Static Pods

• K8S 클러스터에서 master node와 다른 worker node 없이 오로지 하나의 worker node만 있다면?
• kubelet은 특정 디렉토리의 definition 파일들을 보고 pod 생성하는 것 뿐 아니라 pod가 살아있는지 확인함
• kubelet은 app crash나면 restart도 시키고, 변경 사항이 생기면 recreate도 함
• 이 디렉토리에서 yaml 삭제하면 pod도 삭제됨
• Static pod : API Server의 개입 없이 kubelet이 자체적으로 생성한 pod
• replicaset나 deployment나 service는 이 디렉토리에 definition 넣어도 생성 못함. 이것들은 master node의 controller가 필요하기 때문.
• directory는 어느 위치에나 할 수 있고 위치 설정은 kubelet이 처음에 뜰 때 지정 가능
• kubelet.service 세팅에 --pod-manifest-path 옵션으로 설정되어 있고, default는 /etc/kubernetes/manifests
• kubelet.service 세팅에 --config 옵션으로 config.yaml파일에서도 지정할 수 있음.
  config파일 위치는 /var/lib/kubelet/config.yaml. yaml파일에서는 ststicPodPath: 로 선언
• static pod는 docker ps 로 확인 가능. kubectl 을 못 쓰는 이유는 master node가 없다고 가정했기 때문.
• kubelet이 pod를 생성하는 경우는 위처럼 static pod 로 생성하는 경우 하나와, kube-apiserver에서 받는 http api endpoint
• static pod도 master node에서 인지하고 있음. 이는 kubelet이 static pod 생성할 때 kubeapi server에 똑같은 object 생성. kube-apiserver에서는 readonly mirror pod 만 보임. 그러므로 일반적인 pod와는 다르게 edit이나 delete 불가
• kubectl get po 하면 static pod의 이름의 끝에 nodename이 자동적으로 붙음
• Static Pod 사용 이유
  • Kubernetes control plane에 독립적
  • master node에 필요한 api server pod들의 manifest 폴더에 추가해 놓으면 신경쓰지 않아도 kubelet은 알아서 static pod들 새로 띄움
  • 이 방식이 kubeadm이 k8s cluster 구성하는 방식
  • kubectl get po -n kube-system 에 나오는 pod들
• DaemonSet과의 비교
  • DaemonSet은 각 worker node에 최소 하나씩은 띄워야할 때 사용하며, kube-api server의 daemonset controller가 필요함
  • Static Pod는 kubelet이 생성. static pod는 kubernetes control plane components를 생성할 수 있음.
  • 두 형태의 pod 모두 kube-scheduler의 영향을 받지 않음.