파드의 생명주기(Pod Lifecycle) 완벽 해부: Pending부터 Terminated까지

파드의 생명주기(Pod Lifecycle) 완벽 해부: Pending부터 Terminated까지

쿠버네티스를 운영하면서 kubectl get pods 명령어를 입력했을 때 가장 반가운 단어는 단연 Running일 것입니다. 하지만 YAML 명세서를 API 서버에 제출(Apply)하는 순간부터 컨테이너가 정상적으로 사용자 요청을 처리하기까지, 파드는 보이지 않는 인프라 이면에서 매우 정교한 상태 머신(State Machine)의 흐름을 거칩니다.

파드의 생명주기를 정확히 이해하는 것은 단순한 이론 학습을 넘어, CrashLoopBackOff나 ImagePullBackOff 같은 장애 상황을 마주했을 때 문제의 병목 지점을 직관적으로 짚어내는 트러블슈팅의 핵심 역량이 됩니다. 본 가이드에서는 파드의 탄생부터 소멸까지의 전체 생명주기를 단계별로 완벽하게 해부합니다.

---

1. 파드의 5가지 거시적 위상 (Pod Phase)

파드는 생성부터 종료까지 쿠버네티스 API 서버가 추적하는 5가지 주요 위상(Phase) 중 하나에 머물게 됩니다. 이는 파드 전체의 거시적인 상태를 요약해 보여줍니다.

• Pending (대기 중): API 서버가 파드 생성 요청을 승인했지만, 아직 파드 내의 컨테이너가 생성되지 않은 초기 상태입니다.
  • 이 상태에 오래 머문다면 스케줄러가 파드를 배치할 적절한 노드(자원 부족 등)를 찾지 못했거나, 컨테이너 런타임이 무거운 이미지(Image)를 레지스트리에서 다운로드하고 있는 중일 확률이 높습니다.
• Running (실행 중): 파드가 특정 워커 노드에 성공적으로 바인딩(Binding)되었고, 파드 내부의 모든 컨테이너가 생성된 상태입니다.
  • 주의할 점은 Running이라고 해서 애플리케이션이 100% 정상 동작함을 의미하지는 않는다는 것입니다. 컨테이너 중 최소 하나가 실행 중이거나, 시작 또는 재시작되는 중이라면 위상은 Running으로 표시됩니다.
• Succeeded (성공): 파드 내의 모든 컨테이너가 정상적으로 실행을 마치고 종료(종료 코드 0)되었으며, 더 이상 재시작되지 않는 상태입니다. 주로 배치(Batch) 작업을 처리하는 Job이나 CronJob 컨트롤러에서 흔히 볼 수 있는 최종 상태입니다.
• Failed (실패): 파드 내의 모든 컨테이너가 종료되었지만, 최소 하나 이상의 컨테이너가 비정상 종료(0이 아닌 종료 코드를 반환하거나 시스템에 의해 강제 종료됨)된 상태입니다.
• Unknown (알 수 없음): 컨트롤 플레인이 파드의 상태를 확인할 수 없는 장애 상태입니다. 주로 워커 노드의 Kubelet이 다운되었거나 노드의 네트워크 단절로 인해 통신이 지연될 때 발생합니다.

---

2. 거시적 위상의 함정: 컨테이너 상태(Container State)의 진실

많은 초보 관리자들이 파드의 Phase와 개별 Container State를 혼동합니다. 파드 위상이 Running이더라도 실제 컨테이너는 계속해서 죽고 살아나기를 반복할 수 있습니다. 진짜 문제는 파드 내부 컨테이너의 3가지 세부 상태에 숨어있습니다.

• Waiting (대기): 컨테이너가 실행을 시작하기 위해 필요한 작업들을 처리 중인 상태입니다.
  • 이미지를 가져오지 못하는 ErrImagePull, 시작 직후 에러로 죽어버려 재시작을 대기하는 CrashLoopBackOff 등의 치명적인 에러 메세지가 바로 이 상태에서 출력됩니다.
• Running (실행): 컨테이너가 오류 없이 실제로 실행되고 있는 상태입니다. 컨테이너가 이 상태에 진입하면 postStart 라이프사이클 훅(Hook)이 실행됩니다.
• Terminated (종료): 컨테이너가 실행을 성공적으로 마쳤거나, 치명적인 오류가 발생하여 실행이 완료된 상태입니다. OOM(Out of Memory)으로 인해 강제 종료되었을 경우 로그(Reason)에 OOMKilled가 남게 됩니다.

---

3. 파드의 탄생: 초기화(Initialization) 아키텍처

파드가 노드에 스케줄링되어 Running으로 넘어가기 전, 파드 내부에서는 매우 중요하고 순차적인 초기화 과정이 일어납니다.

1. 네트워크 샌드박스 구성: 가장 먼저 pause 컨테이너가 실행되어 파드의 고유한 네트워크 네임스페이스와 IP 주소를 획득합니다.
2. 초기화 컨테이너(Init Containers) 실행: 애플리케이션 컨테이너가 실행되기 전에 먼저 실행되어야 하는 컨테이너들입니다.
   • Init 컨테이너는 파드 명세서에 정의된 순서대로 반드시 하나씩 순차적으로 실행됩니다.
   • 이전 Init 컨테이너가 성공적으로 종료(Completed)되어야만 다음 Init 컨테이너가 실행됩니다.
   • 데이터베이스 파드가 준비될 때까지 기다리거나, 메인 컨테이너가 사용할 권한(Permission)이나 설정 파일을 미리 세팅해 두는 용도로 강력하게 활용됩니다.
3. 메인 컨테이너 실행: 모든 Init 컨테이너가 성공적으로 작업을 마치면, 비로소 사용자가 정의한 메인 애플리케이션 컨테이너들이 병렬로 실행되기 시작합니다.

---

4. 파드의 죽음: 우아한 종료(Graceful Shutdown) 메커니즘

파드는 영원히 살아있는 존재가 아닙니다. 관리자가 삭제 명령을 내리거나, 노드 축소로 인해 방출(Eviction)될 때 파드는 Terminating 상태로 돌입하며 정교한 철수 작전을 시작합니다.

1. 트래픽 유입 차단: API 서버에 파드 삭제가 요청되는 즉시, 해당 파드의 IP는 모든 서비스(Service)의 엔드포인트 목록에서 제거됩니다. 새로운 사용자 트래픽이 죽어가는 파드로 라우팅되는 것을 막기 위함입니다.
2. preStop 훅 실행: 파드 명세에 preStop 라이프사이클 훅이 정의되어 있다면 가장 먼저 실행됩니다. 주로 외부 로드밸런서에서 완전히 제외될 때까지 잠시 대기(sleep)하거나, 애플리케이션의 메모리 버퍼를 안전하게 저장하는 셸 스크립트를 실행합니다.
3. SIGTERM 시그널 전송: Kubelet은 파드 내부의 메인 프로세스(PID 1)에 SIGTERM 종료 시그널을 보냅니다. 애플리케이션은 이 시그널을 받아 열려있는 데이터베이스 커넥션을 닫고 메모리를 정리하는 등 스스로 종료할 수 있는 유예 시간(기본 30초, terminationGracePeriodSeconds)을 얻게 됩니다.
4. SIGKILL에 의한 강제 종료: 만약 애플리케이션이 유예 시간이 지나도록 끈질기게 버티고 종료되지 않는다면, 리눅스 커널은 SIGKILL 시그널을 날려 프로세스를 메모리에서 무자비하게 강제 삭제합니다.

---

파드의 생명주기를 완벽하게 이해한다는 것은, 쿠버네티스라는 거대한 분산 시스템의 호흡을 읽어내는 것과 같습니다. 트러블슈팅을 진행할 때 맹목적으로 파드의 로그만 뒤지는 것이 아니라, kubectl describe pod 명령어를 통해 해당 파드가 생명주기의 어느 지점(Phase, Container State, Condition)에서 발목이 잡혀 있는지를 파악하는 것이 클라우드 네이티브 아키텍트의 진정한 첫걸음입니다.