Kubernetes v1.36: 워크로드 인식 스케줄링 강화

출처: Kubernetes Blog

AI/ML 및 배치 워크로드는 단순한 Pod‑by‑Pod 스케줄링을 넘어서는 고유한 스케줄링 문제를 야기합니다.
Kubernetes v1.35에서는 워크로드 인식 스케줄링 개선의 첫 번째 단계로, 기본적인 워크로드 API와 Pod 기반 프레임워크 위에 구축된 기본적인 갱 스케줄링 지원, 그리고 동일한 Pod을 효율적으로 처리하기 위한 기회주의 배치 기능을 도입했습니다.

Kubernetes v1.36은 API 관점을 명확히 분리함으로써 중요한 아키텍처 변화를 선보입니다. 워크로드 API는 정적 템플릿 역할을 하고, 새로운 PodGroup API가 런타임 상태를 담당합니다. 이를 지원하기 위해 kube‑scheduler는 원자적인 워크로드 처리를 가능하게 하는 새로운 PodGroup 스케줄링 사이클을 도입했으며, 향후 기능 확장의 기반을 마련했습니다. 이번 릴리스에서는 토폴로지 인식 스케줄링과 워크로드 인식 선점(preemption)의 첫 번째 구현도 공개합니다. 또한, 워크로드에 대한 ResourceClaim 지원을 통해 PodGroup에 대한 동적 자원 할당(DRA)이 가능해졌습니다. 마지막으로 실사용 준비성을 보여주기 위해 v1.36은 Job 컨트롤러와 새로운 API 간의 첫 번째 통합 단계를 제공합니다.

워크로드 및 PodGroup API 업데이트

워크로드 API는 이제 정적 템플릿으로 동작하고, 새로운 PodGroup API가 런타임 객체를 설명합니다.
Kubernetes v1.36은 scheduling.k8s.io/v1alpha2 API 그룹의 일부로 워크로드와 PodGroup API를 도입했으며, 이전 v1alpha1 버전을 완전히 대체합니다.

v1.35에서는 Pod 그룹과 그 런타임 상태가 워크로드 리소스 안에 내장되어 있었습니다. 새로운 모델은 이 개념들을 분리합니다. 워크로드는 정적 템플릿 객체가 되고, PodGroup은 런타임 상태를 관리합니다. 이 분리는 성능과 확장성을 향상시키며, PodGroup API가 복제본별 상태 업데이트를 샤딩할 수 있게 합니다.

워크로드 API가 단순히 템플릿 역할만 하게 되면서 kube‑scheduler의 로직이 간소화됩니다. 스케줄러는 워크로드 객체를 감시하거나 파싱할 필요 없이, 스케줄링에 필요한 모든 정보를 담고 있는 PodGroup을 직접 읽을 수 있습니다.

업데이트된 구성 예시

워크로드 컨트롤러(예: Job 컨트롤러)는 이제 워크로드 객체를 정의하고, 이는 Pod 그룹에 대한 정적 템플릿 역할을 합니다.

apiVersion: scheduling.k8s.io/v1alpha2
kind: Workload
metadata:
  name: training-job-workload
  namespace: some-ns
spec:
  # Pod 그룹은 이제 템플릿으로 정의됩니다.
  # 템플릿은 PodGroup 객체의 spec 필드를 포함합니다.
  podGroupTemplates:
  - name: workers
    schedulingPolicy:
      gang:
        # 갱은 동시에 4개의 Pod이 실행될 수 있을 때만 스케줄링됩니다.
        minCount: 4

컨트롤러는 이러한 템플릿을 기반으로 런타임 PodGroup 인스턴스를 생성합니다. PodGroup 런타임 객체는 실제 스케줄링 정책을 보관하고, 생성된 템플릿을 참조합니다. 또한 개별 Pod의 상태를 반영하는 조건을 포함한 status 필드를 가지고 있어, 그룹 전체의 스케줄링 상태를 나타냅니다.

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: training-job-workers-pg
  namespace: some-ns
spec:
  # PodGroup은 원본 워크로드 템플릿을 참조합니다.
  # 비교를 위해, .metadata.ownerReferences는 실제 워크로드 객체(예: Job)를 가리킵니다.
  podGroupTemplateRef:
    workload:
      workloadName: training-job-workload
      podGroupTemplateName: workers
  # 실제 스케줄링 정책은 런타임 PodGroup 안에 위치합니다.
  schedulingPolicy:
    gang:
      minCount: 4
status:
  # 상태에는 개별 Pod 조건을 반영하는 condition이 포함됩니다.
  conditions:
  - type: PodGroupScheduled
    status: "True"
    lastTransitionTime: 2026-04-03T00:00:00Z

마지막으로, 개별 Pod와 새로운 아키텍처를 연결하기 위해 Pod API의 workloadRef 필드는 schedulingGroup 필드로 교체되었습니다. Pod을 생성할 때 런타임 PodGroup에 직접 연결합니다.

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
  namespace: some-ns
spec:
  # workloadRef 필드가 schedulingGroup으로 대체되었습니다.
  schedulingGroup:
    podGroupName: training-job-workers-pg
  ...

워크로드를 정적 템플릿으로 유지하고 PodGroup을 독립적인 1급 API로 승격함으로써, 향후 Kubernetes 릴리스에서 고급 워크로드 스케줄링 기능을 구축할 수 있는 견고한 기반을 마련했습니다.

PodGroup 스케줄링 사이클 및 갱 스케줄링

이러한 워크로드를 효율적으로 관리하기 위해 kube‑scheduler는 전용 PodGroup 스케줄링 사이클을 도입했습니다.
Pod‑by‑Pod 로 순차적으로 리소스를 평가·예약하는 방식은 스케줄링 교착 상태(deadlock)를 초래할 위험이 있습니다. 대신 스케줄러는 그룹 전체를 하나의 통합 연산으로 평가합니다.

스케줄러가 스케줄링 큐에서 PodGroup 멤버를 꺼낼 때, 그룹 정책에 관계없이 해당 그룹에 대기 중인 나머지 Pod을 모두 가져와 결정적인 순서로 정렬하고, 다음과 같은 원자적인 스케줄링 사이클을 수행합니다.

1. 클러스터 상태 스냅샷을 한 번만 찍어 레이스 컨디션을 방지하고 일관성을 확보합니다.
2. 표준 Pod 기반 필터링·점수 매기기 단계를 활용하는 PodGroup 스케줄링 알고리즘을 통해 그룹 내 모든 Pod에 대한 유효한 Node 배치를 찾으려고 시도합니다.
3. 알고리즘 결과에 따라 전체 PodGroup에 대한 스케줄링 결정을 원자적으로 적용합니다.

성공 시

배치가 발견되고 그룹 제약조건이 충족되면, 스케줄 가능한 멤버 Pod들은 바인딩 단계로 바로 이동합니다. 남은 스케줄 불가능한 Pod은 다시 스케줄링 큐로 반환되어, 충분한 리소스가 확보될 때까지 대기합니다.

참고: 이미 일부 Pod이 Node에 할당된 뒤에 새로운 Pod이 추가되면, 사이클은 기존 Pod을 고려하면서 새 Pod을 평가합니다. 이미 Node에 배정된 Pod은 실행 중인 상태를 유지하며, 스케줄러가 이를 해제하거나 퇴출하지 않습니다.

실패 시

그룹이 요구조건을 충족하지 못하면 전체 그룹이 스케줄 불가능으로 간주됩니다. 모든 Pod이 바인딩되지 않으며, 백오프 기간 후에 다시 시도하도록 큐에 반환됩니다.

이 사이클은 갱 스케줄링의 기반이 됩니다. 워크로드가 “전부 혹은 전무” 배치를 요구할 때, 갱 정책은 이 사이클을 활용해 부분적인 배치를 방지하고, 자원 낭비와 교착 상태를 예방합니다.

스케줄러는 minCount 요구조건이 충족될 때까지 Pod을 PreEnqueue 상태에 유지하지만, 실제 스케줄링 단계는 이제 완전히 새로운 PodGroup 사이클에 의존합니다. 알고리즘 실행 중에 스케줄 가능한 Pod 수가 minCount를 만족하는지 확인하고, 클러스터가 최소 요구량을 수용하지 못하면 어떤 Pod도 바인딩되지 않으며, 그룹은 자원이 충분히 확보될 때까지 대기합니다.

제한 사항

첫 번째 버전의 PodGroup 스케줄링 사이클은 다음과 같은 제한을 가집니다.

• 동질적인 Pod 그룹(모든 Pod이 동일한 스케줄링 요구사항을 가지고, affinity, anti‑affinity, topology spread 등 상호 의존성이 없는 경우)에서는 알고리즘이 가능한 배치를 찾을 확률이 높습니다.
• 이질적인 Pod 그룹(Pod마다 요구사항이 다르거나 복잡한 제약조건이 있는 경우)에서는 배치가 존재하더라도 알고리즘이 반드시 찾는다고 보장할 수 없습니다.
• 상호 의존성을 가진 Pod 그룹(예: Pod 간 affinity/anti‑affinity)에서도 배치가 존재하더라도 반드시 찾는다고 보장되지 않습니다.