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/

파드 라이프사이클

 

 

 

 

 

 

 

 

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 세팅을 할 수 있게 됩니다