Kubelet, Kube-proxy, Pod

k8s documentation, Cluster Architecture

Kubelet

Kubelet은 클러스터의 각 워커 노드에서 실행되는 에이전트로, 해당 노드의 모든 작업을 총괄하는 '현장 감독관' 또는 '선장' 과 같은 역할을 한다.

주요 역할

1. 노드 등록: apiserver와 통신하여 자신(노드)을 클러스터에 등록한다.
2. 파드 실행 지시: apiserver로부터 특정 파드를 실행하라는 명령을 받으면, 노드의 컨테이너 런타임(예: Docker)에게 해당 이미지를 가져와 컨테이너를 실행하도록 지시한다.
3. 상태 모니터링 및 보고: 노드 위에서 실행되는 파드와 컨테이너들의 상태를 지속적으로 감시하고, 그 결과를 주기적으로 apiserver에 보고한다.

설치 및 확인

Kubelet은 다른 컨트롤 플레인 컴포넌트와 달리, kubeadm으로도 자동 설치되지 않는다. 모든 워커 노드에 반드시 수동으로 설치하고 서비스로 실행해야 한다. 현재 실행 상태는 노드에서 ps aux | grep kubelet 명령어로 확인할 수 있다.

---

Kube-proxy

Kube-proxy는 클러스터의 모든 노드에서 실행되는 네트워크 프록시로, 클러스터 내의 '교통 경찰' 과 같은 역할을 한다.

왜 필요한가?

• 파드의 IP 주소는 언제든 바뀔 수 있어 불안정하다.
• 이를 해결하기 위해 서비스(Service) 라는 안정적인 가상 IP를 사용한다.
• 하지만 서비스는 실제 프로세스가 아닌 '가상' 개념이라 자체적으로 트래픽을 받을 수 없다.

역할 및 동작 방식

Kube-proxy는 이 문제를 해결한다. apiserver를 감시하다가 새로운 서비스가 생성되면, 각 노드에 네트워크 규칙(예: iptables 규칙) 을 프로그래밍한다. 이 규칙은 "서비스의 가상 IP로 들어오는 트래픽은 실제 파드의 IP로 전달하라"는 내용을 담고 있다. 덕분에 우리는 서비스의 고정된 주소로 파드에 안정적으로 접근할 수 있다.

배포 방식

Kube-proxy는 일반적으로 데몬셋(DaemonSet) 형태로 배포된다. 데몬셋은 클러스터의 모든 노드에 파드 인스턴스가 하나씩 실행되도록 보장하는 방식이다.

---

쿠버네티스 배포의 최소 단위, 파드(Pod)

쿠버네티스는 컨테이너를 노드에 직접 배포하지 않는다. 대신 컨테이너들을 파드(Pod) 라는 객체로 한번 감싸서 배포한다. 파드는 쿠버네티스에서 생성하고 관리할 수 있는 가장 작은 배포 단위다.

핵심 원칙: 1파드 = 1애플리케이션 인스턴스

• 스케일링: 애플리케이션의 부하가 늘어나면, 기존 파드에 컨테이너를 추가하는 것이 아니라 새로운 파드를 추가로 생성하여 확장한다. 부하가 줄면 파드를 삭제하여 축소한다.
• 멀티 컨테이너 파드: 드물지만, 하나의 파드에 여러 컨테이너를 넣을 수도 있다. 이는 주로 메인 애플리케이션을 보조하는 헬퍼(helper)나 사이드카(sidecar) 컨테이너가 필요할 때 사용한다.
  • 장점: 같은 파드 안의 컨테이너들은 네트워크와 스토리지를 공유하며, localhost로 서로 통신할 수 있다. 또한 생성되고 소멸하는 생명주기를 공유한다.

왜 컨테이너가 아닌 파드인가?

파드라는 추상화 계층 덕분에 복잡한 컨테이너 관리(네트워킹, 스토리지 공유, 생명주기 동기화 등)를 쿠버네티스가 자동으로 처리해 준다. 단일 컨테이너만 사용하는 간단한 앱이라도 쿠버네티스는 항상 파드 안에 넣어 배포함으로써, 미래의 아키텍처 변경 및 확장에 대비할 수 있게 한다.

기본 명령어

# 'nginx' 이미지를 사용하는 파드를 생성
kubectl run nginx --image=nginx

# 현재 클러스터의 파드 목록을 확인
kubectl get pods