Pod Lifecycle

Pod

Pod은 Kubernetes에서 scheduling 가능한 최소한의 배포 단위로, Pod은 전체 생애에서 단 한번만 schedule된다. 다시 말해서 Node에 할당된 pod은 종료될 때까지, 해당 node에서만 존재할 수 있다는 이야기다. Pod 자체는 Self-heal이 불가능하므로 Fail 발생시 그대로 제거되며, 다른 UUID값을 갖는 Pod으로 대체된다. 

Pod Phase

'kubectl get pod <pod-name> -o yaml' 등의 명령어로 Pod의 디테일한 정보를 확인해보면, 사용자가 정의한 spec 외에 status 라는 필드가 존재한다. 그리고 이 필드에는 phase 항목이 존재하는데, 이는 Pod의 lifecycle이 현재 어느 단계에 있는지를 알려준다.

우선 Pod의 전체 Lifecycle과 각 Phase는 아래와 같다.

 

 

• Pending: Pod 생성 요청을 받았지만 하나 이상의 container가 실행준비를 마치지 못한 상태이다. 컨테이너 이미지를 다운로드하는 시간도 이 phase에 포함된다.
• Running: Node가 배정되었고, 모든 컨테이너가 생성된 상태이다. 최소한 하나 이상의 컨테이너가 실행 중이거나 시작 또는 재시작 중이다.
• Succeeded: Pod의 모든 컨테이너가 성공적으로 종료되었으며, 재시작할 필요가 없다.
• Failed: 모든 컨테이너가 종료되었으나, 하나 이상의 컨테이너가 0이 아닌 값을 반환하였거나 시스템에 의해 강제로  종료되어 실패로 끝난 경우이다. 
• Unknown: k8s가 Pod의 상태 정보를 읽어오지 못하는 상태이며, 일반적으로 kubelet과 API 서버간의 통신에 문제가 있는 경우가 많다.

참고로 node가 다운되거나 네트워크 연결이 원활하지 않은 경우, 해당 node의 모든 Pod은 Failed phase로 전이(transition)된다.

 

Pod Conditions

Pod Phase 외에, 현재 Pod이 서비스를 제공할 수 있는지 순서대로 점검한 Pod Condition이 존재한다.

• PodScheduled: Pod이 Node에 배정되었는지 확인
• ContainersReady: Pod의 모든 컨테이너가 ready 상태인지 확인
• Initialized: 모든 'init container'가 성공적으로 실행되었는지 여부
• Ready: Pod이 서비스를 제공할 수 있는 상태인지 확인. Readiness Probe를 통해 결정되며, 이를 통과해야 Endpoint가 할당되어 Service를 통해 로드밸런싱이 이루어진다.

Restart Policy

Pod의 spec 중 'restartPolicy' 필드가 존재한다. 그런데 분명히 Pod은 재생성이 안된다고 위에서 이미 얘기를 했는데 어찌된 영문일까?

사실 이 필드는 Pod이 아닌 하위 컨테이너 모두에 대해 적용되는 항목으로, 해당 Pod이 위치한 node의 kubelet이 이를 참조하여 컨테이너를 재시작할지 여부를 결정한다. Pod의 컨테이너가 종료되면 kubelet은 10초, 20초, 40초와 같이 딜레이를 2배씩 증가시키면서 해당 컨테이너를 재시작하며 최대 5분까지 지연될 수 있다. 그리고 컨테이너가 10분 동안 문제없이 실행된 경우, 이 지연시간(back-off delay)은 초기화된다.

 

참고

• Pod Lifecycle

• How Pods and the Pod Lifecycle work in Kubernetes