Static Pods

 

 

일반적으로 파드는 컨트롤 플레인에 의해 스케쥴링되고 관리됩니다.

kubelet은 worker node에서 동작하는 컨트롤러로 master node의 api server, kube scheduler와 상호작용하여 해당 노드에 어떤 리소스를 배치할지 정합니다.

 

그럼 만약 ectd, kube-apiserver, kube-scheduler가 없으면 어떻게 될까요?

 

kubelet은 단독으로 pod 생성과 관리가 가능합니다.

api server가 없으므로 kubelet은 로컬 내 디렉토리를 설정하고 해당 디렉토리 안의 pod definition file을 사용하여 pod를 생성 및 관리합니다.

 

이렇게 kubelet이 api server의 개입 없이 단독으로 생성하고 관리하는 pod를 static pod라고 합니다.

 

주의) kubelet은 오직 pod만 위의 과정으로 생성 가능합니다.

해당 디렉토리에 pod외의 리소스(service, deployment 등)의 definition file 배치해도 생성되지 않습니다.

 

pod definition file의 디렉토리 위치

 

--pod-manifest-path=/etc/kubernetes/manifests

--config=kubeconfig.yaml

 

kubelet.service의 —pod-manifest-path 혹은 —config 옵션에서 디렉토리 위치를 확인 가능합니다.

 

• kubelet 이 구동 될 때 --pod-manifest-path 옵션에 의해 kubelet이 감시할 디렉터리가 결정됩니다.

(default: /etc/kubernetes/manifests)

 

만약 위의 옵션들을 찾을 수 없으면?

 

kubelet의 config.yaml의 staticPodPath에서 확인 가능.

 

config.yaml의 위치는 보통 /var/lib/kubelet/config.yaml

kubelet.serive 파일 위치는 systemctl status kubelet 의 loaded에서 확인 가능합니다.

systemctl status kubelet 명령어 실행 결과

 

vi  /lib/systemd/sytem/kubelet.service 명령어 실행 결과

 

"KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"

/var/lib/kubelet/config.yaml 에서 확인 가능

 

kubelet이 감시하는 디렉토리 내의 yaml 파일들

 

현재 static pod definition 파일의 개수: 4개

 

Static pod 확인

kubelet이 static pod를 생성할 때, mirror object를 kube-apisever에도 생성하기 때문에 docker ps 명령어로 확인 가능합니다.

따라서 api server도 static pod 감지가 가능하기에 get 명령어로 확인할 수 있지만, 이는 mirror 버전이므로 kubectl 명령어로 수정 및 삭제는 불가능합니다.

 

 

kubelet은 디렉토리 파일 내의 pod definition file / 마스터 노드의 kube-apiserver 둘 다를 통해서 pod 생성 가능합니다.

 

이름은 자동으로 매겨집니다. (ex. static-web-node01)

예와 같이 pod 이름 뒤에 해당 노드의 이름이 붙으며, 이를 통해 static pod 구분이 가능합니다.

 

위 환경에서는 controlplane, node01 노드가 존재하고 get 명령어 사용 시 이름 뒤에 해당 노드가 존재하는 pod는 etcd-controlplane, kube-apiserver-controlplane, kube-controller-manager-controlplane, kube-scheduler-controlplane 이므로 이 4개가 static pod입니다.

 

더 자세한 확인을 위해 각 pod의 yaml 의 ownerReferences 을 확인할 수 있습니다.

 

위는 DaemonSet이 관리하는 pod, 아래는 static pod.

 

kind: Node, name: [node 이름] 이면 static pod입니다.

 

Use case

 

주로 static pod는 컨트롤 플레인 컴포넌트(api server, scheduler, controler manager)를 노드에 배포하는 데 사용됩니다.

혹은 쿠버네티스 컨트롤 플레인에 의존하지 않는 파드를 배포할 때 사용합니다.

Create a static pod named static-busybox that uses the busybox image and the command sleep 1000

kubectl run static-busybox --image=busybox --dry-run=client -o yaml --command -- sleep 1000 > static-busybox.yaml

 

주의) --command -- 뒤에 오는 명령어는 전부 command 로 간주하므로 kubectl 명령어는 --command 전에 작성해야 합니다.

static pod의 yaml을 변경하면 자동으로 kubelet이 변경사항을 적용해줍니다.

yaml 파일을 /etc/kubernetes/manifests 에 생성하면 static-busybox-controlplane static pod가 생성됨

 

We just created a new static pod named static-greenbox. Find it and delete it.

 

greenbox는 node01에 속하므로 node01로 접속합니다.

ssh node01 혹은 ssh [internal ip] 를 사용하여 ip를 확인할 수 있습니다.

 

node01의 /var/lib/kubelet/config.yaml 확인 시 staticPodPath가 바뀐 것을 확인 가능합니다.

바뀐 staticpodpath

 

새로운 staticPodPath에서 rm 명령어로 static-greenbox.yaml 을 삭제하고 exit 하여 controlplane으로 돌아오면 해당 pod가 사라진 것을 확인할 수 있습니다.

 

 

 

참고

Certified Kubernetes Adiminstrtor(CKA) with Practice Tests by Mumshad Mannambeth, KodeKloud Training