쿠버네티스 컴포넌트
쿠버네티스 클러스터의 전체 구조
마스터에는 etcd, kube-apiserver, kube-scheduler, kube-controller-manager,kubelet, kube-proxy, docker 등의 컴포넌트가 실행된다. 컴포넌트 각각이 다른 마스터나 노드 서버에서 별개로 실행되어도 실제 쿠버네티스 클러스터를 운영하는 데 이상은 없다. 하지만 마스터가 서버 1대라면 방금 소개한 프로세스 한 묶음을 해당 서버에서 같이 실행하는 것이 일반적인 구성이다.
마스터는 보통 고가용성을 만족하고자 서버 3대 정도 구성해서 운영한다. 평소 실제 클러스터를 관리하는 리더 마스터는 1대고 나머지 2대는 대기한다. 리더 마스터에 장애가 발생하면자연스럽게 나머지 2대 중 1대가 리더 역할을 맡다. 클러스터를 좀 더 안정적으로 운영하려면 마스터를 서버 5대로 구성할 수도 있다.
노드에는 kubelet, kube-proxy, docker 등의 컴포넌트가 실행된다. 실제 사용하는 컨테이너 대부분은 노드에서 실행된다.
마스터용 컴포넌트
마스터용 컴포넌트들은 실제 클러스터 전체를 관리한다. etcd, kube-apiserver, kubescheduler, kube-controller-manager, cloud-controller-manager 등이 마스터용 컴포넌트이다.
etcd
etcd는 코어OS에서 개발한 고가용성을 제공하는 키-값Key-value 저장소이다. 분산 시스템에서 노드 사이의 상태를 공유하는 합의 알고리즘 중 하나인 raft 알고리즘을 구현한 것이다. 쿠버네티스에서는 필요한 모든 데이터를 저장하는 데이터베이스 역할을 한다.
etcd는 서버 하나당 프로세스 1개만 사용할 수 있다. 보통 etcd 자체를 클러스터링한 후 여러 개 마스터 서버에 분산해서 실행해 데이터의 안정성을 보장하도록 구성한다. etcd 자체는 꽤 안정적이지만 더 안정적으로 쿠버네티스를 운영하려면 주기적으로 etcd에 있는 데이터를 백업할 것을 권한다.
kube-apiserver
kube-apiserver는 쿠버네티스 클러스터의 API를 사용할 수 있도록 하는 컴포넌트이다. 클러스터로 온 요청이 유효한지 검증한다. 예를 들어 쿠버네티스 API 스펙에 맞춰 클러스터의특정 네임스페이스에 존재하는 디플로이먼트 목록 조회 요청을 받으면, 이 요청에 사용된 토큰이 해당 네임스페이스와 자원을 대상으로 요청을 실행할 권한이 있는지 검사하고 권한이 있다면 디플로이먼트 목록을 조회하여 되돌려준다.
쿠버네티스는 마이크로서비스 아키텍처이므로 서로 분리된 컴포넌트 여러 개로 구성되어 있다. 쿠버네티스에 보내는 모든 요청은 kube-apiserver를 이용해서 다른 컴포넌트로 전달한다.
kube-apiserver는 수평적으로 확장할 수 있도록 설계했으므로 서버 여러 대에 여러 개kube-apiserver를 실행해 사용할 수 있다.
kube-scheduler
kube-scheduler는 현재 클러스터 안에서 자원 할당이 가능한 노드 중 알맞은 노드를 선택해서 새롭게 만든 파드를 실행한다. 파드는 처음 실행할 때 여러 가지 조건을 설정하며, kube-scheduler가 조건에 맞는 노드를 찾는다. 조건에는 하드웨어 요구사항, 함께 있어야 하는 파드들을 같은 노드에 실행하는 어피니티(ainity)와 파드를 다양한 노드로분산해서 실행하는 안티 어피니티(anti-affinity) 만족 여부, 특정 데이터가 있는 노드에 할당 등이 있다.
kube-controller-manager
쿠버네티스에는 파드들을 관리하는 컨트롤러 controller가 있다. 컨트롤러 각각은 논리적으로 개별프로세스지만 복잡도를 줄이려고 모든 컨트롤러를 바이너리 파일 하나로 컴파일해 단일 프로세스로 실행한다.
kube-controller-manager는 컨트롤러 각각을 실행하는 컴포넌트이다. 쿠버네티스는 Go언어로 개발되었는데, 클러스터 안에서 새로운 컨트롤러를 사용할 때는 컨트롤러에 해당하는 구조체를 만든다. 이 구조체를 kube-controller-manager가 관리하는 큐에 넣어서 실행하는 방식으로 동작한다.
cloud-controller-manager
cloud-controller-manager는 쿠버네티스의 컨트롤러들을 클라우드 서비스와 연결해 관리하는 컴포넌트이다. 관련 컴포넌트의 소스 코드는 각 클라우드 서비스에서 직접 관리한다.
보통 네 가지 컨트롤러 컴포넌트를 관리한다.
- 노드 컨트롤러(Node Controller): 클라우드 서비스 안에서 노드를 관리하는 데 사용한다.
- 라우트 컨트롤러(Route Controller): 각 클라우드 서비스 안의 네트워크 라우팅을 관리하는데 사용한다.
- 서비스 컨트롤러(Service Controller): 각 클라우드 서비스에서 제공하는 로드밸런서를 생성, 갱신, 삭제하는 데 사용한다.
- 볼륨 컨트롤러(Volume Controller): 클라우드 서비스에서 생성한 볼륨을 노드에 연결하거나 마운트하는 등에 사용한다.
노드용 컴포넌트
노드용 컴포넌트는 쿠버네티스 각 노드의 파드 실행 환경을 관리한다. 컴포넌트에는 kubelet, kube-proxy, 컨테이너 런타임 등이 있다.
kubelet
kubelet은 클러스터 안 모든 노드에서 실행되는 에이전트이다. 파드 컨테이너들의 실행을 직접 관리한다. kubelet은 파드스펙 Podspecs 이라는 조건이 담긴 설정을 전달받아서 컨테이너를 실행하고 컨테이너가 정상적으로 실행되는지 헬스 체크를 진행한다. 단, 노드 안에 있는 컨테이너라도 쿠버네티스가 만들지 않은 컨테이너는 관리하지 않는다.
kube-proxy
쿠버네티스는 클러스터 안에 별도의 가상 네트워크를 설정하고 관리한다. kube-proxy는 가상 네트워크의 동작을 관리하는 컴포넌트이다. 호스트의 네트워크 규칙을 관리하거나 연결을 전달할 수도 있다.
컨테이너 런타임
컨테이너 런타임(Container Runtime)은 실제로 컨테이너를 실행시킨다. 가장 많이 알려진 런타임으로는 도커 Docker가 있고 containerd, runc 같은 런타임도 지원한다. 보통 컨테이너 표준을 정하는 OCIO(pen Container Initiative) 런타임 규격을 구현한 컨테이너 런타임이라면 쿠버네티스에서 사용할 수 있다. 쿠버네티스 버전 1.10부터는 쿠버네티스와 같은 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF) 소속인 containerd를 도커 없이 기본 런타임으로 사용할 수도 있다.
참고
쿠버네티스 입문, 동양북스