CompositePodGroup API 라이프사이클

CompositePodGroup API 라이프사이클

CompositePodGroup은 다단계(멀티레벨) PodGroup 계층에서 리프(leaf)가 아닌 노드를 나타내요. PodGroup 리소스와 달리 CompositePodGroup 리소스는 파드를 직접 포함하지 않습니다. 대신 하위 CompositePodGroup 객체와 PodGroup 객체의 계층을 유지하고, 자신의 하위 그룹에 적용되는 스케줄링 정책을 담고 있습니다.

출처: 문서

본문

소유권과 가비지 컬렉션

CompositePodGroup 객체는 그 하위 CompositePodGroup 및 PodGroup 리소스와 함께, 쿠버네티스 ownerReferences를 통해 그것을 만든 워크로드 컨트롤러가 소유합니다. 소유 워크로드 객체가 삭제되면, 종속적인 가비지 컬렉션(cascading garbage collection)이 연결된 그룹 계층을 자동으로 삭제합니다.

CompositePodGroup 이름은 네임스페이스 안에서 고유해야 하며 유효한 DNS 서브도메인이어야 합니다.

생성 순서

적절한 계층 해석과 스케줄링을 보장하기 위해 워크로드 컨트롤러는 리소스를 하향식(top-down) 순서로 만듭니다:

  1. Workload: 정적 템플릿(CompositePodGroupTemplate과 PodGroupTemplate)을 정의한다.
  2. 루트 CompositePodGroup: spec.workloadRef가 Workload의 루트 템플릿을 가리키며 생성된다.
  3. 하위 CompositePodGroups와 PodGroups: 하향식으로 생성된다. 각 하위 그룹은 spec.parentCompositePodGroupName으로 부모를, spec.workloadRef로 자신의 템플릿을 지정한다.
  4. Pods: spec.schedulingGroup.podGroupName이 리프 PodGroup을 가리키며 생성된다.

그룹이 존재하지 않는 부모 CompositePodGroup을 참조하거나, 파드가 아직 생성되지 않은 PodGroup을 참조하면, 스케줄러는 계층의 모든 부모 리소스가 존재할 때까지 스케줄링을 보류합니다.

제약과 검증 규칙

  • 일관된 스케줄러 이름: 전체 CompositePodGroup 계층의 모든 파드는 같은 spec.schedulerName을 사용해야 합니다. 불일치가 감지되면 스케줄러는 계층을 스케줄 불가로 거부합니다.
  • 일관된 우선순위: 전체 CompositePodGroup 계층의 모든 파드는 같은 값의 spec.priority를 지정해야 하며, 이는 루트 그룹이 지정한 우선순위와 같아야 합니다. 불일치가 감지되면 스케줄러는 계층을 스케줄 불가로 거부합니다.
  • 일관된 선점 정책: 전체 CompositePodGroup 계층의 모든 파드는 같은 spec.preemptionPolicy를 사용해야 합니다. 또한 PodGroupPreemptionPolicy 기능 게이트가 활성화되면, 루트 그룹의 선점 정책은 파드가 지정한 것과 같아야 합니다. 불일치가 감지되면 스케줄러는 계층을 스케줄 불가로 거부합니다.
  • 최대 중첩 깊이: 그룹-템플릿 계층은 최대 4단계 깊이를 지원합니다.
  • 목록 항목 제한: Workload의 어느 수준에서든 하위 CompositePodGroupTemplate과 PodGroupTemplate의 최대 개수는 8개입니다.
  • 불변의 갱(gang) 그룹 수: CompositePodGroup의 spec.schedulingPolicy.gang.minGroupCount 필드는 생성 후 변경할 수 없습니다.
  • 불변의 계층 참조: 그룹의 spec.parentCompositePodGroupName과 파드의 spec.schedulingGroup은 한번 설정되면 변경할 수 없습니다.

더 알아보기 (Learn more)