이번 글에서는 Kubernetes의 정적 포드에 대해 다뤄보겠습니다.
kubelet의 기본 동작 원리
Kubelet은 Kubernetes의 중요한 구성 요소로, 노드에서 실행되는 포드와 컨테이너를 관리합니다. 일반적으로 kubelet은 kube-apiserver에서 어떤 포드를 로드할지에 대한 지침을 받습니다. 이러한 지침은 kube-scheduler에 의해 결정되고, etcd에 저장됩니다.
하지만 kube-apiserver, kube-scheduler, etcd 클러스터가 없고, 마스터 노드도 없는 상황에서는 어떻게 될까요? 이런 상황에서도 kubelet이 독립적으로 작동할 수 있을까요?
독립적인 kubelet의 역할
Kubelet은 노드를 독립적으로 관리할 수 있습니다. 예를 들어, 호스트에 kubelet과 Docker가 설치되어 있다고 가정해 봅시다. Kubernetes 클러스터 없이도 kubelet은 포드를 생성할 수 있습니다. 이때 중요한 것은 kube-apiserver가 없으므로 API 서버를 통해 포드의 세부 정보를 제공할 수 없다는 점입니다.
포드를 만들려면 포드 정의 파일이 필요합니다. 그런데 API 서버 없이 포드 정의 파일을 어떻게 kubelet에 제공할 수 있을까요? 이를 위해 kubelet은 지정된 서버 디렉토리에서 포드 정의 파일을 읽도록 구성할 수 있습니다.
정적 포드 구성
Kubelet은 주기적으로 지정된 디렉토리를 확인하여 포드 정의 파일을 읽고, 호스트에서 포드를 생성합니다. 이 디렉토리에 포드 정의 파일으 넣으면 kubelet이 포드를 생성하고, 파일을 제거하면 포드가 자동으로 삭제됩니다. 이렇게 kubelet이 자체적으로 생성하는 포드를 정적 포드 (ststic pods)라고 부릅니다.
정적 포드의 한계
정적 포드는 replicaset, deployment 등의 객체를 생성할 수 없습니다. 이들은 쿠버네티스 아키텍처의 일부로, Controlplane의 구성 요소가 필요하기 때문입니다.
정적 포드와 kube-apiserver의 관계
정적 포드는 kubernetes controlplane에 의존하지 않으므로 controlplane 구성 요소를 포드로 배포하는 데 사용할 수 있습니다. 그렇다면 정적 포드는 API 서버에서 어떻게 보일까요? kube-apiserver에서 보이는 정적 포드는 포드의 읽기 전용 미러입니다. 포드에 대한 세부 정보를 볼 수는 있지만, 일반 포드처럼 수정하거나 삭제할 수는 없습니다.
포드의 이름은 노드 이름과 함께 자동으로 추가됩니다. 예를 들어, 노드 이름이 "node01"이면 포드 이름은 "podname-node01"이 됩니다.
정적 포드의 용도
정적 포드는 Kubernetes Controlplane에 의존하지 않기 때문에, controlplane의 구성 요소를 배포하는 데 사용할 수 있습니다. 예를 들어, kubelet을 모든 마스터 노드에 설치하고, 각 마스터 노드의 지정된 디렉토리에 controlplane 구성 요소의 포드 정의 파일을 넣으면 됩니다.
정적 포드와 데몬셋의 차이
데몬셋은 모든 노드에서 애플리케이션의 단일 인스턴스가 실행되도록 보장합니다. 데몬셋은 kube-apiserver를 통해 데몬셋 컨트롤러에 의해 처리됩니다. 반면, 정적 포드는 kubelet이 직접 생성하며 kube-apiserver나 다른 kubernetes controlplane 구성 요소의 개입 없이 동작합니다.
정적 포드와 데몬셋 모두 kube-scheduler의 영향을 받지 않습니다.
마치며
이번 글에서는 kubernetes에서 정적 포드가 무엇인지, 그리고 kubelet이 이를 어떻게 관리하는지에 대해 알아보았습니다. 정적 포드는 kubernetes controlplane 없이도 포드를 관리할 수 있는 강력한 방법입니다. 이를 통해 kubernetes 클러스터를 더 유연하고 견고하게 운영할 수 있습니다.
