[ Docker && Kubernetes ] - 쿠버네티스를 이용한 컨테이너 오케스트레이션: 쿠버네티스 클러스터 구성요소

우선 전반적인 클러스터 구성에 대해 살펴보고 제어 영역과, 노드가 어떻게 이루어져 있는지에 대해 알아보고 마치겠습니다.

 

클러스터 구성

Control Plane ( Master Node )

컨트롤러 플래인은 클로스터의 관리하는 역할을 담당합니다. 그리고 상태 관리 및 명령어 처리를 담당합니다. 

 

API Server

API Server는 기존의 어플리케이션과 매우 유사합니다. 상태를 관리하는 데이터베이스 (etcd)와 Kube API Server가 이로부터 상태를 관리하는 전통적인 어플리케이션과 비슷합니다. etcd는 데이터를 안전하게 관리하기 위한 분산 Key - Value저장소라고 할 수 있습니다. 만약 클러스터 상태를 복구하고 싶다고 하면 etcd만 관리하면 됩니다.

 

Scheduler

API서버와 통신하면서 각각의 노드가 자원을 얼마나 사용하고 있는지 상태를 관리하면서 새로운 워크로드를 띄워야 할때, 어디 노드에 해당 컨테이너를 띄워야 하는지 관리를 해줍니다. 

 

Controller Manager

Controller라는 컴포넌트는 쿠버네티스를 이해하기 위한 아주 중요한 컴포넌트입니다. 여러 컨트롤러 프로세스를 관리하는게 컨트롤러 매니저 입니다. 컨트롤러 매니저에는 쿠버네티스 컨트롤러 매니저와 클라우드 컨트롤러 매니저가 존재하게 됩니다. 클라우드 컨트롤러 매니저는 본인이 서비스를 운영하고자 하는 클라우드 프로바이더가 있을것입니다. 각각의 환경에 맞춰서 해당 클라우드 프로바이더와 통신하면서 클라우드 프로바이더에 종속적인 기능을 수행합니다. Ingress를 이용해서 AWSD ALB를 이용한다거나, Storage Class를 이용해서 EBS를 사용한다거나 할때, 클라우드 컨트롤러 매니저를 사용합니다. 

 

그리고 API Resource들이 있습니다. 여기에는 Pod, Deployment, Service, secret과 같은것들이 있습니다. 이들을 제어하는 컨트롤러가 있는데, 이는 API Server와 통신을 하면서 예를들어 클러스터에 어떤 Pod들이 있는지, 지금 클러스터의 상태와 API Server가 가지고 있는 Pod의 상태를 비교해서 만약 현재 클러스터의 상태와 다르다고 하다면 reconcile이라는 작업을 하여 상태를 변화시키게 됩니다. 

 

etcd

분산 Key - Value저장소로 클러스터 상태를 저장하는 데이터베이스 역할을 합니다.

 

Node (Worker Node)

노드는 어플리케이션 컨테이너를 실행하는 역할을 합니다.

 

kubelet

kubelet은 모든 노드에 설치되는 컴포넌트 입니다. API 서버와 통신을 하면서 노드의 리소스를 관리하기도 합니다. 그리고 컨테이너 런타임(Container Runtime)과 통신하며 컨테이너 라이프사이클을 관리하게 됩니다. 이 때 컨테이너를 관리하기 위해 사용되는 CRI가 존재하게 됩니다.

 

CRI ( Container Runtime Interface )

Container Runtime에는 Docker만 있는것이 아닙니다. 컨테이너를 관리해주는 데몬이 굉장히 다양한데, 쿠버네티스가 도커로부터 의존성을 제거하고 다양한 컨테이너 런타임을 지원하기 위한 인터페이스라고 보시면 됩니다. 그래서 쿠버네티스는 Docker, container-d, cri-o컨테이너 런타임을 지원합니다.

kube-proxy

이는 클러스터상에서 오버레이 네트워크를 구성하는데 기여합니다. 그리고 네트워크 프록시 및 내부 로드밸런서 역항를 수행합니다.

 

다음 실습부터는 minikube를 클러스터 배포판으로 사용하게 됩니다. minikube가 만드는 클러스터는 단일노드 클러스터 입니다. 따라서 이는 Master 노드 / Workder 노드를 모두 수행하는 클러스터라고 보시면 됩니다.  다음부터는 클러스터를 만든다는 느낌보다는 사용자의 입장에서 쿠버네티스 리소스를 어떻게 관리하고 어플리케이션을 어떻게 관리할 수 있는지와 관련된 내용을 다루겠습니다.