[Kubernetes] 쿠버네티스 구성 요소

쿠버네티스 클러스터 구성

쿠버네티스는 마스터 노드와 워커 노드로 구성되어 있다.

 

마스터 노드가 최소 1대 이상 있어야 클러스터를 유지시킬 수 있으며

 

마스터 노드는 여러 대가 있을 수 있다.

 

보통 마스터 노드를 Control Plane, 워커 노드를 Data Plane이라 부르는데

 

마스터 노드에는 특별한 경우가 아니면 애플리케이션 로직이 담긴 컨테이너(Pod)를 할당하지 않기 때문이다.

 

출처 : https://kubernetes.io/docs/concepts/overview/components/

 

마스터 노드, Control Plane

이름을 보면 알 수 있듯이 클러스터를 제어하는 영역이다.

 

그렇다면 쿠버네티스는 Control Plane에 어떤 컴포넌트를 가지고 있을까?

 

kubectl

kubectl은 쿠버네티스 클러스터에 명령을 내리는 컴포넌트이다.

 

우리가 정의한 YAML 파일을 클러스터에 배포하거나 현재 클러스터의 상태를 조회하는 명령을

 

CLI 환경을 제공해 사용자가 편하게 명령어로 제어할 수 있다.

 

kubectl은 기본적으로 마스터 노드에 위치하지만,

 

클러스터 환경이 아닌 로컬 환경에 위치시킬 수도 있다.

 

kube-apiserver

kube-apiserver는 쿠버네티스 클러스터의 중심 역할을 한다.

 

API Server라는 이름만 보면, 사용자가 직접 여기와 통신할것 같지만

 

API Server가 아닌 kubectl을 이용한다.

 

앞으로 설명할 대부분의 컴포넌트들은 이 API Server를 통해 서로 통신한다.

 

etcd

etcd는 카프카를 사용하면서 잠깐 마주쳤었다.

 

etcd는 분산 시스템에서 데이터를 저장할 수 있는 key-value store이다.

 

분산 저장을 지원해 시스템의 가용성을 확보할 수 있다.

 

쿠버네티스는 etcd를 클라우드 구성 요소들의 상태 값을 저장하는데 사용한다.

 

etcd를 제외하고는 상태 값을 관리하지 않으며 kube-apiserver는 명령을 실행할 때

 

etcd의 정보를 참고하게 된다.

 

아래는 etcd의 역할을 설명하는 flow인데 지금 상태에서는 모르고 넘어가도 된다.

kubectl get pods # 현재 클러스터에 있는 파드를 출력하는 명령어

 

kubectl -> kube-apiserver -> etcd -> kube-apiserver -> kubectl 순으로 생각하면 된다.

 

kube-controller-manager

컨트롤러 매니저는 오브젝트 상태를 관리한다.

 

사용자로부터 Pod를 생성하라는 명령이 들어오면 컨트롤러 매니저는 명령대로 Pod를 생성한다. 

 

하지만 노드에 실제로 Pod를 할당하는것은 컨트롤러 매니저가 하지 않고 아래에 있는 스케쥴러가 담당한다.

 

kube-scheduler

이름에서 알 수 있듯이, 스케쥴러를 담당한다.

 

노드의 상태와 자원, 요구 조건등을 고려해 Pod를 어떤 노드에 할당할 것인지를 결정하고 할당한다.

 

컨트롤러 매니저가 Pod를 만들어 놓으면 스케쥴러는 실제로 할당하는 역할이다.

 

워커 노드, Data Plane

실제로 우리 애플리케이션 로직이 담긴 Pod 들을 배포할 노드 영역이다.

 

Data Plane에는 어떤 컴포넌트들이 동작하고 있을까?

 

kubelet

kubelet은 각각의 노드들위에서 동작하는 Agent이다.

 

Pod 안의 컨테이너들이 정상적으로 작동하는지 지속적으로 모니터링하며 

 

kubelet으로 전달 된 PodSpec을 컨테이너 런타임으로 전달하는 역할을 한다.

 

CRI, Container Runtime Interface

실질적인 컨테이너의 실행을 담당한다.

 

쿠버네티스는 CRI로 containerd, CRI-O를 지원한다.

 

음 docker는 어디갔지? 라고 생각할 수 있는데

 

우리가 여태 다뤘던 docker는 대략 이런 이미지이다.

 

출처 : https://www.linkedin.com/pulse/containerd%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B4%EA%B3%A0-%EC%99%9C-%EC%A4%91%EC%9A%94%ED%95%A0%EA%B9%8C-sean-lee/?originalSubdomain=kr

 

containerd는 간단히 말해서 도커에서 만든 CRI이다.

 

쿠버네티스는 containerd를 지원하므로 도커 컨테이너를 자유롭게 사용할 수 있는 것이다.

 

kube-proxy

kube-proxy는 kubelet과 마찬가지로 각각의 노드에 1개씩 존재하며

 

service 오브젝트의 가상 ip 주소와 실제 pod 오브젝트의 ip 주소를 매핑하여

 

서비스 디스커버리를 지원해준다.

 

 

이렇게 쿠버네티스 클러스터의 기본 구성요소를 알아보았다. 

 

기본만 해도 이정도인데 현실은 이보다 훨씬 복잡하게 구성되어 있다,,,

 

하지만 기본을 잘 쌓고 가야 나중에 흔들리지 않을 수 있다!

 

다음 포스팅에서는 쿠버네티스의 대표 오브젝트들을 알아보도록 하겠다.