아래와 같은 Pod를 생성하는 명령을 입력하게 된다면 쿠버네티스 내부에서는 어떻게 동작이 일어날까요?
kubectl run test-pod --image=nginx
저는 4가지 단계로 구분을 진행했습니다.
1. ETCD 저장(Pending) 과정 (kube-apiserver)
우선 첫번째로 해당 명령어는 kube-apiserver로 전달되게 됩니다.
kube-apiserver는 해당 명령을 실행할 수 있는 권한을 가진 사용자가 실행을 했는지 확인을 진행합니다.
- 인증(Authentication): 요청한 사용자가 누구인지 확인합니다.
- 인가(Authorization): 해당 사용자가 Pod에 대한 생성 권한이 있는지 확인합니다.
- Admission Control: ResourceQuota나 PodSecurityPolicy(PSP) 적용에 대한 검증을 수행합니다.
위 과정들을 거치게 되면, etcd에 Pod객체를 저장하게 됩니다. 이 상태까지가 Pending의 상태입니다.
2. Node 선택 과정 (kube-scheduler)
쿠버네티스 컴포넌트 중 kube-scheduler라는 컴포넌트가 있습니다.
해당 scheduler는 kube-apiserver를 Watch를 하고 있으며, 1번에서 ETCD까지 등록이 완료된 Pending 상태의 Pod를 확인하게 됩니다.
이후 매니페스트에 작성된 Node Selector, Resource, affinity들을 확인한 후, Scoring을 통해 어느 Node에 스케쥴링을 할지 선택을 진행합니다.
선택이 완료되면, kube-apiserver를 통해 Pod가 스케줄링될 Node를 업데이트(.spec.nodeName) 합니다.
3. 컨테이너 시작(Running) 단계 (Kubelet)
쿠버네티스 클러스터의 모든 노드에는 "kubelet" 이라는게 존재합니다.
kubelet이란? : 각 노드에서 실행되는 핵심 에이전트, control plane과 통신하여 클러스터의 상태와 노드의 상태를 동일하게 동기화시켜주는 역할을 합니다.
1. 각 노드의 kubelet에서 kube-apiserver를 watch하고 있다가, 자신의 노드가 할당된 Pod를 감지하게 됩니다.
2. 이미지를 다운로드, 네트워크 설정, 볼륨마운트 등의 절차를 수행합니다.
3. 컨테이너를 시작하고 Pod 및 컨테이너 상태를 kube-apiserver를 통해 주기적으로 전달합니다.
kube-apiserver는 워커노드의 kubelet에서 전달받은 상태를 업데이트 하여 Pod를 "Running" 상태로 전환합니다.
이렇게 Pod가 생성이 완료 됩니다.
사실 컨테이너 시작단계에서 CNI를 통해 네트워크를 주소를 받는 부분이 존재합니다만, 해당 부분에 대해서는 다음 글에 작성하겠습니다.
참고 문서
Kubernetes 컴포넌트: https://kubernetes.io/ko/docs/concepts/overview/components/
'DevOps > Kubernetes' 카테고리의 다른 글
[쿠버 뿌셔 02] Endpoint - 외부 패킷이 Pod로 가기까지의 여정 (0) | 2025.09.30 |
---|