Kubernetes v1.36: 워크로드 인식형 스케줄링의 진화 | WIPI의 프로그래밍 및 기술 블로그

AI/ML 및 배치(batch) 워크로드는 단순한 포드 단위(Pod-by-Pod) 스케줄링을 넘어서는 독특한 스케줄링 과제를 안겨줍니다. Kubernetes v1.35에서는 기초적인 워크로드 인식형 스케줄링(workload-aware scheduling) 개선 사항의 첫 단계를 도입했으며, 여기에는 기초적인 워크로드 API와 포드 기반 프레임워크 위에 구축된 기본적인 갱 스케줄링(gang scheduling) 지원, 그리고 동일한 포드들을 효율적으로 처리하기 위한 기회주의적 배칭(opportunistic batching) 기능이 포함되었습니다.

Kubernetes v1.36은 API 관심사를 깔끔하게 분리하여 중요한 아키텍처적 진화를 이루었습니다. 이제 워크로드(Workload) API는 정적 템플릿 역할을 수행하고, 새로운 포드그룹(PodGroup) API가 런타임 상태를 관리합니다. 이를 지원하기 위해 kube-scheduler에는 원자적(atomic) 워크로드 처리를 가능하게 하고 향후 기능 확장의 길을 열어주는 새로운 **포드그룹 스케줄링 사이클(PodGroup scheduling cycle)**이 도입되었습니다. 또한, 이번 릴리스에서는 스케줄링 역량을 한 단계 끌어올리기 위해 **토폴로지 인식형 스케줄링(topology-aware scheduling)**과 **워크로드 인식형 선점(workload-aware preemption)**의 첫 번째 버전을 선보입니다. 아울러, 워크로드를 위한 리소스클레임(ResourceClaim) 지원을 통해 포드그룹에 대한 동적 리소스 할당(DRA) 기능을 구현했습니다. 마지막으로 실제 환경에서의 준비성을 입증하기 위해, v1.36에서는 Job 컨트롤러와 새 API 간의 첫 번째 통합 단계를 제공합니다.

워크로드 및 포드그룹 API 업데이트

워크로드 API는 이제 정적 템플릿 역할을 하며, 새로운 포드그룹 API는 런타임 객체를 기술합니다. Kubernetes v1.36은 scheduling.k8s.io/v1alpha2 API 그룹의 일부로 워크로드 및 포드그룹 API를 도입하여 이전의 v1alpha1 API 버전을 완전히 대체했습니다.

v1.35에서는 포드 그룹과 그 런타임 상태가 워크로드 리소스 내에 포함되어 있었습니다. 새로운 모델은 이 개념들을 분리합니다. 워크로드는 이제 정적 템플릿 객체 역할을 하고, 포드그룹은 런타임 상태를 관리합니다. 이러한 분리는 포드그룹 API가 레플리카별로 상태 업데이트를 샤딩(sharding)할 수 있게 함으로써 성능과 확장성도 개선합니다.

워크로드 API가 단순히 템플릿 역할만 수행함에 따라 kube-scheduler의 로직이 간소화되었습니다. 스케줄러는 워크로드 객체 자체를 감시(watch)하거나 파싱할 필요 없이, 스케줄러에 필요한 모든 정보를 포함하고 있는 포드그룹을 직접 읽을 수 있습니다.

업데이트된 구성은 다음과 같습니다. 워크로드 컨트롤러(예: Job 컨트롤러)는 이제 포드 그룹 객체의 스펙(spec) 필드를 포함하는 정적 템플릿인 워크로드 객체를 정의합니다.

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

이후 컨트롤러는 해당 템플릿을 기반으로 런타임 포드그룹 인스턴스를 생성합니다. 런타임 포드그룹 객체는 실제 스케줄링 정책을 보유하며 생성된 템플릿을 참조합니다. 또한 개별 포드의 상태를 반영하는 조건(conditions)이 포함된 상태(status)를 가져 그룹 전체의 스케줄링 상태를 나타냅니다.

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

마지막으로, 이 새로운 아키텍처를 개별 포드와 연결하기 위해 포드 API의 workloadRef 필드가 schedulingGroup 필드로 대체되었습니다. 포드를 생성할 때 런타임 포드그룹에 직접 링크합니다.

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

워크로드를 정적 템플릿으로 유지하고 포드그룹을 독립적인 1급(first-class) API로 격상함으로써, 향후 Kubernetes 릴리스에서 고급 워크로드 스케줄링 기능을 구축할 수 있는 강력한 토대를 마련했습니다.

포드그룹 스케줄링 사이클 및 갱 스케줄링

이러한 워크로드를 효율적으로 관리하기 위해 kube-scheduler는 이제 전용 포드그룹 스케줄링 사이클을 가집니다. 리소스를 포드 단위로 순차적으로 평가하고 예약하여 스케줄링 데드락 위험을 초래하는 대신, 스케줄러는 그룹을 하나의 통합된 작업으로 평가합니다.

스케줄러가 스케줄링 큐에서 포드그룹 멤버를 꺼낼 때, 그룹의 특정 정책과 관계없이 해당 그룹에 대해 대기 중인 나머지 포드들을 가져와 결정론적으로 정렬하고 다음과 같이 원자적 스케줄링 사이클을 실행합니다.

스케줄러는 전체 그룹을 평가하는 동안 경쟁 상태를 방지하고 일관성을 보장하기 위해 클러스터 상태의 단일 스냅샷을 생성합니다.
그런 다음 표준 포드 기반 필터링 및 점수화 단계를 활용하는 포드그룹 스케줄링 알고리즘을 사용하여 그룹 내 모든 포드에 대해 유효한 노드 배치를 찾으려 시도합니다.
알고리즘의 결과에 따라 스케줄링 결정이 전체 포드그룹에 대해 원자적으로 적용됩니다.
- 성공: 배치를 찾았고 그룹 제약 조건이 충족되면, 스케줄링 가능한 멤버 포드들이 함께 바인딩(binding) 단계로 이동합니다. 남은 스케줄링 불가능한 포드들은 리소스가 확보되어 이미 스케줄링된 포드들에 합류할 수 있을 때까지 스케줄링 큐로 돌아가 대기합니다. (참고: 일부 포드가 이미 스케줄링된 후 포드그룹에 새 포드가 추가되면, 사이클은 기존 포드를 고려하면서 새 포드를 평가합니다. 결정적으로, 이미 노드에 할당된 포드들은 계속 실행 상태를 유지합니다. 스케줄러는 이후 사이클에서 그룹이 요구 사항을 충족하지 못하더라도 이미 할당된 포드를 할당 해제하거나 퇴거시키지 않습니다.)
- 실패: 그룹이 요구 사항을 충족하지 못하면 전체 그룹이 스케줄링 불가능한 것으로 간주됩니다. 어떤 포드도 바인딩되지 않으며, 나중에 백오프(backoff) 기간 후에 다시 시도하기 위해 스케줄링 큐로 돌아갑니다.

이 사이클은 갱 스케줄링의 기반 역할을 합니다. 워크로드에 엄격한 전부 아니면 전무(all-or-nothing) 배치가 필요한 경우, gang 정책은 이 사이클을 활용하여 리소스 낭비와 잠재적 데드락을 유발하는 부분 배포를 방지합니다.

스케줄러는 여전히 minCount 요구 사항이 충족될 때까지 PreEnqueue에서 포드들을 유지하지만, 실제 스케줄링 단계는 이제 전적으로 새로운 포드그룹 사이클에 의존합니다. 구체적으로 알고리즘 실행 중에 스케줄러는 스케줄링 가능한 포드 수가 minCount를 만족하는지 확인합니다. 클러스터가 필요한 최소 수량을 수용할 수 없으면 어떤 포드도 바인딩되지 않습니다. 그룹은 실패하며 충분한 리소스가 확보될 때까지 기다립니다.

한계점

포드그룹 스케줄링 사이클의 첫 번째 버전에는 몇 가지 한계가 있습니다.

동질적(homogeneous) 포드 그룹(즉, 모든 포드의 스케줄링 요구 사항이 동일하고 포드 간 어피니티, 안티 어피니티 또는 토폴로지 스프레드 제약 조건과 같은 의존성이 없는 경우)의 경우, 배치가 존재한다면 알고리즘이 이를 찾아낼 것으로 예상됩니다.
이질적(heterogeneous) 포드 그룹의 경우, 해결책이 명백해 보이더라도 유효한 배치를 찾는 것이 보장되지 않습니다.
포드 간 의존성이 있는 포드 그룹의 경우, 유효한 배치를 찾는 것이 보장되지 않습니다.

위 사항 외에도 그룹 내 의존성(예: 한 포드의 스케줄링 가능 여부가 포드 간 어피니티를 통해 다른 그룹 멤버에 의존하는 경우)이 포함된 경우, 결정론적인 처리 순서로 인해 클러스터 상태와 관계없이 알고리즘이 배치를 찾지 못할 수 있습니다.

토폴로지 인식형 스케줄링

AI/ML 학습이나 배치 처리와 같은 복잡한 분산 워크로드의 경우, 클러스터 전체에 포드를 무작위로 배치하면 상당한 네트워크 지연이 발생하고 전반적인 성능 저하의 원인이 될 수 있습니다.

토폴로지 인식형 스케줄링은 포드그룹에 직접 토폴로지 제약 조건을 정의할 수 있게 함으로써 이 문제를 해결하며, 포드들이 특정 물리적 또는 논리적 도메인 내에 함께 배치되도록 보장합니다.

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
 name: topology-aware-workers-pg
spec:
 schedulingPolicy:
 gang:
 minCount: 4
 # 랙(rack) 토폴로지를 기반으로 포드들이 함께 배치되도록 강제함
 schedulingConstraints:
 topology:
 - key: topology.kubernetes.io/rack

이 예시에서 kube-scheduler는 rack 토폴로지 제약 조건과 일치하는 다양한 노드 조합에 포드를 스케줄링하려고 시도합니다. 그런 다음 포드그룹이 리소스를 얼마나 효율적으로 활용하는지, 해당 도메인 내에서 얼마나 많은 포드가 성공적으로 스케줄링될 수 있는지를 기준으로 최적의 배치를 선택합니다.

이를 위해 스케줄러는 세 단계로 구성된 전용 배치 기반 알고리즘으로 포드그룹 스케줄링 사이클을 확장했습니다.

그룹의 스케줄링 제약 조건을 기반으로 후보 배치(포드그룹 할당이 이론적으로 가능한 노드 서브셋)를 생성합니다. 토폴로지 인식형 스케줄링 플러그인은 새로운 PlacementGenerate 확장 지점을 사용하여 이러한 배치를 만듭니다.
제안된 각 배치를 평가하여 전체 포드그룹이 실제로 그곳에 들어갈 수 있는지 확인합니다.
실행 가능한 모든 배치의 점수를 매겨 포드그룹에 가장 적합한 배치를 선택합니다. 토폴로지 인식형 스케줄링 플러그인은 새로운 PlacementScore 확장 지점을 사용하여 이러한 배치의 점수를 매깁니다.

현재 토폴로지 인식형 스케줄링은 제약 조건을 충족하기 위해 포드 선점을 트리거하지 않습니다. 그러나 향후 릴리스에서 워크로드 인식형 선점과 토폴로지 제약 조건을 통합할 계획입니다.

Kubernetes v1.36은 이러한 기초적인 토폴로지 인식형 스케줄링을 제공하지만, Kubernetes 프로젝트는 곧 그 기능을 확장할 계획입니다. 향후 업데이트에서는 다중 토폴로지 레벨 지원, 소프트 제약 조건(기본 설정), 동적 리소스 할당(DRA)과의 긴밀한 통합, 그리고 basic 스케줄링 정책과 함께 사용될 때의 더 견고한 동작 등을 도입할 예정입니다.

워크로드 인식형 선점

새로운 포드그룹 스케줄링 사이클을 지원하기 위해 Kubernetes v1.36은 워크로드 인식형 선점이라는 새로운 유형의 선점 메커니즘을 도입했습니다. 포드그룹을 스케줄링할 수 없을 때, 스케줄러는 이 메커니즘을 활용하여 해당 포드그룹의 스케줄링이 가능하도록 시도합니다.

표준 포드 단위 스케줄링 사이클에서 사용되는 기본 선점과 비교하여, 이 새로운 메커니즘은 전체 포드그룹을 단일 선점자 단위로 취급합니다. 각 노드에서 개별적으로 선점 대상을 평가하는 대신, 클러스터 전체에서 검색을 수행합니다. 이를 통해 스케줄러는 여러 노드에서 동시에 포드를 선점하여 나중에 전체 포드그룹을 스케줄링할 수 있는 충분한 공간을 확보할 수 있습니다.

워크로드 인식형 선점은 또한 포드그룹 API에 직접 두 가지 추가 개념을 도입합니다.

포드그룹을 형성하는 개별 포드의 우선순위를 덮어쓰는 포드그룹 우선순위(priority).
포드그룹 내의 포드들이 독립적으로 선점될 수 있는지, 아니면 전부 아니면 전무 방식으로 함께 선점되어야 하는지를 결정하는 포드그룹 중단 모드(disruptionMode).

Kubernetes v1.36에서 이 필드들은 워크로드 인식형 선점 메커니즘에서만 존중됩니다. 이 기능들을 개발 중인 팀은 향후 릴리스에서 포드 단위 스케줄링 사이클에서 사용되는 기본 선점을 포함하여 다른 중단 소스로도 이 필드들의 지원을 확장하기를 희망하고 있습니다.

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
 name: victim-pg
spec:
 priorityClassName: high-priority
 priority: 1000
 disruptionMode: PodGroup

이 예시에서 스케줄러가 워크로드 인식형 선점 사이클 동안 victim-pg를 잠재적 선점 대상으로 평가할 때, 우선순위로 1000을 사용하며 해당 포드그룹을 엄격한 전부 아니면 전무 방식으로 선점합니다.

DRA 워크로드 리소스클레임(ResourceClaim) 지원

Kubernetes v1.34에서 정식 버전(GA)이 된 이후, DRA는 포드가 GPU, TPU, NIC와 같은 장치에 대해 상세한 요청을 할 수 있게 해주었습니다. 요청된 장치는 동일한 리소스클레임(ResourceClaim)을 이름으로 요청하는 여러 포드에 의해 공유될 수 있습니다. 다른 요청들은 리소스클레임 템플릿(ResourceClaimTemplate)을 통해 복제될 수 있으며, 이 경우 Kubernetes는 템플릿을 참조하는 각 포드에 대해 비결정적인 이름을 가진 하나의 리소스클레임을 생성합니다. 그러나 특정 포드들이 특정 장치를 공유해야 하는 대규모 워크로드의 경우, 현재는 개별 리소스클레임을 직접 생성하고 관리해야 하는 상황입니다.

이제 포드뿐만 아니라 포드그룹도 리소스클레임 템플릿의 복제 단위가 될 수 있습니다. 포드그룹의 spec.resourceClaims 중 하나에서 참조하는 리소스클레임 템플릿에 대해, Kubernetes는 그룹 내에 포드가 얼마나 많든 관계없이 전체 포드그룹에 대해 단 하나의 리소스클레임을 생성합니다. 포드의 spec.resourceClaims 중 하나가 해당 포드그룹의 spec.resourceClaims 중 하나와 일치할 경우, 해당 포드의 클레임은 포드그룹을 위해 생성된 리소스클레임으로 해석되며 해당 개별 포드를 위한 리소스클레임은 생성되지 않습니다. 워크로드 객체 내의 단일 포드그룹 템플릿은 각 별개의 포드그룹마다 복사되면서도 각 그룹 내의 포드들이 공유할 수 있는 리소스 요청을 표현할 수 있습니다.

다음 예시는 포드그룹을 위해 생성된 동일한 리소스클레임을 요청하는 두 개의 포드를 보여줍니다.

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
 name: training-job-workers-pg
spec:
 ...
 resourceClaims:
 - name: pg-claim
 resourceClaimTemplateName: my-claim-template
---
apiVersion: v1
kind: Pod
metadata:
 name: topology-aware-workers-pg-pod-1
spec:
 ...
 schedulingGroup:
 podGroupName: training-job-workers-pg
 resourceClaims:
 - name: pg-claim
 resourceClaimTemplateName: my-claim-template
---
apiVersion: v1
kind: Pod
metadata:
 name: topology-aware-workers-pg-pod-2
spec:
 ...
 schedulingGroup:
 podGroupName: training-job-workers-pg
 resourceClaims:
 - name: pg-claim
 resourceClaimTemplateName: my-claim-template

또한, resourceClaimName을 통하거나 resourceClaimTemplateName으로부터 생성된 클레임을 통해 포드그룹이 참조하는 리소스클레임은 전체 포드그룹을 위해 예약됩니다. 이전에는 kube-scheduler가 리소스클레임의 status.reservedFor 필드에 개별 포드만 나열할 수 있었는데, 이 필드는 256개 항목으로 제한되어 있었습니다. 이제 status.reservedFor의 단일 포드그룹 참조가 256개보다 훨씬 많은 포드를 나타낼 수 있게 되어, 장치의 고카디널리티(high-cardinality) 공유가 가능해졌습니다.

이러한 변화를 통해 복잡한 토폴로지를 가진 대규모 워크로드가 확장 가능한 장치 관리를 위해 DRA를 활용할 수 있게 되었습니다.

Job 컨트롤러와의 통합

Kubernetes v1.36에서 Job 컨트롤러는 사용자를 대신해 워크로드 및 포드그룹 객체를 생성하고 관리할 수 있습니다. 이를 통해 분산 AI 학습과 같이 긴밀하게 결합된 병렬 애플리케이션을 나타내는 Job들이 추가적인 도구 없이도 갱 스케줄링될 수 있습니다. 이러한 통합이 없다면 사용자가 직접 워크로드와 포드그룹을 생성하고 포드 템플릿에 참조를 연결해야 했을 것입니다. 이제 Job 컨트롤러가 이 과정을 네이티브하게 자동화합니다.

WorkloadWithJob 기능 게이트가 활성화되면 Job 컨트롤러는 자동으로 다음을 수행합니다.

각 적격 Job에 대해 워크로드와 그에 대응하는 런타임 포드그룹을 생성합니다.
Job이 생성하는 모든 포드에 .spec.schedulingGroup을 설정하여 스케줄러가 이를 하나의 갱(gang)으로 취급하게 합니다.
Job을 생성된 객체들의 소유자(owner)로 설정하여 Job이 삭제될 때 해당 객체들도 함께 가비지 컬렉션되도록 합니다.

통합이 적용되는 경우는 언제인가요?

첫 번째 기능 반복의 예측 가능성을 유지하기 위해, Job 컨트롤러는 Job이 다음과 같이 명확하게 고정된 형태를 가질 때만 워크로드와 포드그룹을 생성합니다.

.spec.parallelism이 1보다 큽니다.
.spec.completionMode가 Indexed로 설정되어 있습니다.
.spec.completions가 .spec.parallelism과 같습니다.
포드 템플릿에 schedulingGroup이 아직 설정되어 있지 않습니다.

이러한 조건들은 갱 스케줄링이 합리적으로 판단할 수 있는 Job 클래스를 설명합니다. 각 포드는 안정적인 식별자(Indexed)를 가지고, 갱의 크기는 승인 시점에 알려져 있으며 고정되어 있고(parallelism == completions), 다른 컨트롤러가 스케줄링 책임을 이미 맡지 않은 상태(schedulingGroup 필드가 비어 있음)입니다. 이러한 조건을 충족하지 않는 Job은 이전과 동일하게 포드 단위로 스케줄링됩니다.

포드 템플릿에 schedulingGroup을 직접 설정한 경우(예: 상위 레벨 컨트롤러가 워크로드를 관리하는 경우), Job 컨트롤러는 포드 템플릿을 건드리지 않으며 자체 워크로드나 포드그룹을 생성하지 않습니다. 덕분에 이미 외부 배치 시스템을 사용 중인 클러스터에서도 이 기능을 안전하게 활성화할 수 있습니다.

다음은 갱 스케줄링 자격을 갖춘 Job의 예시입니다.

apiVersion: batch/v1
kind: Job
metadata:
 name: training-job
 namespace: job-ns
spec:
 completionMode: Indexed
 parallelism: 4
 completions: 4
 template:
 spec:
 restartPolicy: Never
 containers:
 - name: worker
 image: registry.example/trainer:latest

Job 컨트롤러는 이 Job이 소유하는 워크로드와 포드그룹을 생성하며, 생성된 모든 포드는 생성된 포드그룹을 가리키는 .spec.schedulingGroup을 가집니다. 그런 다음 앞서 설명한 포드그룹 스케줄링 사이클을 통해 네 개의 포드가 모두 동시에 배치될 수 있을 때 함께 스케줄링됩니다.

아직 지원되지 않는 사항

현재의 제약 조건으로 인해 이 통합은 정적이고 인덱싱된 완전 병렬 Job으로 제한됩니다. 탄력적(elastic) Job 및 다른 내장 컨트롤러를 포함한 추가 워크로드 형태에 대한 지원은 KEP-5547에서 추적 중입니다.

향후 Kubernetes 릴리스에서는 이 통합이 추가적인 워크로드 컨트롤러를 지원하도록 확장될 것이며, Job에 대한 현재의 제약 조건도 완화될 수 있습니다.

향후 계획

워크로드 인식형 스케줄링의 여정은 여기서 멈추지 않습니다. v1.37을 위해 커뮤니티는 다음 사항들을 활발히 준비하고 있습니다.

워크로드 및 포드그룹 API의 Beta 졸업: 주요 목표는 워크로드 및 포드그룹 API를 Beta 단계로 성숙시켜 Kubernetes 생태계에서의 기초적인 역할을 공고히 하는 것입니다. 이 졸업 과정의 일환으로 탄력적 Job을 가능하게 하고 동적 워크로드가 효율적으로 확장될 수 있도록 minCount 가변성(mutability)을 도입할 계획입니다.
다단계 워크로드 계층 구조: JobSet 또는 LeaderWorkerSet(LWS)을 통한 분산 추론(Disaggregated Inference)과 같이 복잡한 현대 AI 워크로드를 지원하기 위해 아키텍처를 다단계 계층 구조로 확장하는 작업을 진행 중입니다. 실제 워크로드 컨트롤러의 조직을 직접 반영하여 여러 포드그룹을 계층 구조로 그룹화할 수 있는 새로운 API 도입을 목표로 하고 있습니다.
고급 스케줄링 기능의 졸업: 광범위한 워크로드 인식형 스케줄링 생태계의 성숙도를 높이는 데 집중하고 있습니다. 여기에는 토폴로지 인식형 스케줄링 및 워크로드 인식형 선점과 같은 기존 기능들을 Beta 단계로 올리는 작업이 포함됩니다.
통합 컨트롤러 통합 API: 도입을 간소화하기 위해 컨트롤러 통합 API를 개발 중입니다. 이는 실제 워크로드 컨트롤러가 워크로드 인식형 스케줄링 기능을 사용하기 위한 통합되고 표준화된 방법을 제공할 것입니다.

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

시작하기

아래의 모든 워크로드 인식형 스케줄링 개선 사항은 v1.36에서 Alpha 기능으로 제공됩니다. 이를 사용해 보려면 다음을 구성해야 합니다.

필수 조건: 워크로드 및 포드그룹 API 지원: kube-apiserver와 kube-scheduler 모두에서 GenericWorkload 기능 게이트를 활성화하고, scheduling.k8s.io/v1alpha2 API 그룹이 활성화되어 있는지 확인하세요.

필수 조건이 충족되면 특정 기능을 활성화할 수 있습니다.

갱 스케줄링: kube-scheduler에서 GangScheduling 기능 게이트를 활성화합니다.
토폴로지 인식형 스케줄링: kube-scheduler에서 TopologyAwareWorkloadScheduling 기능 게이트를 활성화합니다.
워크로드 인식형 선점: kube-scheduler에서 WorkloadAwarePreemption 기능 게이트를 활성화합니다 (GangScheduling 활성화가 함께 필요합니다).
DRA 워크로드 리소스클레임 지원: kube-apiserver, kube-controller-manager, kube-scheduler 및 kubelet에서 DRAWorkloadResourceClaims 기능 게이트를 활성화합니다.
Job 컨트롤러와 워크로드 API 통합: kube-apiserver 및 kube-controller-manager에서 EnableWorkloadWithJob 기능 게이트를 활성화합니다.

테스트 클러스터에서 워크로드 인식형 스케줄링을 사용해 보시고, Kubernetes 스케줄링의 미래를 만드는 데 도움이 될 경험을 공유해 주시길 권장합니다. 다음 채널을 통해 의견을 보내실 수 있습니다.

Slack (#workload-aware-scheduling)을 통한 연락.
SIG Scheduling 회의 참여.
Kubernetes 저장소에 새로운 이슈(issue) 등록.

더 알아보기

이 기능들의 아키텍처와 설계에 대해 더 자세히 알아보려면 다음 KEP들을 읽어보세요.