쿠버네티스를 공부하다가 갑자기 정적(static) 파드에 대해 뜬금없이 나와서 이게 무엇이고, 왜 중요한건지 헷갈렸다. 특히 스케줄러가 파드를 관리하고 배포한다고 했다가, 스케줄러 또한 파드인데
그것은 누가 띄우는 건지 의문이 생겨서 정리해보기로 했다.

쿠버네티스 기본 파드 배포 흐름

일반적으로 우리가 파드를 만들면 흐름은 다음과 같을 것이다.

kubectl apply 
				→ API Server 
                				→ Scheduler 
                                				→ Worker Node 
                                                 				=> Pod 생성

즉, 스케줄러가 파드의 배치를 결정한다.

그럼 여기에서 또 의문이 생긴다. 스케줄러도 파드인데 그 스케줄러를 누가 띄워주는 것인지.

쿠버네티스 구성 핵심 컴포넌트

쿠버네티스는 여러 핵심 컴포넌트들로 구성된다.

• etcd
• kube-apiserver
• kube-controller-manager
• kube-scheduler

(이 네 가지는 쿠버네티스가 작동하려면 반드시 먼저 실행되어야 한다.
또한 잘못 건들이면 복구가 쉽지 않기에 잘 건들이지 않는 부분들이다.)

그런데 스케줄러가 자기 자신을 띄울 수는 없다.
-> 이때 사용하는 방식이 바로 "정적(Static) 파드"이다.

정적 파드(Static Pod)란?

정적 파드는 스케줄러가 관리하지 않는 파드이다.
대신 kubelet이 직접 YAML 파일을 읽어서 생성한다.

kubelet은 다음 경로를 항상 확인을 하는데,

/etc/kubernetes/manifests/

이 폴더 안에 YAML 파일이 존재하면,

kubelet이 직접 읽고, 스케줄러를 거치지 않고 파드를 바로 생성한다.

즉,static pod는 쿠버네티스를 부팅하기 위한 파드라고 보면 된다.

정적 파드 구조

[ /etc/kubernetes/manifests/ ]  ← kubelet이 감시
        ├─ apiserver.yaml
        ├─ etcd.yaml
        ├─ controller-manager.yaml
        └─ scheduler.yaml

kubelet ─────→ 파일 감지 → 파드 자동 생성

정적 파드가 필요한 이유

쿠버네티스는 “쿠버네티스를 띄운 뒤”에야 스케줄러가 동작한다.
그러려면 스케줄러와 API 서버부터 먼저 "파드 형태"로 떠 있어야 한다.

이 순서를 가능하게 만드는 유일한 방법이 Static Pod 방식인 것이다.
따라서 Static Pod는 쿠버네티스의 시작점(bootstrap)이다.

어떤 컴포넌트가 Static Pod일까

• kube-apiserver
• etcd
• kube-controller-manager
• kube-scheduler

위 네 가지가 kubelet이 정적 파드 방식으로 직접 실행하는 정적파드이다.
그래서 이 파일들은

/etc/kubernetes/manifests/ 

안에 들어있다.

위처럼 노드 내부로 들어가서 경로에 접속해서 ls 로 보면 정적 파드 4개를 확인할 수 있다.

정리

• 일반 파드는 스케줄러 → 워커 노드 흐름으로 생성된다
• 하지만 스케줄러조차도 파드이므로, 먼저 띄워주는 존재가 필요하다
• 그래서 kubelet이 직접 실행하는 정적 파드(Static Pod) 구조를 사용한다
• /etc/kubernetes/manifests/ 안에 YAML만 넣으면 자동 생성된다

쿠버네티스의 핵심 요소 4개(apiserver, etcd, scheduler, controller-manager)는 Static Pod로 구성된다

참고자료:
[쿠버네티스 공식 홈페이지 - Create static Pods]
https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/?utm_source=chatgpt.com