[쿠버네티스] Static Pod vs Dynamic Pod: 누가 Pod를 관리하는가?

Static Pod vs Dynamic Pod

지난 시간에는 Kubernetes에서 가장 기본이 되는 실행 단위인 Pod에 대해 간략히 살펴보았습니다.

이번 글에서는 Pod의 생성 및 관리 방식에 따라 구분되는 정적 Pod(Static Pod)와 동적 Pod(Dynamic Pod)에 대해 알아보겠습니다.

Kubernetes 환경에서 우리가 일반적으로 생성하고 관리하는 Pod는 대부분 API Server를 통해 생성되는 동적 Pod입니다. 반면, 정적 Pod는 kubelet이 특정 노드에서 직접 관리하는 Pod로, API Server를 거치지 않고 노드에 배치된 manifest 파일을 기준으로 실행됩니다.

즉, 두 Pod의 가장 큰 차이는 누가 Pod를 생성하고 관리하느냐입니다. 동적 Pod는 Kubernetes Control Plane이 관리하고, 정적 Pod는 각 노드의 kubelet이 직접 관리합니다. 이번 글에서는 정적 Pod와 동적 Pod의 개념, 동작 방식, 그리고 실제 운영 환경에서 어떤 차이가 있는지 정리해보겠습니다.

Static Pod

정적 파드는 각 노드의 kubelet이 노드에 있는 매니페스트 파일을 직접 읽어 생성 / 관리하는 파드로, 특정 노드에 고정되어 항상 떠 있어야 하는 파드에 주로 사용됩니다.

 

정적 파드의 대표적인 예시는 Master Node, 즉 Control Plane Node에서 구동되는 주요 Control Plane Pod들입니다. Kubernetes 클러스터를 구성하면 Master Node 내부에는 kube-apiserver, kube-controller-manager, kube-scheduler, etcd와 같은 핵심 구성 요소들이 실행됩니다.

이 Pod들은 일반적인 Deployment나 ReplicaSet을 통해 생성되는 것이 아니라, 각 노드의 /etc/kubernetes/manifests 경로에 위치한 YAML 파일을 kubelet이 직접 감지하여 실행합니다.

 

조금만 생각해 보면 Control Plane Pod들을 왜 정적 파드로 운영하는지 알 수 있습니다. 만약 kube-apiserver, kube-scheduler, kube-controller-manager, etcd 같은 Control Plane 구성 요소들을 정적 파드가 아닌 동적 파드로 생성한다고 가정해 보겠습니다.

동적 파드는 기본적으로 Kubernetes API Server를 통해 생성 요청이 들어가고, Scheduler가 어느 노드에 배치할지 결정한 뒤, kubelet이 해당 Pod를 실행하는 구조입니다.

그런데 여기서 문제가 발생합니다.

API Server 자체가 아직 실행되지 않은 상태라면, 동적 파드를 생성하기 위한 요청을 받을 수 없습니다. 또 Scheduler가 실행되지 않았다면, 해당 Pod를 어느 노드에 배치할지도 결정할 수 없습니다.

즉, Control Plane을 동적 파드로 운영하려고 하면 Control Plane이 떠 있어야 Control Plane Pod를 만들 수 있는 모순적인 상황이 발생합니다.

 

 

Static Pod는 API Server나 Scheduler를 통해 생성되는 일반적인 Pod와 달리, 특정 노드의 kubelet이 직접 관리하는 Pod입니다. 관리자가 Pod YAML manifest 파일을 작성한 뒤 /etc/kubernetes/manifests 경로에 배치하면, kubelet은 해당 경로를 감시하다가 파일 생성을 감지합니다. 이후 manifest 내용을 기준으로 Container Runtime에 컨테이너 생성을 요청하고, 필요한 이미지는 Registry에서 Pull하여 Pod를 실행합니다.

Static Pod가 생성되면 kubelet은 해당 정보를 API Server에 Mirror Pod 형태로 등록합니다. 이 때문에 사용자는 kubectl get pod 명령어로 Static Pod를 조회할 수 있습니다.

하지만 실제 Static Pod의 생성, 수정, 삭제는 API Server가 아니라 노드의 manifest 파일을 기준으로 kubelet이 수행합니다. 따라서 Static Pod를 완전히 삭제하려면 kubectl delete pod가 아니라 /etc/kubernetes/manifests 경로의 YAML 파일을 삭제해야 합니다.

결국 Static Pod의 핵심은 kubelet이 직접 manifest 파일을 감시하고 실행하는 Pod이며, API Server에는 조회를 위한 Mirror Pod 형태로 등록된다는 점입니다.

 

Dynamic Pod

이번에는 Static Pod와 반대되는 개념으로 이해할 수 있는 Dynamic Pod에 대해 알아보겠습니다. 먼저 Dynamic Pod라는 표현은 Kubernetes에서 별도의 리소스 타입을 의미하는 공식 명칭이라기보다는, 일반적으로 API Server를 통해 생성되고 Control Plane에 의해 관리되는 Pod를 설명할 때 사용하는 표현입니다.

우리가 Kubernetes에서 일반적으로 생성하는 대부분의 Pod는 Dynamic Pod라고 볼 수 있습니다.

예를 들어 Deployment, ReplicaSet, DaemonSet, StatefulSet, Job 등을 통해 생성되는 Pod들이 여기에 해당합니다.

Dynamic Pod는 사용자가 직접 특정 노드에 YAML 파일을 배치해서 실행하는 방식이 아닙니다.
사용자가 kubectl apply 명령어나 배포 도구를 통해 Kubernetes API Server에 생성 요청을 보내면, Control Plane이 해당 요청을 처리하고 Pod를 생성합니다.

 

Dynamic Pod의 기본 생성 흐름은 다음과 같습니다.

1. 사용자가 Pod 또는 Deployment YAML 파일을 작성합니다.
2. kubectl apply 명령어를 통해 API Server에 생성 요청을 보냅니다.
3. API Server는 요청 내용을 검증한 뒤 etcd에 저장합니다.
4. Scheduler는 아직 노드가 배정되지 않은 Pod를 확인합니다.
5. Scheduler는 리소스 상태와 스케줄링 조건을 기준으로 적절한 Worker Node를 선택합니다.
6. 선택된 노드의 kubelet은 API Server를 통해 자신에게 할당된 Pod 정보를 확인합니다.
7. kubelet은 Pod 명세를 기준으로 Container Runtime에 컨테이너 생성을 요청합니다.
8. Container Runtime은 필요한 이미지를 Registry에서 Pull한 뒤 컨테이너를 실행합니다.
9. 컨테이너가 정상 실행되면 Pod는 Running 상태가 됩니다.

즉, Dynamic Pod는 kubelet이 단독으로 생성하는 것이 아니라, API Server, Scheduler, Controller Manager, kubelet, Container Runtime이 함께 동작하면서 생성됩니다.

여기서 중요한 점은 Dynamic Pod는 Control Plane의 관리 대상이라는 점입니다.

예를 들어 Deployment로 Pod를 3개 생성했다고 가정해 보겠습니다. 이 중 하나의 Pod가 장애로 종료되면 ReplicaSet Controller는 현재 실행 중인 Pod 수가 원하는 개수보다 부족하다는 것을 감지합니다.

그 후 새로운 Pod 생성을 API Server에 요청하고, Scheduler는 다시 적절한 노드를 선택합니다. 선택된 노드의 kubelet은 새 Pod를 실행하게 됩니다. 이처럼 Dynamic Pod는 단순히 한 번 생성되고 끝나는 것이 아니라, Kubernetes Controller에 의해 지속적으로 관리됩니다.

반면 Static Pod는 특정 노드의 /etc/kubernetes/manifests 경로에 있는 manifest 파일을 kubelet이 직접 감시하고 실행합니다. Scheduler가 노드를 선택하지 않으며, API Server가 실제 생성 주체도 아닙니다.

Dynamic Pod는 API Server를 통해 생성 요청이 들어오고, Scheduler와 Controller의 제어를 받아 kubelet이 실행하는 일반적인 Kubernetes Pod입니다.

실제 운영 중인 대부분의 워크로드는 Dynamic Pod로 운영되기 때문에, API Server부터 Scheduler, kubelet, Container Runtime까지 이어지는 배포 흐름을 이해하고 있어야 합니다.