1) About
쿠버네티스 클러스터가 구성되어 있지 않아서 마스터 노드가 존재하지 않는 경우 (ETCD, Kube Scheduler, Kube API Server 등이 없음), 단일 노드 내에 Kubelet과 Docker만 설치되어 있다면 Kubelet으로 무엇을 할 수 있을까?
→ Kubelet은 기본적으로 Pod를 생성할 수 있음
Kube API Server 없이 어떻게 yaml 파일을 Kubelet에게 제공할 수 있을까?
→ 특정 경로에 위치시키면 Kube API Server 없이도 Kubelet은 Pod를 정의한 yaml 파일을 읽어낼 수 있음
→ /etc/kubernetes/manifests
→ 반드시 위 경로가 아니더라도 특정 경로를 직접 지정할 수 있음
→ Kubelet이라는 서비스를 실행할 때는 —-pod-manifest-path로 경로를 줄 수 있는데, 여기에 원하는 경로를 기입하면 됨 (kubeadm X)
→ 혹은 —config 옵션으로 config 파일을 명시하고, 해당 config 파일 내에 staticPodPath를 기입하여도 동일하게 동작 (kubeadm O)
Kubelet은 주기적으로 해당 경로를 확인하여 Pod를 생성함
단순히 Pod만 생성하는 것이 아니라 Pod의 상태에 문제가 생겨 다운되면 다시 생성한다든가, 디렉토리 내에 있는 yaml 파일의 내용을 변경하면 해당 변경점을 반영하기 위해 Pod를 재생성하는 식으로 동작
경로 내에 yaml 파일을 지우게 되면 Pod 역시 삭제로 이어짐
이와 같이 Kube API Server의 개입 없이 생성된 Pod들을 Static Pod라고 함
** Kubelet은 항상 일하는 단위가 Pod이기 떄문에 다른 객체를 이해하지는 못함
2) Kube API Server
Kube API Server가 있을 때도 Static Pod를 생성할 수 있을까?
→ 못 할 이유가 전혀 없음
Kubelet 자체의 역할이 Static Pod 생성 외에도, 노드에 배정된 Pod 정의를 확인하여 Pod를 생성하는 것
즉, Kubelet은 Static Pod를 생성하기 위해 staticPodPath를 확인함과 동시에 Pod를 생성하기 위해 ETCD Cluster에서 Kubelet 자신이 속한 노드에 배정된 Pod를 확인하는 과정을 거침
그렇다면 Static Pod를 Kube API Server가 인식할 수 있을까?
→ 인식할 수 있음
Kubelet이 Static Pod를 생성할 때 Kube API Server와 연결되어 있다면, Kube API Server에 해당 Pod를 미러링 객체를 만들도록 요청
이러한 미러링 객체는 읽기 전용이기 때문에 상태나 상세 정보는 확인할 수 있지만, 편집과 삭제는 불가능하고 이와 같은 작업을 하려면 Kubelet이 갖고 있는 staticPodPath 경로에서 정의 파일을 직접 건드려야함
3) Why
Static Pod는 쿠버네티스의 제어 (Control Plane)에 의존적이지 않음
따라서 Control Plane의 요소를 Pod로 노드에 배포하는데 유용하게 사용할 수 있음
예를 들어 마스터로 사용할 노드 내에 Kubelet을 설치하고, Control Plane의 구성 요소에 해당되는 이미지 (Controller Manager, ETCD, API Server)를 사용하여 Pod 정의 파일을 만든 뒤, staticPodPath에 위치 시키면, 마스터 노드를 구성하는 요소들을 Static Pod로 관리할 수 있게 됨
이와 같이 Static Pod를 구성하면 Control Plane에 해당하는 요소들의 구성 절차를 줄이고 서비스 간의 충돌과 서비스의 다운을 걱정하지 않아도 됨
이러한 방식으로 쿠버네티스의 클러스터를 설정할 수 있으며, 실제로 kubeadm이 클러스터를 이렇게 설정함
4) vs Daemon Set
Kube Scheduler가 Static Pod 및 Daemon Set에 영향을 끼치지 않는 것은 동일하지만, Static Pod는 Kubelet이 생성하고 Daemon Set은 Kube API Server에 의해 생성됨
사용 예시에도 차이가 있는데, Static Pod는 쿠버네티스 클러스터를 구성하기 위한 Control Plane을 배포하는데 사용되고, Daemon Set은 모니터링 에이전트 및 로그 수집기 등을 배포하는데 사용됨
5) Commands
생성된 Static Pod들은 Kube API Server 등 클러스터가 구성되기 이전에는 kubectl로 확인할 수가 없으므로, 이런 경우엔 docker 명령어를 통해 확인할 수 있음
** docker ps