1. Pod - Lifecycle

파드(Pod)의 라이프 사이클(Lifecycle)을 이해하는 것은 쿠버네티스 트러블슈팅의 절반을 마스터하는 것과 같다. 파드가 왜 죽었는지, 왜 서비스에 연결되지 않는지는 모두 이 생애 주기 안에 답이 있다.

 

---

 

1. 파드 라이프 사이클의 본질과 중요성

사람이 태어나서 성장하고 생을 마감하듯, 파드도 생성부터 소멸까지 정해진 과정을 거친다.

• 기능적 연관성: 라이프 사이클은 앞으로 배울 Readiness/Liveness Probe, QoS, Restart Policy 등 쿠버네티스의 핵심 기능들과 밀접하게 연결되어 있다.
  • 내용이 다소 복잡할 수 있으나, 모두 알아야한다. 
  • 이를 모르면 인프라의 동적인 변화를 예측할 수 없으므로 반드시 이해하고 넘어가야 한다.
• 행동의 변화: 파드가 어느 단계에 있느냐에 따라 쿠버네티스가 해당 파드에 대해 수행하는 행동(트래픽 전달 여부 등)이 달라진다.

 

2. Pod의 라이프 사이클

파드의 상태 정보는 크게 YAML 파일의 "status 필드"에 기록된다. 크게 세 가지 계층 구조로 나뉜다.

1. Phase (페이지, Pod): 파드 전체의 상태를 대표하는 값 (Pending, Running 등).
2. Conditions (컨디션스, Pod): 파드가 거쳐 가는 세부 단계들의 성공 여부 (Initialized, Ready 등). 만약, status: 'False'인 경우 이유를 알아야 하기 때문에 Reason이 추가되어 있다.
3. Container States (컨테이너 상태, Containers): 파드 안엔 컨테이너가 있다. 그 개별 컨테이너들의 상태 (Waiting, Running, Terminated). 컨테이너 또한,이유를 알아야 하기 때문에 Reason이 추가되어 있다.

위 구조를 기반으로 어떻게 상태가 변화하는지 그 과정을 상세하게 뜯어보자.

 

 

1. [최초상태]: Pending (대기) 단계

파드가 생성된 직후의 상태다. 다음 작업들이 이루어진다.

• Node Scheduling: 어느 노드에 배치될지 결정된다. 완료 시 PodScheduled가 True가 된다.
• InitContainer 실행: 본 컨테이너 기동 전의 초기화 스크립트가 실행된다. 성공 시 Initialized가 True가 된다.
• Image Pulling: 컨테이너 이미지를 다운로드한다.
  • 이때, 위 두 과정 동안의 컨테이너 상태는 Waiting, 리즌은 ContainerCreating이다.

2. Running (실행) 단계

직전 상태에서 본격적으로 최소 하나 이상의 컨테이너가 기동되면, 다음 작업들이 이루어진다.

• [1] 기본적으로 Container와 Pod가 Running으로 변경된다.

인프런_대세는 쿠버네티스(주의 사항)

• 주의 사항: 근데, 번외로 파드 페이지가 Running이더라도 내부 컨테이너가 계속 재시작되는 CrashLoopBackOff 상태일 수 있다. 즉, 파드는 Running이더라도, 내부 Container의 상태는 Wating + CashLoopBackOff일 수 있다는 것이다.
• 즉, 파드는 컨테이너의 이러한 상태들에 대해서도 Running이라고 간주한다.
  • 대신 내부 컨디션인 ContainerReady와 Ready가 모두 Flase이다.
• 즉, 주의 사항을 강조하는 이유는 Pod의 상태가 Container 상태가 아니기 때문에 파드 뿐만 아니라 컨테이너 상태도 모니터링하자.

• [2] 트래픽 조건:그래서, 내부 컨디션인 ContainerReady와 Ready가 모두 True여야만 실제 서비스 트래픽이 파드로 전달된다.

3. Succeeded / Failed / Unknown (종료 및 기타)

Job이나 CronJob으로 생성된 파드들. 자신의 일을 수행했을 때는 Running, 마치면 Succeeded / Failed 둘 중 하나이다.

• Succeeded: Job 등 일시적 작업이 성공적으로 완료(Completed)된 상태다.
• Failed: 작업 중 에러가 발생하여 비정상 종료된 상태다.
  • 이때, 또 파드의 컨디션 값이 변하게 된다.
  • 위 두가지든 뭐든 모두 ContainerReady: False, Ready: False 고정이다.

• Unknown: 노드와의 통신 장애로 파드의 상태를 알 수 없을 때 발생한다. 이게 지속되면 Failed로 되기도 한다.

 

 

 

 

💡꼬리 질문

Q: 파드의 restartPolicy 설정은 파드가 Succeeded 또는 Failed 상태로 전이되는 과정에 어떤 영향을 미치며, 왜 중요할까?

 

 

결론: 파드가 '최종 상태'에 머무를지, 아니면 다시 Running 단계로 복귀할지를 결정한다.

1. 동작 원리: 만약 restartPolicy가 Always(기본값)라면, 컨테이너가 종료되어도 쿠버네티스는 이를 다시 살려낸다. 따라서 파드는 결코 Succeeded나 Failed 같은 터미널(Terminal) 상태에 영구적으로 머물지 않고 다시 Running으로 돌아간다.
2. Job의 경우: Job이나 CronJob으로 생성된 파드는 작업 완료 후 종료되어야 하므로 OnFailure 또는 Never를 사용한다. 이 설정이 있어야만 작업 성공 시 Succeeded, 실패 시 Failed라는 명확한 최종 라이프 사이클 단계에 도달할 수 있다.
3. 실무적 의의: 이 정책을 잘못 설정하면 할 일이 끝난 파드가 무한 재시작되며 자원을 낭비하거나, 반대로 죽지 말아야 할 서비스 파드가 죽은 채로 방치될 수 있다.

 

위 학습용 정리 내용 및 사진 자료는 "인프런_대세는 쿠버네티스(https://inf.run/Lv5RV)" 강의를 소스로 작성하였습니다