PodGroup 생명주기

PodGroup 생명주기

gang 스케줄링처럼 여러 파드를 한 단위로 묶어야 할 때, 쿠버네티스는 이 묶음을 PodGroup이라는 객체로 표현해요. PodGroup은 파드가 아직 실행 중인 동안에는 이른 삭제로부터 보호되는, 하나의 단위로 스케줄되는 객체예요. 워크로드 컨트롤러가 PodGroup을 어떻게 만들고 관리하며, 어떤 제약이 있는지 이해하면 스케줄링 그룹을 쓰는 워크로드를 설계하기 훨씬 수월해져요. 이 기능은 쿠버네티스 v1.35부터 알파로 들어왔고 기본적으로는 꺼져 있어요.

출처: 쿠버네티스 공식 문서 — PodGroup Lifecycle

소유권과 생명주기

PodGroup은 표준 ownerReferences를 통해 자신을 만든 워크로드 컨트롤러(예: Job)가 소유해요. 소유 오브젝트가 삭제되면 PodGroup도 자동으로 가비지 컬렉션돼요. PodGroup 이름은 네임스페이스 안에서 유일해야 하고, 유효한 DNS 서브도메인 이름이어야 해요.

생성 순서

컨트롤러는 오브젝트를 항상 이 순서로 만들어야 해요.

  1. Workload — 스케줄링 정책 템플릿.
  2. PodGroup — 런타임 인스턴스.
  3. Pods — spec.schedulingGroup.podGroupName으로 해당 PodGroup을 가리키는 파드들.

만약 PodGroup이 존재하지 않거나 삭제 중인 Workload를 가리키는 podGroupTemplateRef를 포함하면, API 서버는 그 PodGroup 생성 요청을 거부해요. PodGroup을 만들 수 있으려면 참조하는 Workload가 먼저 존재해야 해요. 반대로 파드가 아직 존재하지 않는 PodGroup을 참조하면 그 파드는 pending 상태로 남고, PodGroup이 생성되면 스케줄러가 그 파드를 자동으로 스케줄링 큐에 넣어요.

삭제 보호

PodGroup은 그 파드 중 하나라도 실행 중이면 완전히 삭제될 수 없어요. 전용 finalizer가 해당 PodGroup을 참조하는 모든 Pods가 종료 상태(Succeeded 또는 Failed)에 도달할 때까지 삭제를 막아 줘요.

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

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

이름과 생명주기를 더 세밀하게 통제하고 싶다면, PodGroup 객체를 직접 만들어 파드 템플릿에 spec.schedulingGroup.podGroupName을 직접 설정할 수도 있어요(사용자 관리형). 이 방식은 PodGroup 생성과 이름짓기를 완전히 제어할 수 있게 해 주죠.

제약 사항

PodGroup을 쓸 때 꼭 알아둬야 할 제약이 몇 가지 있어요.

  • PodGroup 안의 모든 파드는 같은 .spec.schedulerName 을 써야 해요. 불일치가 감지되면 스케줄러는 그룹 안의 모든 파드를 스케줄 불가로 거부해요.
  • PodGroup 안의 모든 파드는 같은 .spec.priority 를 써야 해요. 불일치 시 모든 파드가 스케줄 불가로 거부돼요.
  • PodGroup 안의 모든 파드는 같은 .spec.preemptionPolicy 를 써야 해요. 불일치 시 모든 파드가 스케줄 불가로 거부돼요.
  • 파드의 spec.schedulingGroup 필드는 불변(immutable) 이에요. 한번 설정하면 파드는 다른 PodGroup으로 옮겨갈 수 없어요.
  • 하나의 Workload 안에 넣을 수 있는 PodGroupTemplate의 최대 개수는 8개예요.
  • 스케줄러는 초기 배치 이후의 PodGroup 운영 상태나 후속 스케줄링 시도에 대한 상태 정보를 갱신하지 않아요. 그래서 기존 파드가 실패·축출·종료되거나 새로 관찰된 파드가 스케줄링에 실패해도 PodGroup 상태는 갱신되지 않아요.

더 알아보기 (Learn more)