LifeCycle
Pod가 있고 Status안에
Phase라고해서 Pod의 전체 상태를 대표하는 속성이 있고,
Pod가 생성되면서 실행하는 단계들이 있는데 그 단계와 상태를 알려주는 속성이 Condition이다.
Pod안에는 Container들이 있는데 Container들도 State라고 해서 각각의 Container를 대표하는 상태가 있다.
Phase
Pending, Running, Succeeded, Failed, Unknown
Conditions
Initialized, ContainerReady, PodScheduled, Ready
Reason(Conditions의 세부 내용) : ContainersNotReady, PodCompleted
State
Waiting, Running, Terminated
Reason(State의 세부 내용) : ContainerCreating, CrashLoopBackOff, Error, Completed
Pod이 최소 상태는 Pending이다.
Pod가 어느 Node위로 올라갈지 직접 Node를 지정했을 때는 지정한 해당 Node에 아니면 쿠버네티스가 알아서 자원의 상황을 판단해서 Node를 결정하기도 하는데 이것이 완료되면 PodScheduled는 True가 된다.
initContainer라고 해서 본 컨테이너가 기동되기 전에 초기화 시켜야 될 내용들이 있을 경우 그 내용을 담는 컨테이너가 있다.
만약 볼륨이나 보안 세팅을 위해 사전 설정을 해야 하는 경우 Pod 생성 내용 안에 initContainers라는 항목으로 초기화 스크립트를 넣을 수 있고 이 스크립트가 본 Container보다 먼저 실행이 되서 그 작업이 성공적으로 끝났거나 아예 설정을 안했을 경우 Initialized는 True를 그리고 실패할 경우 False가 된다.
Container에 Image를 다운로드하는 동작이 있고 그 과정동안 Container의 상태는 Waiting이고 Reason은 ContainerCreating이다.
Container가 기동되면서 Pod와 Container 상태는 Running이 된다.
그런데 일반적으로 정상적으로 기동될 수 있지만 하나 또는 모든 Container가 기동중에 문제가 생겨 재시작 될 수 있다. 그럼 이때 Container 상태는 Waiting이고 Reason은 CrashLoopBackOff다.
Pod는 Container 이러한 상태들에 대해서 Running이라고 간주하고 그대신 ContainerReady와 Ready는 False다.
그래서 일반적으로 계속 Service가 운영이 되야하는 경우 이 Status를 계속 유지해야할 것이고 Pod의 상태가 Running이더라도 내부 Container의 상태들이 Running이 아닐수도 있기 때문에 Pod뿐만아니라 Container상태도 모니터링이 필요하다.
Job이나 CronJob으로 생성된 Pod의 경우 자신의 일을 수행했을 때는 Running 중이지만 일을 마치게 되면 Pod는 더이상 일을 하지 않는 상태가 되고 Pod의 상태는 Failed나 Succeeded가 된다.
작업을 하고 있는 컨테이너중에 하나라도 문제가 생겨서 에러가 생기면 Pod의 상태는 Failed가 되고
Container들이 모두 Completed로 해당 일을 잘 마쳤을 경우 Succeeded가 된다.
이때 또 Pod의 Condition 값이 변하게 되는데 성공이건 실패건 간에 ContainerReady와 Ready의 값이 False로 바뀌게 된다.
그리고 추가적인 케이스로 Pending중에 바로 Failed로 빠지는 경우가 있고
Pending이나 Running 중에 통신 장애가 발생하면 Pod가 Unknown 상태로 변하는데 통신 장애가 빨리 해결되면 기존상태로 되돌아 오지만 장애가 지속되면 Failed가 된다.
