https://www.youtube.com/watch?v=dlI1PFCtfm0&list=PLIUCBpK1dpsNf1m-2kiosmfn2nXfljQgb&index=5
쿠버네티스 강의 영상을 보면서 쿠버네티스를 공부하였습니다.
Pod
pod는 컨테이너를 뜻한다.
쿠버네티스에 컨테이너 1개라고 하면 1개라고 적어놓고 1개인지 아닌지 확인하여 아니면 1개로 만들어주고 2개면 하나를 없애준다.
쿠버네티스에서 아래와 같은 과정을 거친다.
Desired State
while(1)
{
상태체크: 현재상태 == 원하는 상태
차이점 발견: 현재상태 != 원하는 상태
조치: 현재상태 -> 원하는 상태
}
어디다가 설치를 해야할지 알려주는 스케쥴러가 존재한다.
컨테이너 상태를 체크할 컨트롤러도 존재한다.
체크하고 명령을 보내는 부분을 Master, 실제로 컨테이너가 실행되는 부분을 Node, 중간에서 교통정리를 해주는 API server, 상태를 저장하고 조회하는 데이터 베이스는 etcd
Master 상세 용어
etcd: 모든 상태와 데이터를 저장, 분산 시스템으로 구성하여 안전성을 높임[고가용성-HA], 가볍고 빠르면서 정확하게 설계[일관성], key-Value형태로 데이터 저장, TTL, watch같은 부가기능 제공, 백업은 필수!
API server: 상태를 바꾸거나 조회, etcd와 유일하게 통신하는 모듈, REST API형태로 제공, 권한을 체크하여 적절한 권한이 없을 겨우 요청을 차단, 관리자 요청 뿐 아니라 다양한 내부 모듈과 통신, 수평으로 확상되도독 디자인
Scheduler: 새로 생성된 Pod의 요구사항을 체크(노드에 라벨을 부여)
Controller: 논리적으로 다양한 컨트롤러가 존재 (복제, 노드, 엔드포인트 컨트롤러 ....), 끊임 없이 상태를 체크하고 원하는 상태를 유지, 복잡성을 낮추기 위해 단일 프로세스로 실행
Master 상세 - 조회 흐름
Controller -(1)정보 조회 -> API Server(2)정보 조회 권한 체크 -(3)정보 조회-> etcd
etcd -(1)원하는 상태 변경-> API Server -(2)원하는 상태 변경-> Controller(3)원하는 상태로 리소스 변경 -(4)변경 사항 전달-> API Server(5)정보 갱신 권한 체크 -(6)정보 갱신-> etcd
수많은 내부적인 컴포넌트들(Controller, Scheduler)이 API server와 통신을 하고 API server만 etcd와 소통하는 구조이다.
Node
proxy, Kubelet이 API Server만 바라본다.
proxy 서버는 iptables이나 ipvs를 사용, Kubelet이 직접 pod과 통신
Node 상세 용어
kubelet: 각 노드에서 실행, pod을 실행/중지하고 상태를 체크, CRI(Container Runtime Interface)
proxy: 네트워크 프록시와 부하 분한 역할, 성능상의 이유로 별도ㅢ 프록시 프로그램 대신 iptables or IpVs를 사용(설정만 관리)
쿠버네티스 흐름
관리자가 요청 -(1)pod 하나 만들어줘! -> API server -(2)Pod 요청[etcd에다가 저장]-> etcd (pod - 생성요청)
API Server -(3) 새 pod 확인, (4) pod 할당-> Controller (새로 생긴 pod이 있나 체크)
API Server -(5)pod할당 요청-> etcd(pod - 할당 요청)
API Server -(6)새 pod할당 확인-> Scheduler (할당요청이 있네? 어디다가 띄울까 ) -(7)pod 노드 할
당-> API Server -(8)pod 노드 할당-> etcd (Pod - 노드할당 / 미실행)
API Server -(9)미실행 pod 확인-> Kubelet (내 노드에 할당된 pod중에서 아직 실행이 안된 파일이 있나? 확인) -(10) Pod 생성-> API Server -(11) pod 생성-> etcd (Pod - 노드 할당 / 실행중)
쿠버네티스 오브젝트
Pod
- 가장 작은 배포단위
- 전체 클러스터에서 각 pod마다 고유한 ip를 할당
- 여러개의 컨테이너가 하나의 pod에 속할 수 있음
- 각 pod안에서 host 폴더 공유, localhost 네트워크 공유
ReplicaSet
- 여러개의 Pod을 관리
- 새로운 Pod은 Template을 참고하여 생성
- 신규 pod을 생성하거나 기존 podd을 제거하여 원하는 수(Replicas)를 유지
Deployment
- 배포 버전을 관리
- 여러개의 Replicaset을 관리
- 내부적으로 Replicaset을 이용
Daemon set
- 모든 노드에 꼭 하나씩만 떠있기를 원하는 pod을 만들고 싶을 때 사용 (로그를 수집 - 모니터링에 유용, 등등)
Service - ClusterIP
- 클러스터 내부에서 사용하는 프록시
service(ClusterIP) - pod
ㄴpod
ㄴpod - pod은 동적이지만 서비스는 고유 ip를 가짐
- 클러스터 내부에서 서비스 연결은 DNS를 이용
- 클러스터 ip는 내부에서만 통신가능, 외부 브라우저에서는 접근 불가
Service - NodePort
- 노드(host)에 노출되어 외부에서 접근 가능한 서비스
- service(NodePort) -> Service(ClusterIP)로 접근
- 모든 노드에 동일한 포트로 생성
Service - LoadBalancer
- 하나의 IP주소를 외부에 노출
- 1번 노드를 도메인에 연결했는데 서버가 죽으면? 2번 노드로 붙어야하는데 설정을 안해줘서 접속이 끊기게 된다. 이러한 것을 방지하기 위해 앞에 로드밸런서를 둔다.
- 사용자는 로드밸런서로 요청을 보내고 그 요청이 다시 노드포트로 가고 간 요청이 클러스터ip로 가고 간 요청이 pod으로 가는 구조로 되어 있다.
Ingress
https://kubernetes.io/ko/docs/concepts/services-networking/ingress/
- 도메인 또는 경로별 라우팅 - Nginx, HAProxy, ALB, ....
- 클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리함.
- 클러스터 외부에서 클러스터 내부 서비스로 HTTP와 HTTPS 경로를 노출
일반적인 구성
LoadBalancer IP에 대한 고찰
VM으로 minikube를 실행하고 minikube ip 명령어로 나온 ip가 로드밸런서의 ip이다. 라는 착각부터 이 이야기는 시작된다.
ft_services를 마친 분들에게 자문을 구하며 답을 알아내었다.
ft_services 과제를 git으로 clone하고 해당 코드들의 내용을 뜯어보면서 확인하는데 loadbalancer ip를 192.168.99.100으로 지정을 해두고 과제를 진행하고 있었다.
로드밸런서인 metallb의 yaml파일은
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 192.168.99.100-192.168.99.255이렇게 나타나 있었다.
이것을 확인한 jiholee님과 gypark님과 나는 아무의심없이 넘어갔지만 minikube ip를 친 결과 ip의 주소는 192.168.99.103이었고, 사이트에 접속하는데
지정해두었던 ip인 192.168.99.100:5000으로 접속하면서 의문이 들었다.
저 minikube ip가 로드밸런서 ip가 아니었나?
로드밸런서의 ip에 대한 추측은 이것만이 아니었다.
'저 yaml파일에 address범위 안에 들어가 있으니 괜찮을 것이다.'라고 해서 addresses범위를 minikube ip가 해당되지 않도록 192.168.99.200-192.168.99.255으로 바꾸고, 과제를 돌려보니 사이트에는 접속이 가능했다.
다른 실험으로는 지정해두었던 loadbalancer ip인 192.168.99.100를 지우고 실행시킨 결과, extern ip가 192.168.99.100 이렇게 하나의 ip만 가리키고 있던게 주소값 범위를 정해두었던 200부터 1씩 올라가면서 각각의 extern ip를 가지게 되었다.
그리고 192.168.99.100-192.168.99.255를 172.16.0.0-172.31.255.255 범위로 해서 해봤는데 이건 또 안됐다.
이건 안되는게 당연한게 사설 ip에 주소대역이 아래와 같은데,
Class A : 10.0.0.0 ~ 10.255.255.255
Class B : 172.16.0.0 ~ 172.31.255.255
Class C : 192.168.0.0 ~ 192.168.255.255
여기서 minikube ip와 다른 대역에 있어서 안되는 것이다.
이렇게 검증해본 결과,
-
minikube ip는 무조건 로드밸런서의 ip가 아니다. (다르게 설정하여 할 수 있다.)
-
minikube ip와 맞는 사설 ip로 addresses범위를 설정해야 한다.
-
Minikube VM은 host-only IP 주소를 통해 호스트 시스템에 노출되고, 이 IP 주소는 minikube ip 명령어로 확인할 수 있다. NodePort 서비스 타입은 IP 주소에 해당 노드 포트로 접근할 수 있다.
라는 결론이 나왔다.
이제 ip에 대한 이슈도 해결되었으니 차근차근 만들어봐야겠다.
같이 논의를 나누었던 jiholee님과 gypark님 고생하셨습니다. ft_services 화이팅!
