Pod를 생성할 때 내부 흐름

“직접 Pod 생성”의 내부 흐름(요청 → 컨테이너 가동)

아래는 kubectl apply -f pod.yaml 같은 Pod(또는 Deployment 등) 생성 요청이 들어간 뒤의 핵심 경로입니다.

1. kubectl → kube-apiserver (REST 호출)
   • kubeconfig의 인증서/토큰으로 인증(Authentication), 인가(Authorization, RBAC) 를 통과.
   • Admission 단계 실행:
     • Mutating Webhook/플러그인: 기본값 주입(이미지PullPolicy, 디폴트 리소스 등), 사이드카 주입(Istio 등).
     • Validating Webhook/플러그인: 정책 검사(PodSecurity, Gatekeeper/OPA), 네임스페이스 쿼터/LimitRange 검증.
   • 최종 승인된 오브젝트(예: Pod 스펙)가 etcd(클러스터 상태 저장소)에 기록됨.
     → apiserver만 etcd에 쓰기/읽기 수행, 나머지 컴포넌트는 watch로 갱신을 구독.
2. (선택 경유) 컨트롤러 매니저(kube-controller-manager)
   • 만약 Deployment/ReplicaSet/Job로 생성했다면:
     • Deployment 컨트롤러가 ReplicaSet을 조정, ReplicaSet이 Pod 템플릿을 기준으로 필요한 개수의 Pod 오브젝트를 생성.
   • 직접 Pod를 만들었다면 이 단계는 일부 생략(컨트롤러가 아닌 스케줄러가 바로 관여).
3. 스케줄러(kube-scheduler)
   • etcd에 생긴 Pending Pod를 watch.
   • 노드 자원/어피니티/톨러레이션/테인트/토폴로지 등을 고려해 적합한 Node를 선택.
   • 선택 결과를 API 서버에 바인딩(Pod의 spec.nodeName 설정).
4. 선정된 노드의 kubelet
   • kubelet이 API 서버를 watch 하다가 “자기 노드에 배치된 Pod”를 감지.
   • 다음 순서로 실행 준비:
     • 이미지 풀(ImagePullSecret/레지스트리 인증 사용)
     • 볼륨 준비: CSI(스토리지 드라이버)로 PVC 바인딩/마운트
     • 네트워크 준비: CNI(예: Calico)로 Pod 네트워크 인터페이스 생성·IP 할당·라우팅 설정
     • 컨테이너 런타임(containerd/CRI-O) 에 Pod/컨테이너 생성 요청(CRI)
   • 컨테이너 시작 후 상태(Ready/NotReady, 로그, 이벤트) 를 API 서버에 지속 보고.
5. 서비스/엔드포인트 반영
   • EndpointSlice 컨트롤러가 Ready한 Pod를 해당 Service의 엔드포인트로 반영.
   • kube-proxy(각 노드의 DaemonSet) 가 Service의 가상 IP(ClusterIP) → 실제 Pod IP로 가는 iptables/IPVS 규칙을 동기화.
   • Pod 내부 DNS 질의는 CoreDNS(서비스 kube-dns)로 가며, 서비스/Pod 이름을 IP로 해석.

요약:
kubectl → apiserver(인증/인가/어드미션) → etcd 기록 → 스케줄러(노드 결정) → kubelet(이미지·볼륨·네트워크 준비, 컨테이너 가동) → kube-proxy/CoreDNS(네트워킹/서비스 디스커버리)