⚡

[CKA] 22. Static PODs

Date

2024/11/30

Kubelet

•

kubelet은 kube-api Server에 의존하여 Node에 로드할 Pod에 대한 지시를 받음

◦

이는 kube-scheduler의 결정에 근거한 것으로, etcd에 저장됨

•

kubelet은 node를 독립적으로 관리하는 것이 가능함

◦

kube-apiserver, etcd, kube-scheduler 등 없이 Pod 생성 및 관리

◦

/etc/kubernetes/manifests 에 생성된 정의 파일을 kubelet이 읽는 것이 가능

◦

Pod에 변화가 생기면 Kubelet은 Pod를 Restart

◦

/etc/kubernetes/manifests 에서 정의 파일을 제거하면 해당 Pod는 자동으로 삭제

API Server의 간섭이나 나머지 Kubernetes Cluster 구성요소의 간섭 없이 Kubelet이 만든 Pod

•

반드시 /etc/kubernetes/manifests 에 정의 파일이 작성되어야 함

•

단일 Pod만 생성 가능하며, ReplicaSet이나 Deployment는 생성할 수 없음

◦

Kubelet은 Pod level에서 동작하며 Pod만 이해할 수 있기 때문

•

kubelet level에서 생성된 Static Pod도 kube-apiserver가 인지함

◦

readonly 객체로만 읽히기 때문에 일반 Pod처럼 편집이나 삭제는 불가능

◦

오직 /etc/kubernetes/manifests에서만 수정 및 삭제 가능

•

Static Pod를 생성하는 /etc/kubernetes/manifests 라는 지정된 디렉터리는 실제로 아무 디렉터리든 될 수 있음

•

kubelet.service의 옵션으로 디렉터리를 설정

◦

기본값으로 /etc/kubernetes/manifests 가 설정됨

•

kubelet.service 파일에 직접 path를 제공하면 다르게 설정 가능

•

kubeconfig.yaml 파일에 staticPodPath를 설정

•

kubeadm으로 셋업한 클러스터는 이런 접근법을 사용함

클러스터의 다양한 셋업에 따라 해당 내용이 변경될 수 있기 때문에 어떤 클러스터든 검사할 때는 kubelet의 옵션을 확인해야 함

kubelet.service의 pod-manifest-path 옵션 확인

없을 경우, config option 확인

config file이 있는 경우 staticPodPath 옵션 확인

•

Static Pod는 controlplane에 의존하지 않기 때문에 controlplane 구성요소(api-server, etcd, …)를 Node에 배포할 수 있음

모든 master node에 kubelete 설치

controlplane components(apiserver, etcd, controller, …)를 도커 이미지를 사용해 Pod 정의 파일 생성

Definition file을 지정된 manifest 폴더에 위치

kubelet이 Pod를 배포 및 관리

→ 따로 바이너리나 configure service를 다운하지 않아도 되며, Crash가 발생해도 자동으로 restart됨

•

kubeadm으로 셋업된 클러스터는 kube-system에 Pod로 components들을 가지고 있음

Static Pod는 kube-apiserver나 다른 구성 요소의 간섭을 받지 않음
DaemonSet은 kube-apiserver에 의해 생성됨

Static Pod는 controlplane components 자체를 배포 가능

둘 모두 Kube-Scheduler의 영향을 받지 않음