클러스터가 파드를 제어하는 방식

클러스터가 파드를 제어하는 방식

클러스터는 파드를 제어할 때 ServiceAccount를 사용하지 않습니다. 대신, 다음과 같은 고유한 방식으로 파드를 관리합니다.

• API 서버의 통신: 클러스터의 핵심인 API 서버는 파드에 직접 접속하지 않고, 파드의 상태를 etcd에 기록합니다. 예를 들어, kubectl delete pod 명령을 내리면, API 서버는 etcd에 해당 파드를 '삭제해야 함'이라고 기록합니다.
• 컨트롤러와 kubelet: 클러스터의 다양한 컨트롤러들이 etcd를 지속적으로 감시합니다. 삭제 명령이 감지되면, kubelet 에이전트가 해당 노드에서 파드를 종료하는 작업을 수행합니다. Kubelet은 클러스터 컨트롤 플레인에 의해 관리되며, 파드에 대한 직접적인 제어 권한을 가지고 있습니다.

요약하자면, ServiceAccount는 파드에서 클러스터로 향하는 '상향식(upward)' 접근을 위한 것이고, 컨트롤 플레인과 kubelet은 클러스터에서 파드로 향하는 '하향식(downward)' 제어를 위한 것입니다.

 

kubectl delete pod test_pod가 작동하는 방식

1. kubectl의 API 요청: 사용자가 kubectl delete pod test_pod 명령을 실행하면, kubectl 클라이언트는 쿠버네티스 API 서버에 DELETE /api/v1/namespaces/default/pods/test_pod 라는 HTTP 요청을 보냅니다.
2. API 서버의 etcd 업데이트: API 서버는 요청을 받아 해당 파드의 상태를 즉시 삭제하지 않습니다. 대신, etcd에 저장된 해당 파드 리소스의 메타데이터에 deletionTimestamp 필드를 추가하고, _finalizers 필드에 kubernetes.io/pod-finalizer와 같은 값을 남깁니다. 이것은 **"이 파드는 이제 삭제될 예정입니다"**라고 표시하는 일종의 플래그입니다.

   {
     "metadata": {
       "name": "test_pod",
       "namespace": "default",
       "uid": "1234abcd-efgh-ijkl-mnop-qrstuvwxyz",
       "resourceVersion": "5678",
       "creationTimestamp": "2025-08-26T01:00:00Z",
       "deletionTimestamp": "2025-08-26T01:01:00Z",  // <--- 이 필드가 추가됩니다.
       "finalizers": ["kubernetes.io/pod-finalizer"] // <--- 이 필드가 추가될 수 있습니다.
     },
     "spec": {
       ...
     },
     "status": {
       "phase": "Running",
       ...
     }
   }

3. etcd에 기록되는 예시 (업데이트된 데이터)
4. 컨트롤러와 Kubelet의 역할: 쿠버네티스의 여러 컨트롤러와 각 노드의 kubelet은 etcd의 변화를 지속적으로 감시하고 있습니다. deletionTimestamp가 추가된 것을 감지하면, kubelet은 해당 노드에 있는 test_pod 파드에게 종료 신호(SIGTERM)를 보냅니다.
5. 최종 삭제: 파드가 종료 신호를 받고 우아하게 종료될 시간을 가진 후, kubelet은 파드 컨테이너를 강제로 종료시킵니다. 파드가 완전히 종료되면, kubelet은 파드 리소스의 finalizers를 제거하고, 최종적으로 API 서버가 etcd에서 해당 파드 데이터를 완전히 삭제합니다.

즉, kubectl delete는 직접 삭제하는 명령이 아니라, API 서버를 통해 etcd에 "삭제 예약"을 남기는 방식입니다. 이 방식 덕분에 파드는 우아하게 종료될 시간을 가질 수 있으며, 클러스터의 모든 컴포넌트가 일관된 상태를 유지할 수 있습니다.