정적 파드

정적 파드 (Static Pods)

정적 파드(Static Pod)는 특정 노드의 kubelet 데몬이 API 서버의 관찰 없이 직접 관리해요. 컨트롤 플레인이 관리하는 파드(예: Deployment)와 달리, kubelet은 각 정적 파드를 감시하고 실패하면 재시작해요.

정적 파드는 항상 특정 노드의 한 kubelet에 바인딩돼요.

정적 파드의 주요 용도는 자체 호스팅(self-hosted) 컨트롤 플레인을 실행하는 것이에요. 즉 kubelet을 사용해 개별 컨트롤 플레인 컴포넌트를 감독하는 거예요. 예를 들어 kubeadm은 정적 파드를 사용해 컨트롤 플레인 노드에서 kube-apiserver, kube-controller-manager, kube-scheduler, etcd를 실행해요.

참고: 클러스터가 컨트롤 플레인 컴포넌트를 파드로 실행한다면, 그것들은 아마 정적 파드일 거예요. kube-system 네임스페이스에서 kubernetes.io/config.mirror 어노테이션으로 미러 파드(mirror Pod)를 알아볼 수 있어요.

출처: 문서

본문

미러 파드 (Mirror Pods)

kubelet은 각 정적 파드에 대해 쿠버네티스 API 서버에 미러 파드를 자동으로 만들려고 시도해요. 이는 노드에서 실행되는 파드가 API 서버에 보이지만, 거기에서 제어할 수는 없다는 뜻이에요. 파드 이름에는 앞에 하이픈이 붙은 노드 호스트네임이 접미사로 붙어요.

kubelet은 정적 파드의 라벨을 미러 파드로 전파해요. 그 라벨을 셀렉터를 통해 평소처럼 사용할 수 있어요.

kubectl로 API 서버에서 미러 파드를 삭제하려고 시도해도 kubelet은 정적 파드를 제거하지 않아요. kubelet은 미러 파드를 다시 생성할 거예요.

제한 사항 (Limitations)

정적 파드의 스펙은 ServiceAccount, ConfigMap, Secret 같은 다른 API 객체를 참조할 수 없어요.

정적 파드는 임시 컨테이너(ephemeral containers)를 지원하지 않아요.

정적 파드와 DaemonSet (Static Pods vs DaemonSets)

클러스터형 쿠버네티스를 실행하고 정적 파드를 사용해 모든 노드에 파드를 실행한다면, 아마 DaemonSet을 사용하는 것이 더 나아요.

정적 파드는 컨트롤 플레인이 관리하지 않으므로 표준 쿠버네티스 메커니즘으로 롤아웃, 롤백, 스케일링할 수 없어요. DaemonSet은 이러한 기능을 제공하며 노드 레벨 워크로드 실행의 권장 방법이에요.

정적 파드는 API 서버를 사용할 수 있기 전에 kubelet이 시작하기 때문에 컨트롤 플레인 컴포넌트 부트스트래핑에 적합해요. DaemonSet은 실행 중인 컨트롤 플레인이 필요해요.

다음 단계 (What's next)

정적 파드를 만드는 방법 배우기
쿠버네티스 컴포넌트와 컨트롤 플레인이 정적 파드를 사용하는 방법 배우기
정적 파드의 대안으로 DaemonSet에 대해 배우기