Kubelet

• 이 노드 위에 올라갈 Pod / 컨테이너를 대신 관리해주는 Agent
  • “API 서버가 시킨대로 컨테이너를 만들고, 잘 돌고 있는지 보고하는 프로그램”

kubelet이 하는 핵심 역할 3가지

1. “이 노드에 어떤 Pod를 띄울지” 명령 받기
   1. 컨프롤 플레인(특히 kube-apiserver)이 “이 Pod는 Node-A에 배치해라” 라고 결정하면,
   2. node-A에 있는 kubelet이 그 명령을 받는다.
   3. 그래서 kubelet은 “이 노드 담당자” 같은 느낌
2. 컨테이너 런타임에게 실제로 컨테이너 생성 요청
   1. kubelet은 직접 컨테이너를 만들지 않고,
      1. Docker, containerd, CRI-O 같은 컨테이너 런타임에게 “이 이미지로 컨테이너 만들어줘” 라고 요청
      2. 그 다음 컨테이너가 잘 덨는지 재시작이 필요한지 헬스체크(라이브니스/레디니스) 통과했는지를 계속 감시

OpenShift에서는 보통 CRI-O + kubelet 조합으로 돌아간다고 보면 된다.

1. 상태를 계속 API 서버에 보고
   1. 이 노드에 현재 어떤 Pod/컨테이너가 떠 있는지 상태는 Running인지 CrashLoopBackOff인지
   2. 노드 리소스(CPU/메모리) 상황은 어떤지
   3. 이런것들은 kubelet이 구준히 kube_apiserver에 보고 한다.
   4. 그래서 kubectl get nodes, kubectl get pods -o wide 같은 명령이 동작하는 것.

실제 흐름으로 이해해보기

kubectl apply -f nginx-pod.yaml를 했다고 가정

1. API 서버
   1. 매니페스트를 받고, “이 Pod는 node-1에 배치하자”라고 결정
2. node-1의 kubelet
   1. API 서버에서 “이 Pod 스펙”을 가져와서 확인
   2. “nginx:latest 이미지로 컨테이너 하나 만들어야겠네?”
3. 컨테이너 런타임(CRI-O 등)
   1. kubelet 요청을 받고 이미지를 pull → 컨테이너 생서
4. kubelet
   1. 컨테이너가 잘뜨는지 체크
   2. 정상 Running이면 “이 pod running 상태입니다:”라고 API 서버에 보고
5. 우리가 kubectl get pod를 보면
   1. kubelet이 보고한 상태를 API서버가 알려주는 것

kubelet이 없다면 어떻게 될까?