kubelet은 Kubernetes 노드에서 실행되는 에이전트다. 할당받은 Pod 명세를 읽고 컨테이너 런타임과 협력하여 컨테이너가 필요한 상태로 실행되도록 관리한다. kubelet 자체가 모든 프로세스를 직접 격리하는 런타임은 아니다. 명령 참조는 PodSpec을 실행 상태와 연결하는 역할을 설명한다.
어떻게 동작하는가
일반적인 Pod는 API 서버를 통해 전달되며, 제어면에서 정한 노드 위에서 kubelet이 실행을 관리한다. kubelet은 노드 상태와 Pod 상태를 보고하고, 볼륨 준비와 컨테이너의 재시작 정책 및 상태 확인에 관여한다. 정적 Pod처럼 로컬 파일에서 읽는 특수한 경로도 있으므로 모든 Pod의 소유자가 Deployment인 것은 아니다.
스케줄러가 어느 노드에 둘지 결정한다면 kubelet은 자신에게 배정된 작업을 그 노드에서 수행한다. 노드의 Ready 상태, 메모리·디스크 압박과 통신 상태는 배치·복구 판단에 영향을 준다. 노드 문서의 상태와 하트비트 설명은 노드 장애를 애플리케이션 오류와 구별하는 데 도움이 된다.
장점과 한계
노드마다 동일한 명세 해석과 상태 보고 경로를 두므로 중앙에서 개별 서버에 접속하지 않고도 실행 현황을 관리할 수 있다. 런타임 인터페이스를 통해 컨테이너 실행 구현과 상위 Kubernetes API를 분리하는 것도 장점이다.
그러나 kubelet이 정상이어도 이미지 다운로드, 볼륨 마운트, DNS, 애플리케이션 초기화는 각각 실패할 수 있다. 노드 상태를 한 줄의 정상·비정상으로만 판단하면 원인을 놓친다. kubelet에는 강한 노드 권한이 필요하므로 인증·인가와 접근 경로를 제한해야 하며, 설정을 무분별하게 바꾸는 것은 여러 Pod에 영향을 준다.
도서관 연습 노드 점검 예시
아래는 library-worker라는 연습 노드를 조회하는 예시다. 첫 명령들은 해당 클러스터의 읽기 권한, 마지막 명령은 systemd로 kubelet을 관리하는 그 노드의 로그 열람 권한을 전제로 한다. 서버나 Pod 설정을 바꾸지 않는다.
kubectl get node library-worker
kubectl describe node library-worker
journalctl -u kubelet --since "20 minutes ago" --no-pagerdescribe 출력에서 Conditions, 할당된 자원, 이벤트를 함께 살펴본다. 예를 들어 디스크 압박과 이미지 관련 오류가 동시에 나타나면 애플리케이션 코드를 고치기 전에 노드 저장 공간과 런타임 상태를 확인할 근거가 된다. 이벤트는 계속 누적되는 완전한 감사 기록이 아니므로 시간 범위를 맞춘 로그와 대조한다.
자주 생기는 오해
kubelet을 재시작하면 모든 애플리케이션 문제가 해결된다고 기대하지 않는다. 반복 재시작은 원인 분석에 필요한 흐름을 끊을 수 있다. 노드가 Ready여도 특정 Pod가 준비되지 않을 수 있고, Pod가 실행 중이어도 readiness 조건을 통과하지 못하면 서비스 트래픽을 받을 준비가 되지 않은 상태일 수 있다.