Static Pods

• kubelet은 노드의 선장이다.

• kubelet은 kube-apiserver와 소통하여 파드를 배치시킨다.

• 파드가 어느 노드에 배치될지를 결정하는 것은 스케쥴러에 의해 의사결정되어지며 해당 파드가 어느 노드에 배치되어있는지에 대한 정보를 ETCD 데이터 저장소에 저장한다.

• 그럼 만약에 마스터 노드 (ETCD, kube-apiserver, Controller-Manager, kube-scheduler)가 없고, 다른 노드도 없다면 kubelet은 어떻게 자신이 관리하는 노드에 파드를 배치시킬 수 있을까?

• kubelet은 위와 같은 상황에서 독립적으로 노드를 관리하는 역할을 제공한다.

• 해당 노드에 kubelet이 설치되어있고, 당연히 도커도 설치되어있다고 가정하자.

• kubelet은 파드를 생성이 가능한데, 문제는 우리가 만든 Pod Definition File을 kube-apiserver 없이 어떻게 kubelet에게 전달해줄 수 있을까?

• 노드 안에 /etc/kubernetes/manifests 폴더 아래에 Pod Definition File을 위치시키자.

• kubelet은 이 폴더 아래에 있는 파일들을 읽어서 호스트에 파드를 생성한다.

• kubelet은 애플리케이션이 종료하면 파드를 재실행 시켜주며, Pod Definition File을 변경해도 역시 다시 파드를 재실행시켜서 변경사항을 반영해준다.

• Pod Definition File를 폴더에서 제거하면 당연히 호스트에 파드도 제거된다.

• 위와같이 kube-apiserver의 개입 없이 생성된 파드들을 Static Pod라고 부른다.

• 당연히 kubelet만 있고, Controller-Manager와 ETCD가 없으므로 레플리카도, 디플로이먼트, 서비스를 생성할 수 없다.

• /etc/kubernetes/manifests Path는 얼마든지 변경 가능하며, kubelet.service 파일 안에 pod-manifest-path라는 옵션이 있는데 거기에 디렉토리를 명시해주면 kubelet이 해당 폴더 아래에 있는 파드 정의 파일을 읽어간다.

• kubelet.service 파일이 없다면 kubeconfig.yaml 파일에 있는 staticPodPath에 Path를 명시해줄 수도 있다.

그럼 이 Static Pods는 어디에 써먹을 수 있을까?

• Static Pod를 사용해 Master Node를 직접 만들어볼 수 있다.

• 각각의 노드에 kubelet을 설치하고, kube-apiserver, ETCD, Controller-Manager 매니페스트 파일을 특정 폴더에 넣어두면 마스터 노드와 동일한 동작을 하게 할 수 있을 것이다.

• 이 방법은 kubeadmin tool에서 쿠버네티스 클러스터를 구성할 때 사용한다.

Static Pod VS DeamonSet

• DeamonSet은 모든 노드의 애플리케이션을 ensure하기 위해 각 노드에 배치된다.

• 이 DeamonSet은 kube-apiserver를 통해 DeamonSet Controller에 의해 컨트롤된다.

• Static Pod는 kubelet에 의해 생성되며 다른 어떤 k8s 오브젝트들의 개입 없이 Control Plane Component를 배포한다.

• 둘의 공통점은 이 두 종류의 파드들 모두 kube-scheduler를 무시한다.

Multiple Schedulers

• 쿠버네티스의 스케쥴러는 확장가능한 구조로 되어있다.

• 만약 파드를 배포하기 전에 뭔가 검증을 하고 싶다거나 특별한 요구 사항이 있을 경우 default scheduler의 알고리즘을 변경하거나, 새로운 scheduler를 만드는 것도 가능하다.

• 새롭게 생성된 스케쥴러는 파드에 스케쥴러의 이름을 추가해주면 반영이 가능하다.

스케쥴링 파트 끝