Kim Jinung
Kubernetes components 본문
0. Goal
쿠버네티스를 사용하고있지만 내부에서 어떤 흐름으로 동작하고 있는지 이해가 부족하다. kube-system 네임스페이스에서 기본적으로 실행되고 있는 kube-proxy, api-server 등이 어떤 역할을 담당하는지 모르고있다. 이번 글에서는 쿠버네티스의 아키텍처를 살펴보고 각 컴포넌트들이 어떤 역할을 하는지 정리한다.
1. 쿠버네티스 클러스터 컴포넌트
쿠버네티스 클러스터는 노드(node)라고 부르는 worker machine(node)들과, 이러한 node들을 관리하는 control plane으로 구성되어있다. master, worker 형태로 구성되어있는 것이다.
유저의 모든 요청은 API server를 통해서 전달된다. API server 컴포넌트가 소속된 control plane 내부에서는 유저가 요청 한 pod의 spec을 참조하여 어떤 노드에서 파드를 생성할 것인지 스케쥴링하고, 실행한다. 이때 클러스터에 참여하고 있는 노드에서는 kubelet 컴포넌트가 파드를 실행하는 주체이다. contorl plane의 API server가 kubelet에 명령을 내리면 kubelet은 노드에서 파드에 관련된 작업을 진행하기도 하고 파드의 상태를 API server에 보고하기도 한다.
이제 각각의 컴포넌트가 담당하고 있는 역할을 알아본다.
(1). Control plane
컨트롤 플레인은 클러스터에 포함되어 있는 아무 노드에서나 실행할 수 있다. 이때 간결함을 위해서 컨트롤 플레인 컴포넌트들은 특정 하나의 머신에서만 실행된다. 분산 아키텍처에서 마스터는 헤드쿼터 역할을 하는 것을 떠올리면 된다. 즉 컨트롤 플레인은 마스터 역할이므로 컨트롤 플레인이 실행되고 있는 머신에서는 유저 컨테이너를 실행하지 않는다. (*싱글 노드로 구성된 환경에서는 어쩔 수 없이 컨트롤 플레인 컴포넌트와 워커 노드 구분없이 실행한다.) 다음과 같은 컴포넌트로 구성된다.
- API server
- kube-scheduler
- kube-controller-manager
- etcd
- cloud-controller-manager(optional)
먼저 흐름을 간단히 요약하면 유저가 커맨드라인 인터페이스인 kubectl로 쿠버네티스에 요청을 보내면, 이 응답을 받는 것은 kube-apiserver다. apiserver는 유저의 요청이 유효한지 검사한다. 유효하다면 파드를 실행시킬 노드를 선택해야 한다. scheduler는 파드를 실행할 최적의 노드를 선택을 담당한다. 파드를 실행할 노드가 선택되면 kube-control-manager는 컨트롤러 프로세스를 실행을 담당한다. 이와 같은 과정을 거치고 kube-apiserver는 노드의 kubelet에 명령을 내리고, kubelet은 apiserver의 요청에 따라 파드를 실행하고 모니터링하고 상태를 보고한다.
kube-apiserver
유저가 쿠버네티스 클러스터와 통신할 때, 커맨드라인 인터페이스인 kubectl을 사용하는데, 이때 kubectl은 k8s API server와 통신한다. 즉 API server는 쿠버네티스의 control plane에서 프론트엔드를 담당한다.
kube-scheduler
신규 파드가 실행될 최적의 노드를 선택한다. 파드 생성 시 다양한 요소(하드웨어, 소프트웨어, 정책 등)을 고려한다.
kube-controller-manager
컨트롤러 프로세스 실행을 담당하는 컴포넌트다. 이때 컨트롤러란 파드의 실행을 제어하는 오브젝트(인스턴스)다. 컨트롤러는 Node controller, Job controller, Endpoints controller, Service account & Token controller 등이 있다. 논리적으로 각 컨트롤러는 별도의 프로세스이지만 복잡성을 줄이기 위해서 싱글 바이너리로 컴파일되어 단일 프로세스로 실행된다.
(문서 상 설명 만으로는 부족한 감이 있음. 추가적인 리서치 진행하여 보완하기)
etcd
쿠버네티스의 백업 저장소로, 클러스터의 모든 관리 데이터를 저장한다. key value store 형태이며 고가용성을 보장한다.
cloud-controller-manager
클라우드 서비스와 연계하는 컨트롤러로, 각 클라우드 사에서 제공한다.
(2). Node Components
노드 컴포넌트는 쿠버네티스 클러스터에 참여하고 있는 모든 노드에서 실행된다. 쿠버네티스 런타임 환경과 실행 중인 파드를 유지보수한다. 다음과 같은 요소로 구성되어 있다.
- kubelet
- kube-proxy
- Container runtime
kubelet
클러스터의 각 노드에서 실행되는 에이전트다. 파드와 컨테이너를 실행하는 주체이며 control plane의 kube-apiserver 컴포넌트와 통신하며 담당하고 있는 노드의 파드를 관리한다.
kube-proxy
클러스터의 각 노드에서 실행되는 네트워크 프록시다. 쿠버네티스 서비스 오브젝트의 구현체다. 네트워크 룰을 유지 관리하는데, 해당 룰은 클러스터 내부 및 외부로에서 클러스터 내부에서 실행되고 있는 파드에 연결할 수 있게 한다.
Container runtime
컨테이너 실행을 담당하는 소프트웨어다. 쿠버네티스는 containerd, CRI-O 등을 지원한다.
(3). Addons
애드온은 쿠버네티스 리소스를 사용하여 클러스터 기능을 구현한다. 클러스터 레벨에 해당하는 기능을 제공하기 때문에 애드온은 kube-system 네임스페이스에 속한다.
coredns
쿠버네티스 클러스터를 위한 자체 DNS server다. 쿠버네티스를 통해서 서비스가 만들어질 때 서비스 이름이 DNS 서버에 등록된다.
이외에도 Dashboard, Container resource monitoring, cluster-level logging 등의 애드온이 있지만, coredns는 필수이므로 쿠버네티스 실행 시 기본적으로 kube-system 네임스페이스에 포함되어 실행된다.
reference
1. k8s docs