Kubelet
Kubelet이란 각 노드에서 실행되는 기본 Node Agent입니다.
위의 구성도에 보이는 것 처럼 api-server와 통신하며, PodSpec을 사용해 PodSpec에 기술된 컨테이너들이 정상적으로 작동되도록 돕습니다.
Worker Node가 배라면 Kubelet은 선장이라고 할 수 있습니다.
관리자가 Pod을 배포하려고 할 경우, api-server를 비롯한 컨트롤 플레인의 컴포넌트들은 명령에 대한 인가 및 인증을 수행하고, 선언된 상태와 일치하지 않는 Pod이 있는지 확인하고, 어떤 Node에 Pod을 배치하면 좋을지 결정합니다.
어디에 배치할지는 Master Node의 컴포넌트들 정확히는 Scheduler가 결정하지만 실제로 Container runtime(Docker 등)에 배치를 명령하는 것은 Kubelet의 역할입니다.
만약, Worker Node에서 동작중인 Kubelet이 정지되면 컨테이너 런타임에 요청을 보내는 역할을 수행해주는 컴포넌트가 정지되었으므로 Pod 생성, 삭제 등이 해당 Node에서 정상적으로 수행되지 않습니다.
Kubelet 서비스 확인
참고 : Kubernetes 실습을 위한 Minikube 환경 구성
Minikube는 로컬 환경에서 Worker Node와 Master Node를 별도로 구성할 필요 없이 하나의 호스트에 구성해주는 툴입니다.
Worker Node와 Master Node를 구축하고 설정하는 수고가 들지 않기 때문에, 간단한 테스트를 수행할 때 활용하기 좋습니다.
Minikube의 설치 방법에 대해서는 위의 참고 문서를 참고해 주세요.
기본적으로 Minikube Kubernetes 클러스터에 올라와 있는 Pod들은 아래의 명령어를 통해 조회할 수 있습니다.
# 클러스터의 모든 Pod 조회
$ kubectl get Pod --all-namespaces
위 명령의 결과를 보면 Minikube를 통해 구성한 Kubernetes 클러스터에는 etcd, api-server, controller, Scheduler등 Master Node의 컴포넌트들과 kube-proxy가 Pod형태로 배포된 것을 확인할 수 있습니다.
그럼 Kubelet은 어디에 있을까요?
Kubelet은 Worker Node에서 서비스 형태로 동작하고 있으므로 다음 명령어를 통해 확인할 수 있습니다.
# Kubelet 서비스 확인
$ systemctl status kubelet
Kubelet이 멈추면 어떻게 될까?
그렇다면 Kubelet이 멈추면 어떻게 될까요?
Kubelet이 하는 역할을 알고 있다면 쉽게 유추해 낼 수 있습니다.
Kubelet은 Worker Node의 런타임 환경에 실제로 Pod를 배포하는 역할을 수행하므로 Kubelet이 정지된 Worker Node에 Pod이 배포되지 않을 것입니다.
실제로 Kubelet을 정지시켜 보겠습니다.
# Kubelet 정지
$ systemctl stop Kubelet
Kubelet이 정지된 것을 확인할 수 있습니다.
그럼 이제 Master Node에서 클러스터에 Pod을 배포해보겠습니다.
# `Pod` 생성
$ kubectl run 
정말 간단한 nginx Pod을 배포하는데 2분 가까이 시간이 지나도 배포가 되지 않고 있습니다.
Worker Node에 Kubelet이 정지되어 컨테이너 런타임을 통해 Pod을 배포하지 못하고 있기 때문입니다.
이제 다시 Kubelet을 실행시키고 Pod이 생성되었는지 확인하겠습니다.
Pod이 정상적으로 생성된 것을 확인할 수 있습니다.
결론
이렇게 Kubelet은 Worker Node에서 컨테이너 런타임을 이용해서 Pod을 생성해주는 역할을 수행하고, Kubelet 서비스에 문제가 생기면 해당 Worker Node에서는 Pod을 배포하지 못하게 됩니다.
