Pod - Lifecycle

Lifecycle 모식도

Lifecycle 예시                                                                                                      Lifecycle 상태값 종류

• Phase: 파드의 전체 상태를 대표하는 속성
• Conditions: Phase를 조금 더 세부적으로 표현한 속성
  • Reason: Conditions>status의 값이 False일 때 사용되는 값이다. False의 원인를 명시한다.
•  ContainerStatuses: 각각의 컨테이너 상태를 표현한 속성
  •  Running 상태를 제외하고 Conditions와 마찬가지로 Reason 값이 추가될 수 있다. 
  • 위의 예시에서는 ContainerCreating에 의해 wating 상태인 거고, imageID가 비어있는 것으로 보아 아직 이미지가 다운로드되지 않았다는 걸 알 수 있다.

Lifecycle 상세 모식도

• 파드의 최초 상태는 Pending이다. 
  • 이 상태일 때 하는 두 가지 작업 중 하나는 Pod가 어느 노드 위에 올라갈지 결정하는 것으로, 이 작업이 완료되면 PodScheduled는 True가 된다.
  • 다음 작업은 Initialized Conditions에 대한 것으로, InitContainer라고 해서 본 컨테이너가 기동되기 전에 초기화 시켜야 되는 내용들이 있을 경우 그 내용을 담고있는 컨테이너가 있다.
  • 예를 들어 볼륨이나 보안 세팅을 위해 사전 설정을 해야 되는 일이 있을 경우 위와 같이 InitContainer라는 항목으로 초기화 스트립트를 넣을 수 있다.
  • 이 스크립트가 본 컨테이너보다 먼저 실행이 돼서 그 작업이 성공적으로 끝났거나 또는 아예 설정을 하지 않았을 경우 True를 그리고 실패를 하게 되면 False가 된다.
    • 작업이 성공적으로 끝나면 InitContainer에 대해 먼저 컨테이너가 생성된다. -> 본 Container 생성

• Phase가 Pending일 동안  ContainerStatuses에 따라 모든 컨테이너의 State는 Wating이고, Reason은 ContainerCreating이다.
• 이제 컨테이너에 이미지를 다운로드하면 본격적으로 컨테이너가 기동되면서 파드와 컨테이너의 상태가 Running이 된다.
  • 모든 Container가 정상적으로 동작한다면 즉, Running 상태이면 Conditions의 ContainerReady와 Ready 값이 True가 된다. (https://rosoa0475.tistory.com/509 - ReadinessProbe 내용 참고)
  • 이때, 컨테이너가 하나라도 기동 중에 문제가 발생해서 재시작되면 컨테이너의 상태는 Waiting이 되고, CrashLoopBackOff라는 Reason이 나온다.
  • 이러한 컨테이너의 상태에서도 파드는 Running Phase이지만, ContainerReady와 Ready 값이 False가 된다.
• Job이나 CronJob으로 생성된 파드의 경우 자신의 일을 수행할 때는 Phase가 Running이지만 일을 마치게 되면 파드의 Phase는 Failed나 Succeeded로 나뉘게 된다.
  • 모든 컨테이너의 State가 Terminated인 상황에서, Reason이 하나라도 Error이면 파드의 Phase는 Failed가 된다.
  • 모든 컨테이너의 State가 Terminated인 상황에서, 모든 Reason이 Completed이면 파드의 Phase는 Succeeded가 된다.
  • 파드의 Phase가 Failed건 Succeeded건 ContainerReady와 Ready의 값은 False로 바뀐다.
• 추가적인 케이스로 Pending 중에 바로 Failed로 빠지는 경우가 있다.
• 더불어 Pending이나 Running 중에 통신 장애가 발생하면 파드가 Unknown 상태로 바뀌는데, 통신 장애가 빨리 해결이 되면 다시 원래 Phase로 변경되지만, 계속 지속이 되면 Failed로 변하기도 한다.