Pod 컨디션

Pod 컨디션 (pod-condition)

출처: 쿠버네티스 공식 문서 — Pod Conditions

쿠버네티스에서 많은 오브젝트가 컨디션(conditions) 을 가져요. 컨디션은 오브젝트가 나타내는 것의 실제 상태 중 어떤 측면을 가리키는 표식이에요.

Pod도 컨디션을 가지는데, 쿠버네티스 Pod 컨디션은 컨트롤러(그리고 문제 해결을 하는 사람)가 Pod의 상태를 이해하는 중요한 수단이에요.

Pod의 phase는 Pod가 수명주기에서 어디쯤 있는지에 대한 높은 수준의 요약을 제공하지만, 하나의 값만으로 전체 그림을 담을 순 없어요. 예를 들어 Pod가 Running phase에 있어도 아직 트래픽을 서비스할 준비가 안 됐을 수 있어요. Pod 컨디션은 스케줄됐는지, 컨테이너가 준비됐는지, 리사이즈(resize)가 진행 중인지, 테인트(taint)로 인해 곧 중단될 예정인지 등 Pod 상태의 여러 측면을 독립적으로 추적해서 phase를 보완해요.

Pod 컨디션의 구조 (Structure of a Pod condition)

Pod의 status에는 특정 체크포인트를 통과했는지를 나타내는 PodCondition 배열이 포함돼요. PodCondition 배열의 각 요소는 다음 필드를 가져요:

| 필드 이름 | 설명 | | type | 이 Pod 컨디션의 이름. | | status | 해당 컨디션이 적용되는지 여부. 가능한 값은 "True", "False", "Unknown". | | lastTransitionTime | Pod가 마지막으로 한 상태에서 다른 상태로 전환된 시각. | | reason | 컨디션의 마지막 전환 사유를 나타내는, 기계가 읽을 수 있는 UpperCamelCase 텍스트. | | message | 마지막 상태 전환에 대한 세부 정보를 나타내는 사람이 읽을 수 있는 메시지. | | observedGeneration | 컨디션이 기록된 시점의 Pod .metadata.generation. Pod generation 참고. |

내장 Pod 컨디션 (Built-in Pod conditions)

쿠버네티스는 다음 Pod 컨디션들을 관리해요:

수명주기 컨디션(Lifecycle conditions): Pod가 수명주기를 진행하면서 대략 다음 순서로 설정돼요 — PodScheduled, PodReadyToStartContainers, Initialized, ContainersReady, Ready.

수명주기 Pod 컨디션 (Lifecycle Pod conditions)

1. PodScheduled: Pod가 노드에 스케줄됨.
2. PodReadyToStartContainers: Pod 샌드박스가 성공적으로 생성되고 네트워킹이 구성됨. 샌드박스와 네트워크는 컨테이너 런타임이 설정하고, CNI 플러그인은 appc/CNI 스펙을 따르는 네트워크 플러그인의 한 종류예요.
3. Initialized: 모든 init 컨테이너가 성공적으로 완료됨. init 컨테이너가 없는 Pod의 경우, 샌드박스 생성 전에 True로 설정됨.
4. ContainersReady: Pod의 모든 컨테이너가 준비됨. 컨테이너의 준비 상태는 구성돼 있다면 준비 프로브(readiness probe)로 결정돼요.
5. Ready: Pod가 요청을 서비스할 수 있고, 매칭되는 모든 Service의 로드 밸런싱 풀에 추가되어야 함.

PodReadyToStartContainers

참고 (Note)

Pod가 노드에 스케줄된 후에는, kubelet이 이를 허용(admit)하고 필요한 스토리지 볼륨을 마운트해야 해요. 이 단계들이 완료되면 kubelet이 컨테이너 런타임(CRI (Container Runtime Interface))과 협력해서 런타임 샌드박스를 만들고 Pod의 네트워킹을 구성해요.

기타 Pod 컨디션 (Other Pod conditions)

DisruptionTarget

• PreemptionByScheduler: 더 높은 우선순위를 가진 새 Pod를 수용하기 위해 스케줄러가 Pod를 선점(preempt)할 예정. 자세한 내용은 Pod 우선순위 선점 참고.
• DeletionByTaintManager: Pod가 허용(tolerate)하지 않는 NoExecute 테인트 때문에, (kube-controller-manager 내 노드 수명주기 컨트롤러의 일부인) Taint Manager가 Pod를 삭제할 예정. 테인트 기반 축출(taint-based evictions) 참고.
• EvictionByEvictionAPI: 쿠버네티스 API를 사용해 Pod가 축출용으로 표시됨.
• DeletionByPodGC: 더 이상 존재하지 않는 Node에 바인딩된 Pod가 Pod 가비지 컬렉션으로 삭제될 예정.
• TerminationByKubelet: Pod가 노드 압력 축출(node pressure eviction), 정상 노드 종료(graceful node shutdown), 또는 시스템 중요 Pod 선점 중 하나 때문에 kubelet이 종료시킴.

Pod 컨테이너 한도를 초과해서 발생한 축출 같은 그 밖의 중단 시나리오에서는, 중단이 아마 Pod 자체 때문에 발생했고 재시도하면 다시 일어날 것이므로 Pod는 DisruptionTarget 컨디션을 받지 않아요.

참고 (Note)

Pod 가비지 컬렉터(PodGC)는 Pod를 정리하는 것과 함께, Pod가 종료되지 않은(non-terminal) phase에 있으면 그것들을 failed로 표시하기도 해요(Pod 가비지 컬렉션 참고).

Job(또는 CronJob)을 쓸 때는 이런 Pod 중단 컨디션을 Job의 Pod 실패 정책의 일부로 사용하고 싶을 수 있어요. 자세한 내용은 Disruptions을 참고하세요.

PodResizePending과 PodResizeInProgress

• type: PodResizePending: kubelet이 요청을 즉시 승인할 수 없음. message 필드에 이유에 대한 설명을 제공해요.
  • reason: Infeasible: 요청된 리사이즈가 현재 노드에서 불가능함(예: 노드가 가진 것보다 더 많은 자원 요청).

향상된 Pod 준비 상태 (Enhanced Pod readiness)

애플리케이션은 Pod의 .status에 추가 피드백이나 신호를 주입할 수 있어요. 이를 향상된 Pod 준비 상태(enhanced Pod readiness) 라고 불러요.

이를 사용하려면 Pod의 spec에 readinessGates를 설정해서, kubelet이 Pod 준비 상태를 평가할 때 확인할 추가 컨디션 목록을 지정해요.

Readiness 게이트는 Pod의 status.condition 필드의 현재 상태로 결정돼요. 쿠버네티스가 Pod의 status.conditions 필드에서 그런 컨디션을 찾지 못하면, 해당 컨디션의 상태는 "False"로 기본 설정돼요.