Pod - Lifecycle, Probe
이 글은 인프런의 대세는 쿠버네티스 강의를 보며 정리한 글입니다.
Lifecycle
pending -> Running -> Succeeded -> Failed
Pod
Status
Phase 속성
ex) Pending, Running, Succeeded, Failed, Unknown
Conditions 속성
ex) Initialized, ContainerReady, PodScheduled, Ready
Container
ContainerStatuses
State 속성
ex) Waiting, Running, Terminated
순서
Pending : 초기화하는 단게 (init)
PodScheduled -> Initialized
Running : Pod가 running 상태이더라도 안에 container가 실행되는건 별도
-> 기동중 실패하면 rollback이 되고 CrashLoopBackoff (waiting)이 된다.
운영중에는 Running을 유지해야함
job이나 cronojob으로 생성된 Pod는 나중에 Failed이나 Succeeded로 간다.
컨테이너중 하나라도 문제가 생기면 Failed
다 성공하면 Succeeded
Pending이나 Running중 통신 장애가 생기면 Unknown으로 가며 계속 지속되면 Failed로 감.
https://kubernetes.io/ko/docs/concepts/workloads/pods/pod-lifecycle/
파드 라이프사이클
이 페이지에서는 파드의 라이프사이클을 설명한다. 파드는 정의된 라이프사이클을 따른다. Pending 단계에서 시작해서, 기본 컨테이너 중 적어도 하나 이상이 OK로 시작하면 Running 단계를 통과하
kubernetes.io
ReadinessProbe, LivenessProbe 상황 설명
예로 2개의 Pod가 가동되어 트릭픽이 50:50으로 나가는 상황에서 1개의 Pod가 망가졌을 때
AutoHealing으로 Pod가 다른 Node에 재생성된다. 이때 Pod가 Running이여도 Container안의 App이 가동중일 수 있다
(이러면 Error페이지를 보게 됨.)
이때 ReadinessProbe를 달면 App이 Running 상태가 될때까지 이미 괜찮은 Pod에 트래픽을 온전히 보낸다.
이후 App이 Running 상태가 되면 다시 50:50으로 트래픽을 분산시킴.
그리고 App이 망가졌지만 Pod가 Running 상태인 경우 LivenessProbe를 달면 금방 새로운 Pod를 재생성하여 정상작동
(Restart) 잠깐의 Disconnection이 존재하지만 금방 돌아옴.
ReadinessProbe : App 구동 순간에 트래픽 실패를 없앰
LivenessProbe : App 장애시 지속적인 트래픽 실패를 없앰
startupProbe를 세팅하게 되면, startupProbe가 OK되기 전에는 readinessProbe와 livenessProbe가 돌지 않기 때문에
더 안정적으로 Probe 세팅을 할 수 있게 됩니다