Kubernetes v1.35: 워크로드 인식 스케줄링 소개

Source: Kubernetes Blog

워크로드‑중심 스케줄링

대규모 워크로드를 스케줄링하는 것은 단일 Pod를 스케줄링하는 것보다 훨씬 복잡하고 취약합니다. Pod별 스케줄링과 달리, 워크로드 스케줄링은 모든 Pod를 함께 고려해야 하며, 이들 간의 관계와 배치 제약 조건을 반영해야 합니다.

워크로드 스케줄링이 중요한 이유

• 전략적 배치 – 머신러닝 배치 작업의 경우, 워커들이 종종 같은 랙에 함께 위치해야 지연 시간을 최소화하고 처리량을 최대화할 수 있습니다.
• 동일한 Pod – 동일한 워크로드에 속한 Pod들은 스케줄링 관점에서 보통 동일하므로, 스케줄링 알고리즘의 가정이 달라집니다.
• 증가하는 수요 – AI 및 데이터‑집약형 워크로드가 급증함에 따라, 효율적인 워크로드 스케줄링은 Kubernetes 사용자에게 필수적인 요구사항이 되고 있습니다.

현재 상황

워크로드 수준의 결정을 처리하기 위해 많은 커스텀 스케줄러가 존재하지만, 이들은 핵심 kube-scheduler 외부에 있습니다. 이러한 분산은 다음과 같은 문제를 초래합니다:

1. 일관성 없는 사용자 경험 – 운영자는 별도의 스케줄링 컴포넌트를 학습하고 유지관리해야 합니다.
2. 제한된 통합 – 커스텀 스케줄러는 기본 스케줄러가 제공하는 기능(예: 우선순위, 선점, extender API 등)을 쉽게 활용할 수 없습니다.
3. 운영 오버헤드 – 추가 스케줄러를 배포·모니터링·업그레이드하는 과정이 복잡성을 증가시킵니다.

행동 촉구

AI 시대에 워크로드 스케줄링의 중요성을 감안할 때, 이제는 다음을 실행할 때입니다:

• 워크로드를 일등 시민으로 승격하여 네이티브 kube-scheduler에 포함시킵니다.
• 네이티브 API를 공개하여 사용자가 워크로드 수준 제약(랙 어피니티, 스프레드 정책 등)을 선언할 수 있게 합니다.
• **기존 스케줄러 확장(예: 프레임워크 플러그인)**을 활용해 워크로드 인식 로직을 구현하고, 핵심 스케줄러를 포기하지 않습니다.

워크로드‑중심 기능을 kube-scheduler에 직접 통합함으로써, Kubernetes는 전통적인 워크로드와 새로운 AI 워크로드 모두에 대해 통합되고, 신뢰할 수 있으며, 확장 가능한 스케줄링 경험을 제공할 수 있습니다.

워크로드‑인식 스케줄링

Kubernetes v1.35는 워크로드‑인식 스케줄링 개선의 첫 번째 트랜치를 도입합니다. 이러한 변경 사항은 여러 릴리스에 걸쳐 진화할 광범위한 멀티‑SIG 노력의 일부이며, 선점 및 자동 스케일링을 포함하되 이에 국한되지 않는 Kubernetes에서 원활한 워크로드 스케줄링 및 관리를 위한 북스타 목표를 향해 나아갑니다.

주요 하이라이트

사용자에게 의미하는 바

• 예측 가능한 배포 – 워크로드에 필요한 포드의 정확한 수와 특성을 정의하면 스케줄러가 해당 제약을 준수합니다.
• 스케줄링 지연 감소 – 동일한 포드가 그룹화되어 함께 스케줄링되므로 준비 상태에 도달하는 시간이 단축됩니다.
• 향후 기능을 위한 기반 – 이번 릴리스는 정교한 선점, 자동 스케일링, 클러스터 간 워크로드 배치와 같은 고급 기능을 위한 토대를 마련합니다.

참고: 이 기능은 향후 릴리스와 추가 SIG 전반에 걸쳐 계속 확장될 예정이므로, 최신 개선 사항을 확인하려면 Kubernetes 릴리스 노트를 주시하세요.

Source: …

Workload API

새로운 Workload API 리소스는 scheduling.k8s.io/v1alpha1 API 그룹에 속합니다.

이 API는 다중 Pod 애플리케이션의 스케줄링 요구사항을 구조화된 기계‑읽기 가능한 정의로 제공합니다. Job과 같은 사용자‑대면 워크로드가 무엇을 실행할지를 설명한다면, Workload는 어떻게 여러 Pod이 스케줄링되고 라이프사이클 전반에 걸쳐 배치가 관리되어야 하는지를 설명합니다.

Workload 로 할 수 있는 일

• Pod 그룹(podGroup)을 정의합니다.
• 해당 그룹에 스케줄링 정책을 적용합니다(예: 갱 스케줄링, 우선순위 등).

예시: 갱‑스케줄링 구성

아래 스니펫은 workers 라는 이름의 pod 그룹을 정의하고, 최소 네 개의 Pod이 동시에 스케줄링되어야 하는 gang 정책을 적용하는 Workload를 생성합니다.

apiVersion: scheduling.k8s.io/v1alpha1
kind: Workload
metadata:
  name: training-job-workload
  namespace: some-ns
spec:
  podGroups:
    - name: workers
      policy:
        gang:
          # 4개의 pod이 동시에 실행될 수 있을 때만 gang이 스케줄 가능
          minCount: 4

Pod를 Workload에 연결하기

개별 Pod를 생성할 때 workloadRef 필드를 사용해 Workload(및 특정 pod 그룹)를 참조합니다:

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
  namespace: some-ns
spec:
  workloadRef:
    name: training-job-workload   # Workload 이름
    podGroup: workers            # Workload에 정의된 Pod 그룹
  # ... 기타 pod spec 필드 ...

이와 같이 설정하면 스케줄러는 갱‑스케줄링 제약조건이 충족될 때만 Pod들을 배치하므로, 전체 그룹이 함께 실행될 수 있도록 보장합니다.

Source: …

갱 스케줄링 작동 방식

gang 정책은 전부‑또는‑전무 배치를 강제합니다. 갱 스케줄링이 없으면 작업이 부분적으로 스케줄될 수 있어, 실행되지 못한 채 자원을 소비하게 됩니다. 이는 자원 낭비와 잠재적인 교착 상태를 초래합니다.

갱‑스케줄된 Pod 그룹의 라이프사이클

1. Pod 생성 – Pod(또는 이를 생성하는 컨트롤러)는 갱‑스케줄된 Pod 그룹의 일부로 표시됩니다.
2. 스케줄러 처리 – 스케줄러의 GangScheduling 플러그인이 각 Pod 그룹(또는 레플리카 키)의 라이프사이클을 관리합니다.
3. 블로킹 단계 – 다음 모든 조건이 충족될 때까지 Pod는 스케줄링이 차단됩니다:
   • 참조된 Workload 객체가 존재한다.
   • 해당 Workload 안에 참조된 PodGroup이 존재한다.
   • 그룹 내 대기 중인 Pod 수가 설정된 minCount에 도달한다.

Permit Gate

minCount가 만족되면 스케줄러는 Pod를 배치하려 시도하지만, 즉시 노드에 바인딩되지 않습니다. 대신 Permit 게이트에서 대기합니다:

• 스케줄러는 **전체 그룹에 대한 유효한 할당(최소 minCount 이상)**을 찾았는지 확인합니다.
• 그룹이 맞으면: 게이트가 열리고 모든 Pod가 한 번에 노드에 바인딩됩니다.
• 일부만 맞는 경우(시간 초과 내, 기본 = 5 분): 스케줄러는 그룹의 모든 Pod를 거부합니다. 거부된 Pod는 큐로 돌아가 다른 워크로드를 위해 예약된 자원을 해제합니다.

향후 방향

이는 Kubernetes에서의 첫 번째 갱 스케줄링 구현입니다. 향후 릴리스에서는 다음을 목표로 합니다:

• 전체 갱에 대한 단일 사이클 스케줄링 단계 제공.
• 워크로드 수준 프리엠션 추가.
• 장기적인 “북‑스타” 목표인 협조 스케줄링을 향한 추가 기능 도입.

핵심 요점: 갱 스케줄링은 Pod 집합이 함께 실행되거나 전혀 실행되지 않도록 보장하여, 부분 할당을 방지하고 클러스터 전체 효율성을 향상시킵니다.

Source:

Opportunistic Batching

Kubernetes v1.35는 opportunistic batching(베타 기능)을 도입하여 동일한 Pod에 대한 스케줄링 지연 시간을 개선합니다. 갱 스케줄링과 달리 이 기능은 명시적인 옵트‑인이나 Workload API가 필요하지 않습니다. 스케줄러는 스케줄링 요구 사항(컨테이너 이미지, 리소스 요청, 어피니티 등)이 동일한 Pod에 대해 계산된 적합성을 재사용함으로써 스케줄링 과정을 크게 가속화합니다.

Note: 대부분의 사용자는 아래 기준을 충족하는 한 자동으로 이점을 얻을 수 있습니다.

Restrictions

Opportunistic batching은 Pod 간에 kube-scheduler가 위치를 찾기 위해 사용하는 모든 필드가 동일할 때만 작동합니다. 일부 스케줄러 기능은 정확성을 위해 배칭을 비활성화합니다.

• kube-scheduler 설정을 검토하여 배칭이 암묵적으로 비활성화되지 않았는지 확인하십시오.
• 제한 사항 전체 목록은 공식 문서를 참고하십시오:

Official Kubernetes Documentation – Opportunistic Batching

북극성 비전

이 프로젝트는 워크로드 인식 스케줄링을 제공하는 광범위한 목표를 가지고 있습니다. 이러한 새로운 API와 스케줄링 향상은 첫 번째 단계에 불과합니다.

가까운 미래 목표

• 워크로드 스케줄링 단계 도입
• 멀티 노드 Dynamic Resource Allocation (DRA) 및 토폴로지 인식 스케줄링에 대한 지원 개선
• 워크로드 수준 선점
• 스케줄링과 자동 확장의 통합 강화
• 외부 워크로드 스케줄러와의 상호작용 향상
• 워크로드의 전체 수명 주기 동안 배치 관리
• 멀티 워크로드 스케줄링 시뮬레이션

Note: 이러한 초점 영역의 우선순위와 구현 순서는 변경될 수 있습니다. 추가 업데이트를 기대해 주세요.

Getting Started

워크로드‑인식 스케줄링 개선 사항을 사용해 보려면 클러스터 구성 요소에서 필요한 기능 게이트와 API 그룹을 활성화하세요.

1. Workload API

• Feature gate: GenericWorkload
• Components: kube-apiserver 및 kube-scheduler
• API group: scheduling.k8s.io/v1alpha1 (활성화되어야 함)

2. Gang Scheduling

• Feature gate: GangScheduling
• Component: kube-scheduler
• Prerequisite: 워크로드 API(1단계)가 이미 활성화되어 있어야 합니다.

3. Opportunistic Batching (Beta)

• v1.35에서 기본적으로 활성화됩니다.
• 비활성화하려면 kube-scheduler의 OpportunisticBatching 기능 게이트를 끄세요.

테스트 클러스터에서 워크로드‑인식 스케줄링을 실험하고 경험을 공유해 주시기 바랍니다. 여러분의 피드백은 Kubernetes 스케줄링의 미래를 shaping하는 데 큰 도움이 됩니다.

How to Provide Feedback

• Slack: #sig‑scheduling 채널에 참여하세요.
• GitHub:
  • 워크로드‑인식 스케줄링 추적 이슈에 댓글을 달아 주세요.
  • Kubernetes 저장소에 새로운 enhancement 이슈를 생성하세요.

자세히 알아보기

• KEP를 읽어보세요:

  • 워크로드 API 및 갱 스케줄링
  • 기회주의 배치

• 최근 업데이트를 위해 워크로드‑인식 스케줄링 이슈 를 추적하세요.