Kubernetes Architecture (Master Node / Worker Node)

쿠버네티스 클러스터는 Control plane이라고도 불리는 마스터노드와 Worker 노드로 구성된다. 간략하게 구조를 그려보자면, 아래와 같다. 

Kubernetes Architecture

이제부터는 master node와 worker node를 이루는 쿠버네티스의 각 component에 대해 설명해보려 한다.

Master Node

• API Server: 쿠버네티스 API를 노출하는 컴포넌트(REST)로, Kubenretes의 Frontend와 같다. 흔히 사용하는 kubectl과 같은 user interface는 모두 쿠버네티스와 interact하기 위해 API server를 통하게 된다. REST API이기 때문에, 어플리케이션에서도 클라이언트 라이브러리를 통해 호출할 수 있다. 
• etcd: 분산 Key-Value store로, 모든 클러스터 데이터를 담는다. 
• Scheduler: 노드가 배정되지 않은 새로운 Pod을 감지하고 알고리즘에 따라 그것이 구동될 노드를 선택하고, API Server에 resource specification을 통지한다. 
• Controller Manager: 컨트롤러를 구동 / 관리한다. Controller는 쿠버네티스 오케스트레이션의 뇌와 같은 역할을 하며, 적어도 하나의 Kubernetes Object를 watch하며 desired state로 만들기 위한 control loop이다. 가장 대표적인 컨트롤러들은 아래와 같다.
  • Node Controller: 노드가 다운되었을 때 통지 / 대응한다.
  • Replication Controller : 시스템의 모든 Replication Controller Object에 대하여 알맞은 수의 Pod들을 유지한다.
  • Endpoint Controller: Service와 Pod을 연결 -> Endpoint object를 채워 서비스와 Pod를 연결시킨다.
  • Service Account & Token Controller: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.

마스터 노드는 이처럼 쿠버네티스 클러스터의 핵심적인 컴포넌트들을 가진다. 마스터 노드에는 일반 pod들이 스케줄링되지 않는데, 이는 마스터 노드가 일반 pod을 스케줄링하지 않도록 Taint가 설정되어있기 때문이다.

$ kubectl describe node master | grep Taints
Taints:             node-role.kubernetes.io/master:NoSchedule

Worker Node

워커 노드에는 control plane에서 스케줄링되는 pod들이 생성된다. 어느 pod이 어느 worker node에 스케줄링되어있는지는 아래와 같은 커맨드로 확인할 수 있다.

$ kubectl get pod -o wide
NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
nginx    1/1       Running   0          13s    10.200.0.4   worker0

워커노드를 구성하는 컴포넌트들은 아래와 같다

 

Kubelet

각 노드에서 실행되는 agent로, pod에서 컨테이너가 확실하게 동작하도록 관리한다. API Server를 모니터링하며 해당 Node에 scheduling되는 pod을 감지하고, docker runtime을 통해 pod에서 container를 실행시킨다. 일례로, 배포되어있는 pod을 kubectl describe를 통해 살펴보자.

kubectl describe pod 을 통해 살펴본 pod 상세

Pod의 Events를 보면, default-scheduler에 의해 pod이 minikube node에 scheduling되었고, 이후 kubelet에 의해 저장소에서 image를 pulling하고, nginx container를 생성해서 pod을 start한 것을 볼 수 있다. 만약 해당 pod에 readiness probe나 liveness probe를 설정해두었다면 unhealthy 상태가 되었을 때 마찬가지로 kubelet에 의해 남겨진 이벤트를 발견할 수 있다. Kubelet은 probe체크를 완료한 후, 이를 API Server에 통지한다. 

 

Container Runtime

컨테이너 실행을 담당하는 소프트웨어로, 대표적으로 Docker가 있다. Kubelet이 명령을 받으면 docker runtime을 통해서 컨테이너를 생성/삭제 하는 등의 라이프사이클 관리를 하게 된다. 도커 외에도 containerd나 CRI-O를 사용할 수 있다. 다만, kubelet의 수정 없이 다양한 container runtime을 지원하기 위해서 kubelet과 컨테이너 런타임 사이에 CRI(Container Runtime Interface)라는 표준화된 인터페이스가 등장하게 되었다. 이에 따라 새로운 컨테이너 런타임이 CRI 스펙에 맞추어서 구현되면, kubelet의 코드를 수정할 필요 없이 새로운 컨테이너 런타임이 사용 가능하다. 

Kube Proxy

각 노드에서 실행되는 네트워크 프록시이며, 쿠버네티스 서비스 개념의 구현부로 노드의 네트워크 규칙을 유지/관리한다. API서버로 인해 Service / Endpoint 규칙이 생성/업데이트 되면, 이를 underlying proxy system(ex. iptables, IPVS)에 업데이트한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다. 이후 서비스 관련 포스팅에서 조금 더 자세히 살펴보도록 한다. 

 

References

• kubernetes.io/ko/docs/concepts/overview/components/

쿠버네티스 컴포넌트

• medium.com/@chkrishna/kubernetes-architecture-f7ca63fff46e

Kubernetes Architecture

• bcho.tistory.com/1353

쿠버네티스 CRI (Container Runtime Interface) & OCI (Open container initiative)