📌 Static Pods

• kubelet 은 kube-apiserver에 의존해 노드에서 로드할 pod에대한 지시를 받음
• 이는 kube-scheduler의 결정에 근거한 것으로 etcd-cluster(데이터 저장소)에 저장됨
• 만약 kube-apiserver 나 kube-scheduler controller, etcd-cluster가 없다면?
• 또는 master node가 없다면?

🧭 kubelet은 node를 독립적으로 관리 할 수 있다.

• worker node에는 kubelet과 docker가 있다
• kube-apiserver는 없다
• kubelet가 아는건 pod를 만드는것 뿐
• 하지만 pod의 상세 정보를 제공할 kube-apiserver는 존재하지 않는다.
• pod를 만드려면 세부 정보가 (yaml파일)이 있어야한다.
• /etc/kubernetes/manifests 디렉터리를 통해 pod의 Definition 파일을 읽을 수 있다.
• 이 디렉터리에 pod 정의 파일을 넣으므로서 static pod 생성 가능
• kubelet은 주기적으로 이 디렉터리에 파일을 확인하고 읽고 호스트에 pod를 만든다.
• pod 생성 뿐 아니라 죽지 않도록 보장 할 수 있다.
• 정의 파일을 수정하면 kubelet이 즉시 수정한다.
• 이 디렉터리에 정의파일을 삭제하면 kubelet이pod를 즉시 삭제한다.

👉Static Pods

• kubelet 스스로 만든 이 pod는 api-server의 간섭이나 나머지 K8S 클러스터 구성요소의 간섭이 없다
• 지정된 디렉토리에 Definition 파일을 준다고 ReplicaSet이나 Deployment는 생성할 수 없다.
• 사실 kubelet의 옵션으로 static pods를 생성할 디렉토리를 설정할 수 있다.

# kubelet.service 옵션으로 경로 static pods 경로 설정

ExecStart=/usr/local/bin/kubelet
<중략>
  --pod-manifest-path=/etc/Kubernetes/manifest \\
<중략..>

# kubelet.service config 옵션으로 구성파일에 경로 설정

ExecStart=/usr/local/bin/kubelet
<중략>
  --config=kubeconfig.yaml \\
<중략..>

# kubeconfig.yaml
staticPodPath: /etc/Kubernetes/manifests

• kubeadm에 셋업한 클러스터는 이와같은 config 방식을 사용함
• 이를 확인하면 static pod의 정의파일이 어디에 위치하는지 경로를 알 수있다.

⚙️ static pod 생성

💡쿠버네티스 클러스터 구성 전

• docker ps 명령 실행, (클러스터 구성전 static pod 사용할 경우)
• kubectl 명령은 kube-apiServer와 작동한다.

⚒️ 쿠버네티스 클러스터 구성 후

• 노드가 클러스터의 일부일 때는?
• pod를 만들라고 kubelet 에 요청하는 api-server가 있을때를 가정
• kubelet은 두 종류의 pod를 동시에 만들수 있는가?
• 가능하다

1. static pod 폴더에서 정의 파일을 통해 가능하고
2. HTTP API 엔드포인트를 이용해 가능하다.

• apiserver가 kubelet에 입력을 제공받는 방법이다.

❓Kube-ApiServer가 Static Pod를 인식할 수 있는가?

• api서버는 kubelet이 만든 static pod를 인지한다.
• kubelet이 static pod를 만들때 그게 클러스터 개체에 속해있다면 읽기전용과 같아서 세부사항을 볼 수는 있지만 api-server가 static pod를 수정할 수는 없다.
• 오직 해당노드의 manifest 폴더에서의 파일을 수정하거나 삭제가 가능하다.

🤔 왜 static pod를 사용하는가?

• static pod를 이용해 control plane(master node)의 구성 요소를 노드에 있는 포드 처럼 배포 할 수 있음
• 구성요소
  • api-server
  • controller-manager
  • etcd
• 위 구성요소는 모두 pod형태로 마스터 노드에 배포되어 있다.
• /etc/kubernetes/manifests 폴더에 yaml 파일 형태로 정의 되어있다.

🚀 바이너리 파일을 다운로드 할 필요가 없고 서비스를 구성하거나 서비스가 다운될까 걱정할 필요가 없음

• 이 중 하나가 다운된다 하더라도 static pod 이기 때문에 자동으로 해당 노드에 재시작 한다.

$ kubectl get pods -n kube-system

• 위 명령어로 control-plane에 생성된 요소를 pod로 볼 수 있다.

⚔️ static Pods vs DaemonSets

• DaemonSets은 모든 클러스터 내 모든 노드에서 애플리케이션 인스턴스가 사용가능하도록 함
• 반면 static pod는 kubelet이 직접 만든다 (kube-apiserver 나 K8S control-plane의 다른 방해요소는 없다)
• static pod는 control plane의 구성요소 자체를 배포하는데 주로 사용
• 공통점은 kube-Scheduler의 영향을 받지 않는다는 점