목차
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는 자동으로 삭제
Static 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에서만 수정 및 삭제 가능
Designated Folder
•
Static Pod를 생성하는 /etc/kubernetes/manifests 라는 지정된 디렉터리는 실제로 아무 디렉터리든 될 수 있음
•
kubelet.service의 옵션으로 디렉터리를 설정
◦
기본값으로 /etc/kubernetes/manifests 가 설정됨
Changing Path
•
kubelet.service 파일에 직접 path를 제공하면 다르게 설정 가능
•
kubeconfig.yaml 파일에 staticPodPath를 설정
•
kubeadm으로 셋업한 클러스터는 이런 접근법을 사용함
Inspecting Cluster
클러스터의 다양한 셋업에 따라 해당 내용이 변경될 수 있기 때문에 어떤 클러스터든 검사할 때는 kubelet의 옵션을 확인해야 함
1.
kubelet.service의 pod-manifest-path 옵션 확인
2.
없을 경우, config option 확인
3.
config file이 있는 경우 staticPodPath 옵션 확인
Reasons for using Static Pods
•
Static Pod는 controlplane에 의존하지 않기 때문에 controlplane 구성요소(api-server, etcd, …)를 Node에 배포할 수 있음
1.
모든 master node에 kubelete 설치
2.
controlplane components(apiserver, etcd, controller, …)를 도커 이미지를 사용해 Pod 정의 파일 생성
3.
Definition file을 지정된 manifest 폴더에 위치
4.
kubelet이 Pod를 배포 및 관리
→ 따로 바이너리나 configure service를 다운하지 않아도 되며, Crash가 발생해도 자동으로 restart됨
•
kubeadm으로 셋업된 클러스터는 kube-system에 Pod로 components들을 가지고 있음
Static PODs vs DaemonSets
1.
Static Pod는 kube-apiserver나 다른 구성 요소의 간섭을 받지 않음
DaemonSet은 kube-apiserver에 의해 생성됨
2.
Static Pod는 controlplane components 자체를 배포 가능
3.
둘 모두 Kube-Scheduler의 영향을 받지 않음