PodGroup 라이프사이클

PodGroup 라이프사이클 (PodGroup Lifecycle)

PodGroup은 단위로 스케줄되며, 파드가 아직 실행 중이면 조기 삭제로부터 보호됩니다.

출처: 문서

본문

소유권과 라이프사이클

PodGroup은 표준 ownerReferences를 통해 그것을 만든 워크로드 컨트롤러(예: Job)가 소유해요. 소유 오브젝트가 삭제되면 PodGroup은 자동으로 가비지 컬렉션됩니다.

PodGroup 이름은 네임스페이스 안에서 고유해야 하며, 유효한 DNS 서브도메인이어야 해요.

생성 순서

컨트롤러는 다음 순서로 오브젝트를 만들어야 해요:

  1. Workload — 스케줄링 정책 템플릿.
  2. PodGroup — 런타임 인스턴스.
  3. Pods — spec.schedulingGroup.podGroupName이 PodGroup을 가리키며.

PodGroup이 존재하지 않는(또는 삭제 중인) Workload를 가리키는 podGroupTemplateRef를 포함하면 API 서버는 PodGroup 생성 요청을 거부해요. PodGroup이 생성되기 전에 참조된 Workload가 존재해야 합니다.

파드가 아직 존재하지 않는 PodGroup을 참조하면 그 Pod는 pending으로 남아요. 스케줄러는 PodGroup이 생성되면 스케줄링을 위해 Pod를 자동으로 큐에 넣습니다.

삭제 보호

PodGroup은 파드 중 하나라도 실행 중이면 완전히 삭제될 수 없어요. 전용 finalizer는 PodGroup을 참조하는 모든 Pod가 종료 단계(Succeeded 또는 Failed)에 도달할 때까지 삭제를 차단합니다.

컨트롤러 관리형과 사용자 관리형 PodGroup

대부분의 경우 워크로드 컨트롤러(예: Job)가 PodGroup을 자동으로 만들어요(컨트롤러 관리형). 컨트롤러는 DaemonSet이 파드마다 노드 친화도를 설정하는 방식과 비슷하게, 생성 시점에 각 파드의 podGroupName을 결정합니다.

이름과 라이프사이클에 대한 더 많은 제어가 필요하다면 PodGroup 오브젝트를 직접 만들고 파드 템플릿에 spec.schedulingGroup.podGroupName을 직접 설정할 수 있어요(사용자 관리형). 이렇게 하면 PodGroup 생성과 이름에 대한 완전한 제어를 얻습니다.

제한 사항

  • PodGroup의 모든 파드는 같은 .spec.schedulerName을 사용해야 한다. 불일치가 감지되면 스케줄러는 그룹의 모든 파드를 스케줄 불가능한 것으로 거부한다.
  • PodGroup의 모든 파드는 같은 .spec.priority를 사용해야 한다. 불일치가 감지되면 스케줄러는 그룹의 모든 파드를 스케줄 불가능한 것으로 거부한다.
  • PodGroup의 모든 파드는 같은 .spec.preemptionPolicy를 사용해야 한다. 불일치가 감지되면 스케줄러는 그룹의 모든 파드를 스케줄 불가능한 것으로 거부한다.
  • 파드의 spec.schedulingGroup 필드는 불변이다. 한 번 설정되면 파드는 다른 PodGroup으로 이동할 수 없다.
  • 단일 Workload의 PodGroupTemplates 최대 수는 8이다.
  • 스케줄러는 초기 배치 이후 PodGroup의 진행 중인 운영 상태나 이후 스케줄링 시도에 관한 상태 정보를 업데이트하지 않는다. 결과적으로 기존 파드가 실패하거나, 축출되거나, 종료되거나, 새로 관찰된 파드가 스케줄에 실패해도 PodGroup 상태는 업데이트되지 않는다.

더 알아보기 (Learn more)