1. Cluster Architecture
1.1 Nodes
- 마스터 노드 (Master Node or Control Plane): 클러스터 전체를 관리하고 조정한다. 이 노드는 클러스터 내의 모든 노드와 컨테이너의 상태를 파악하고, 컨테이너 배치를 계획하며, 클러스터의 건강 상태를 모니터링하는 역할을 한다.
- 워커 노드 (Worker Node): 실제 컨테이너가 배치되고 실행되는 노드이다. 워커 노드는 컨테이너의 실행을 담당하고, 마스터 노드의 지시에 따라 컨테이너를 관리하고 네트워크 및 저장소 리소스를 제공한다.
1.2 Components
- ETCD
- Key-value 형식으로 정보를 저장하는 데이터베이스 (key-value store)
- 클러스터에 관한 모든 정보를 저장한다.
- 어떤 컨테이너가 어떤 노드에 있는지, 몇 시에 생성되었는지 등을 기록한다.
- Kube Scheduler
- 컨테이너의 리소스 요구사항을 파악하여 워커 노드에서 생성해야할 컨테이너를 식별한다.
- 워커 노드의 크기와 용량, 생성된 컨테이너의 수 등을 기준으로 컨테이너의 위치를 결정한다.
- Kube Controller Manager
- 노드 관리 (새 노드를 클러스터에 온보딩, 노드가 사용 불가능하거나 파괴되는 상황을 처리)
- 컨테이너 관리 (컨테이너가 손상 및 파손되면 새 컨테이너를 준비)
- Kube-API Server
- 클러스터 내 여러 요소들의 의사소통 담당
- 클러스터 내에서 모든 작업을 오케스트레이션
- API를 통해 클러스터에서 여러 작업을 수행
- 마스터 노드와 워커 노드 간의 통신 역할
- Kubelet
- 클러스터의 각 노드에서 실행되는 에이전트
- 노드의 모든 활동을 관리
- Kube-API로부터 워커 노드에 생성할 컨테이너에 대한 정보를 받고 필요한만큼 생성 및 제거
- 주기적으로 노드와 노드에 생성된 컨테이너의 상태 등을 Kube-API로 전달
- Kube Proxy
- 워커 노드에서 실행되는 애플리케이션들의 통신 담당
2. ETCD
- 아래의 정보들을 저장한다.
- Nodes
- Pods
- Configs
- Secrets
- Accounts
- Roles
- Bindings
- Others
- 클러스터에 변화를 줄 때마다 업데이트 된다. (e.g., 새로운 노드 추가 / Pod 또는 Replica set 생성)
- ETCD는 컨테이너를 실행할 때 모든 정보들을 Kube Controller에게 전달한다.
3. Kube-API Server
- ETCD와 직접적으로 상호작용하는 유일한 구성요소
- Kube Controller, Kube Scheduler, Kubelet은 watch 기능을 통해 API 서버를 이용하여 각 영역에서 업데이트를 진행한다. (아래의 이미지 참고)
4. Kube Controller Manager
- 다양한 conroller들을 관리
- 노드들과 Pod들을 모니터링(watch status)하고 상황에 필요한 조치를 취한다.(remediate situation) (e.g., 노드/Pod 생성 및 제거 등)
- 노드와 Pod 뿐만 아니라 클러스터 내에 다양한 구성 요소들의 상태를 지속적으로 모니터링하고 클러스터를 사용자가 원하는 상태로 만든다.
4.1 Controllers
- Node Controller
- Kube API 서버를 통해 노드의 상태를 모니터링하고 애플리케이션이 계속 실행되도록 필요한 행동을 취한다.
- 5초마다 노드의 상태를 확인 (Node Monitor Period = 5s)
- 노드의 heartbeat가 멈추면, 40초 동안 기다렸다가 계속 멈춰있으면
UNREACHABLE로 표시되고,kubectl get nodes명령어 입력하면NotReady로 표시된다. (Node Monitor Grace Period = 40s) UNREACHABLE로 표시된 후, 5분동안 지속되면 다른 노드에서 Pod이 재시작된다. (Pod Eviction Timeout = 5m)
- Replication Controller
- Replica set의 상태를 모니터링하고 원하는 수의 Pod가 set 내에 항상 생성되어 있도록 해주는 역할
- 즉, Pod이 죽으면 다른 Pod이 자동으로 생성된다.
- 이외에 다른 controllers
- Namespace Controller
- Deployment Controller
- Replicaset Controller
- Endpoint Controller
- Job Controller
- CronJob Controller
- StatefulSet Controller
- PV Protection Controller
- PV Binder Controller
- Service Account Controller
- etc.
5. Kube Scheduler
- 어떤 Pod가 어떤 노드에 들어갈지만 결정 (실제로 생성하는 역할은 kubelet)
- Pod의 리소스 요구 사항에 따라 생성되기에 알맞은 노드를 결정
- Filter nodes: Scheduler가 이 Pod에 맞지 않는(CPU와 메모리 리소스가 부족한) 노드를 걸러낸다.
- Rank nodes: 우선순위 함수를 이용하여 0에서 10까지의 점수로 노드에 점수를 매겨서 Pod가 생성된 후 노드에 남을 리소스 양을 계산한다. 노드에 리소스가 더 많이 비어있으면 순위가 높게 올라간다.
- Select a node: 정해진 우선순위를 통해 노드를 결정한다.
- Scheduler는 customizing이 가능하다.
- Resource requirements and limits
- Taints and tolerations
- Node selectors/affinity
6. Kubelet
- 마스터 노드와 워커 노드 간의 유일한 소통 담당
- API 서버의 지시에 따라, 노드를 생성하거나 Pod을 생성/제거함
- API 서버에 노드와 Pod의 상태를 모니터링하여 일정 간격으로 보고한다.
7. Kube Proxy
- 각 노드에서 실행되는 프로세스
- 새로운 서비스 object가 생성될 때마다 각 노드에서 적절한 규칙을 만들어 서비스로 트래픽을 전달한다.
- 여기서 규칙으로 쓸 수 있는 한가지 방법은 iptables을 사용하는 것이다.
- 예를 들어, 서비스 IP가
10.96.0.12이고, DB IP가10.32.0.15이면, 백엔드 Pod에10.96.0.12:10.32.0.15를 전달한다.
8. Workflow
사용자가 kubectl get nodes 명령어 사용 시
- API 서버는 사용자 authentication(인증)을 확인한다.
- API 서버는 Request validation(유효성)을 검사한다.
- API 서버는 ETCD로부터 현재 데이터를 검색하여 response를 전달한다.
사용자가 kubectl create -f pod.yaml 명령어 사용 시
- API 서버는 사용자 인증을 확인한다.
- API 서버는 Request validation을 검사한다.
- API 서버는 ETCD로부터 현재 데이터 검색한다.
- API 서버는 새로운 Pod의 구성 정보를 ETCD에 업데이트한다.
- API 서버는 사용자에게
Pod created!response 전달한다. - Scheduler는 지속적으로 API 서버에 요청을 보내 새로 생성되는 Pod에 대한 정보를 실시간으로 수집한다.
- Scheduler는 새로운 Pod를 정해진 노드에 스케줄링한다.
- Scheduler는 스케줄링된 노드 정보를 API 서버에 전달한다.
- API 서버는 Pod의 새로운 상태를 ETCD에 업데이트한다.
- kubelet은 지속적으로 API 서버에 요청을 보내 새로운 Pod에 대한 정보를 가져온다.
- Kubelet은 Pod을 생성하고 Docker를 통해 애플리케이션의 이미지를 배포한다.
- Kubelet은 완료된 상태를 API 서버에 전달한다.
- API 서버는 ETCD로 받은 데이터를 업데이트한다.
