쿠버네티스(kubernetes)의 역할과 구성 요소
1. 쿠버네티스의 역할
- 자동화된 복구
컨테이너를 모니터링 하면서 컨테이너가 죽는 즉시 쿠버네티스는 그것을 빠르게 재시작 시킨다.
- 로드 밸런싱
서비스 웹사이트의 니즈에 따라 컨테이너의 숫자를 자동으로 조절하고, 접속하는 유저가 많을 수록 쿠버네티스는 구동하는 컨테이너의 숫자를 늘리고 유저가 적어지면 컨테이너의 숫자를 줄입니다.
- 무중단 서비스
점진적 업데이트를 통해 서비스를 중단하지 않고도 서비스 업데이트를 가능하게 한다.
- 호환성
서로 다른 클라우드 사이의 호환 문제를 해결하여 사용자들이 특정 업체에 종속되는 일 없이 환경을 이전할 수 있도록 해준다.
2. 쿠버네티스의 구성 요소
쿠버네티스 기능 제어를 전체적으로 담당하는 컨트롤 플레인(Control Plane) 컴포넌트와 컨트롤 플레인 컴포넌트의 요청을 받아 각 노드에서 동작을 담당하는 노드(Node) 컴포넌트로 나누어볼 수 있다.
쉽게 말해, 컨트롤 플레인 컴포넌트는 회사 전반에 해당하는 ‘본사의 업무’라고 할 수 있습니다. 노드 컴포넌트는 각 지역별 ‘지사의 업무’라고 볼 수 있다.
1. 컨트롤 플레인 (Control Plane) - 마스터 노드
a. kube-apiserver
공식 문서에는 ‘쿠버네티스 컨트롤 플레인의 프론트 엔드’ 라고 소개하고 있다. 말 그대로 kube-apiserver는 쿠버네티스 클러스터로 들어오는 요청을 가장 앞에서 접수하는 역할을 한다. 예를 들어, 쿠버네티스 커맨드 도구인 kubectl을 사용해 명령을 수행할 경우 이 명령은 kube-apiserver로 전송된다. 이렇게 전달된 요청에 대하여 kube-apiserver는 이 요청의 처리 흐름에 따라 적절한 컴포넌트로 요청을 전달하는 역할을 한다.
b. etcd
쿠버네티스 클러스터가 동작하기 위해서는 클러스터 및 리소스의 구성 정보, 상태 정보 및 명세 정보 등이 필요하다. etcd는 이를 키-값(key-value) 형태로 저장하는 저장소이다. 만약 etcd가 정상적으로 동작하지 않는다면 쿠버네티스 클러스터에 존재하는 리소스들은 그저 바다에 떠다니는 난파선과 같다. 안정적인 동작을 위해 자료를 분산해서 저장하는 구조를 채택하고 있다. 쉽게 말해, etcd는 회사 각종 중요 정보가 모두 모여 있는 금고와 같은 곳이고 동일한 자료를 여러 금고에 나눠서 보관하고 있는 것이다.
c. kube-scheduler
쿠버네티스 클러스터는 여러 노드로 구성되어 있고, 기본적인 작업 단위라고 할 수 있는 Pod는 여러 노드 중 특정 노드에 배치되어 동작한다. 이때 새로 생성된 Pod를 감지하여 어떤 노드로 배치할지 결정하는 작업을 스케줄링이라고 하는데, 이런 스케줄링을 담당하는 컴포넌트가 kube-scheduler이다. 스케줄링을 위해 노드 및 pod의 각종 요구사항과 제약사항을 종합적으로 판단할 필요가 있다. 이러한 판단 또한 kube-scheduler의 역할이다. 쉽게 말해, 각 부서 인력 소요 계획과 신입사원 역량을 고려해 적절한 부서로 배치하는 인사 담당 부서와 같다.
Pod
쿠버네티스의 배포 가능한 가장 작은 컴퓨팅 유닛이다. 애플리케이션 컨테이너, IP 주소, 볼륨과 같은 공유 스토리지등을 포함한다.
d. kube-controller-manager
kube-controller-manager는 다운된 노드가 없는지, pod가 의도한 복제(Replicas) 숫자를 유지하고 있는지, 서비스와 pod는 적절하게 연결되어 있는지, namespace에 대한 기본 계정과 토큰이 생성되어 있는지를 확인하고 적절하지 않다면 적절한 수준을 유지하기 위해 조치하는 역할을 한다.
2. 노드(Node) 컴포넌트 - 작업자 노드
a. kubelet
kubelet은 노드에서 컨테이너가 동작하도록 관리해 주는 핵심 요소이다. 각 노드에서 pod를 생성하고 정상적으로 동작하는지 관리하는 역할을 담당하고 있으며, 쿠버네티스의 Workload를 관리하기 위해 내려지는 명령은 kubelet을 통해 수행된다고 볼 수 있다. 쿠버네티스 pod를 관리하기 위해 작성하는 YAML을 쿠버네티스 클러스터에 적용하기 위해 kubectl 명령어를 사용할 때, 이 YAML이 kube-apiserver로 전송된 후 kubelet으로 전달된다. kubelet은 이 YAML을 통해 전달된 pod를 생성 혹은 변경하고, 이후 이 YAML에 명시된 컨테이너가 정상적으로 실행되고 있는지 확인한다.
Workload
워크로드는 '쿠버네티스 상에서 작동되는 애플리케이션'을 의미하며, 클라우드 분야에서는 '어떤 애플리케이션을 실행할 때 필요한 IT 리소스의 집합'이라는 의미로 통용된다. 쿠버네티스에서는 워크로드를 일련의 pod 집합내에서 실행한다.
b. container runtime
컨테이너 런타임은 pod에 포함된 컨테이너 실행을 실질적으로 담당하는 application을 의미한다. (컨테이너 런타임은 쿠버네티스 구성 요소에 기본적으로 포함되어 있거나, 특정 소프트웨어를 지칭하는 것은 아니다.) 쿠버네티스가 컨테이너를 제어하기 위해 제공하는 표준 규약인 컨테이너 런타임 인터페이스(CRI)를 준수하여 쿠버네티스와 함께 사용할 수 있는 외부 애플리케이션들을 의미한다.
c. kube-proxy
kube-proxy는 쿠버네티스 클러스터 내부에서 네트워크 요청을 전달하는 역할을 한다. kube-proxy가 없다면 쿠버네티스 내부에 위치한 특정 pod로 요청을 보내기 위해서 해당 pod 의 IP를 정확히 알아야 하며, 이 IP가 외부에서 접근 가능하도록 해야한다. 하지만, 쿠버네티스 pod IP는 pod가 배포될 때마다 매번 바뀌기 때문에, IP를 통해 pod에 요청을 전달하기란 쉽지 않다. kube-proxy는 pod의 IP는 매번 변하지만 kube-proxy가 이 pod에 접근할 수 있는 방법을 그때마다 관리하고 갱신하며, 서비스 오브젝트는 이 정보를 사용하여 pod가 외부에서 접근할 수 있는 경로를 제공한다.