Cloud/Docker & Kubernetes

쿠버네티스의 구성 요소

DGO 2023. 4. 19. 03:33

구성한 클러스터에서 kubectl get pods 명령으로 클러스터를 이루는 구성 요소를 확인 가능하다.

 

 

 

kubectl 

쿠버네티스 클러스트에 명령을 내리는 역할을 하며 다른 구성 요소들과 다르게 명령 형태인 바이너리로 배포됨

 

kubelet

파드의 구성 내용을 받아 컨테이너 런타임으로 전달하고 파드 안의 컨테이너들이 정상적으로 작동하는지 모니터링

파드의 생성과 상태 관리, 복구 등을 담당

 

calico-kube-controller, node

해당 클러스터에서 사용하는 컨테이너 네트워크 인터페이스

 

coredns

쿠버네티스의 dns 서버 표준이며 클러스터에서 도메인 이름을 이용해 통신하는데 사용된다.

kubeadm으로 설치하는 경우 coredns가 설치된다.

 

etcd

쿠버네티스의 데이터가 모두 저장되며 etcd의 정보가 백업되어 있다면 장애 상황에서도 클러스터를 복구 가능하다.

etcd가  다운되며 클러스터가 제대로 동작하지 못하므로 분산 저장을 하게되면 장애가 나더라도 시스템의 가용성을

확보 가능

 

kube-apiserver

쿠버네티스 클러스터의 api를 사용할 수 있게 해주는 프로세스로 요청이 왔을 때 요청이 유효한지 검증하는 역할을 함

쿠버네티로의 모든 요청은 kube-apiserver를 통해 다른 곳으로 전달되도록 되어 있음.

 

kube-controller-manager

쿠버네티스 클러스터의 노드 통신 체크 및 복구, 파드 관리 등의 오브젝트 상태를 관리함.

 

kube-proxy

쿠버네티스 클러스트는 파드가 위치한 노드에 kube-proxy를 통해 파드의 통신을 담당함.

 

kube-scheduler

노드의 상태와 자원, 레이블, 요구 조건 등을 고려해 파드를 어떤 노드에 생성할 것인지를 결정하고 할당

 

 

파드의 생명주기에 따른 쿠버네티스 구성 요소들의 역할

쿠버네티스는 작업을 순서대로 진행하는 워크플로 구조가 아니라 선언적인 시스템 구조를 가지고 있으며 즉, 각 요소가 추구하는 상태를 선언하면 현재 상태와 맞는지 점검하고 그것에 맞추려고 노력하는 구조이다.

추구하는 상태를 API 서버에 선언하면 다른 요소들이 API 서버에 와서 현재 상태와 비교하고 그에 맞게 상태를 변경하려고 하며 여기서 API는 현재 상태 값을 가지고 있는데 이것을 보존하는 것이 etcd이다.

 

1. kubectl을 통해 API 서버에 파드 생성을 요청.

 

2. (업데이트가 있을 때마다 매번) API 서버에 전달된 내용이 있으면 API 서버는 etcd에 전달된 내용을 모두 기록해 클러스터의 상태 값을 최신으로 유지. 따라서 각 요소가 상태를 업데이트할 때마다 모두 API 서버를 통해 etcd에 기록됩니다.

 

3. API 서버에 파드 생성이 요청된 것을 컨트롤러 매니저가 인지하면 컨트롤러 매니저는 파드를 생성하고, 이 상태를 API 서버에 전달. 어떤 워커 노드에 파드를 적용할지는 결정되지 않은 상태로 파드만 생성됨.

 

4. API 서버에 파드가 생성됐다는 정보를 스케줄러가 인지. 스케줄러는 생성된 파드를 어떤 워커 노드에 적용할지 조건을 고려해 결정하고 해당 워커 노드에 파드를 띄우도록 요청.

 

5. API 서버에 전달된 정보대로 지정한 워커 노드에 파드가 속해 있는지 스케줄러가 kubelet으로 확인.

 

6. kubelet에서 컨테이너 런타임으로 파드 생성을 요청.

 

7. 파드가 생성됨.

 

8. 파드가 사용 가능한 상태가 됨.

'Cloud > Docker & Kubernetes' 카테고리의 다른 글

쿠버네티스 노드 유지보수  (0) 2023.04.20
쿠버네티스 파드 생성  (0) 2023.04.20
쿠버네티스 클러스터 구성  (1) 2023.04.17
도커로 컨테이너 다루기  (0) 2023.04.16
Docker?  (0) 2023.04.15