Static Pods

kubelet은 worker node에서 독립적으로 container를 구동할 수 있다. 즉, master node의 kube-apiserver, etcd 등과 연결이 안되었을 때에도 pod를 만들 수 있다는 것이다.

kubelet만으로 worker node에서 master node의 도움없이 pod를 만들고 관리하기 위해서는, 먼저 pod에 대한 definition file이 필요하다. 이 다음, pod definition file을 kubelet option에 지정한 directory로 옮겨놓으면 된다.

가령 pod1.yaml을 kubelet option으로 지정한 /etc/kubernetes/manifests directory라면, 해당 directory에 pod1.yaml을 옮겨놓기만 하면 된다.

pod가 생성될 것이고, pod가 다운되면 kubelet이 자동으로 복구해주고, 만약 pod1.yaml file을 수정하면, 변화가 적용된 pod를 새로 만들어주고, pod1.yaml을 삭제하면 pod도 삭제해준다.

단, pod만 생성할 수 있지 ReplicaSet, Deployment와 같이 master node의 controller가 필요한 경우는 불가능하다.

그럼 이 directory는 어떻게 설정가능한가?? kubelet.service를 보면 다음과 같은 option이 있다.

• kubelet.service

ExecStart=/usr/local/bin/kubelet \\
  --container-runtime=remote \\
  ...
  --pod-manifest-path=/etc/kubernetes/manifests \\
  ...

pod-manifest-path가 바로 이 directory를 지정하는 option인 것이다.

또 다른 방법으로는 kubelet에 kubeconfig.yaml파일을 config로 제공하면서, kubeconfig.yaml에서 staticPodPath를 지정하는 방법이 있다.

• kubelet.service

ExecStart=/usr/local/bin/kubelet \\
  --container-runtime=remote \\
  ...
  --kubeconfig=/var/lib/kubelet/kubeconfig \\
  ...

• kubeconfig.yaml

staticPodPath: /etc/kubernetes/manifests

단, 우선순위는 --pod-manifest 옵션이 더 높기 때문에 --pod-manifest가 없다면 --kubeconfig로 따라가서 보면 된다.

이렇게 pod를 생성했다면, pod가 생성되었는 지를 확인하기 위해서 다음의 명령어를 사용하면 된다.

• docker

docker ps

• cri-o

crictl ps

• containerd

nerdctl ps

왜 kubectl이 아니라 docker와 같은 container 명령어를 쓰냐면, 이 상황은 이미 master node가 떨어져 나간 상황이기 때문이다.

만약, master node가 다시 붙으면 kubectl을 통해서 kubelet으로 배포한 pod를 확인할 수 있다. 이는 kubelet에서 kube-apiserver에 생성된 pod를 mirror했기 때문이다.

kubectl get nodes
NAME                READY   STATUS              RESTARTS    AGE
static-web-node01   0/1     ContainerCreating   0           29s

잘보면 node01이 붙어있는 것을 볼 수 있다. 이는 자동으로 pod를 생성할 때 kubelet에서 해당 worker node 접미사에 붙여준 것이다.

단, 해당 pod는 kubectl을 통해서, 즉, kube-apiserver를 통해서 수정, 삭제가 불가능하다. 오직 해당 worker node의 지정된 directory에서 pod definition을 수정, 삭제해야 적용된다.

그런데, 왜 static pod를 사용하는 것일까?? static pod로 만들면 다른 pod들에게 간섭받지 않고, 계속해서 node에서 동작한다는 특성이 있다. 즉, kube-apiserver에 영향을 받지 않는다는 특징이 있다.

이에 따라 kubeadm을 통해 master node를 만들 때, master node를 구성하는 controller-manager, apiserver, etcd 등을 static pod로 만들기 위해 지정된 directory에 pod 정의 파일을 놓는다. 즉 /etc/kuberntes/manifests에 controller-manager.yaml, apiserver.yaml, etcd.yaml을 놓는 것이다. 이렇게 하면 master node의 kubelet에 의해 control plane object들이 관리받는 것이다.

마지막으로 static pod와 daemonset을 비교해보도록 하자.

	Static Pods	Daemonsets
생성 주최	kubelet	kube-apiserver(daemonset controller)
용도	control plane component들을 static pod로 배포	각 node에 대한 모니터링 에이전트, 로깅 툴
공통점	kube-scheduler에 영향을 받지 않는다.