스케줄링 구성 요소 API와 workloadbuilder 라이브러리

스케줄링 구성 요소 API와 workloadbuilder 라이브러리 (Scheduling Building Block APIs and the workloadbuilder Library)

인트리(in-tree)와 아웃오브트리(out-of-tree) 워크로드 컨트롤러가 자신의 API에 임베드하는 재사용 가능한 스케줄링 API 프리미티브와, 그 프리미티브를 Workload, PodGroup, CompositePodGroup 객체로 컴파일하는 공유 workloadbuilder 라이브러리에 관한 문서예요.

기능 상태: Kubernetes v1.37부터 Beta, 기본 비활성화

이 기능을 사용하려면 사용자(또는 클러스터 관리자)가 클러스터의 모든 관련 컴포넌트에서 GenericWorkload feature gate를 활성화해야 해요.

Workload-aware Scheduling은 scheduling.k8s.io API 그룹 아래 재사용 가능한 API 빌딩 블록 집합을 정의해요. 컨트롤러 작성자는 이 프리미티브를 자신의 API에 임베드해서 사용자가 갱 스케줄링(gang scheduling), 토폴로지, 중단(disruption) 동작 같은 스케줄링 의도를 생태계 전반에서 일관된 스키마로 표현하게 하고, 공유 workloadbuilder 라이브러리가 그 의도를 스케줄러가 다루는 Workload, PodGroup, CompositePodGroup 객체로 컴파일해요.

오늘날 이 빌딩 블록의 내장 소비자는 WorkloadWithJob feature gate로 제어되는 Job 컨트롤러예요.

재사용 가능한 빌딩 블록

빌딩 블록은 scheduling.k8s.io/v1alpha3 API 그룹의 강한 타입 Go struct예요. 컨트롤러 작성자를 위한 것으로, 컨트롤러가 이 struct를 자신의 API 타입에 필드로 임베드하고 workloadbuilder 라이브러리가 컴파일해요. 타입 이름은 두 가지 규칙을 따르는데, 리프(leaf) 레벨 타입은 WorkloadPodGroup... 접두사(예: WorkloadPodGroupSchedulingPolicy), 다중 레벨 변형은 WorkloadCompositePodGroup... 접두사를 써요.

각 컨트롤러는 자신의 API에 어울리는 필드 이름과 구조를 선택하므로, 이 블록들은 고정된 최상위 형태를 강제하지 않아요. 엄격히 강제되진 않지만, 표준 필드 이름과 구조를 재사용하는 것이 권장돼요. 한 컨트롤러 리소스에서 갱 스케줄링을 구성한 사용자가 다른 컨트롤러에서도 같은 옵션을 인식할 수 있도록요.

빌딩 블록을 채택하려면 컨트롤러가 지원하려는 블록을 자신의 타입에 필드로 추가해요. 예를 들어 Job API는 네 블록 모두를 spec.scheduling에서 도달할 수 있는 단일 타입으로 그룹화해요.

type JobSchedulingConfiguration struct {
    SchedulingPolicy      *schedulingv1alpha3.WorkloadPodGroupSchedulingPolicy
    SchedulingConstraints *schedulingv1alpha3.WorkloadPodGroupSchedulingConstraints
    DisruptionMode        *schedulingv1alpha3.WorkloadPodGroupDisruptionMode
    ResourceClaims        []schedulingv1alpha3.WorkloadPodGroupResourceClaim
}

다른 컨트롤러는 다중 부분 워크로드의 컴포넌트별로 같은 블록을 중첩하거나 그중 일부만 지원할 수 있어요.

스케줄링 정책 (Scheduling policy)

스케줄링 정책 블록은 PodGroup의 spec.schedulingPolicy와 같은 basic과 gang 정책을 담아요. 각 정책이 무엇을 의미하는지에 대해서는 PodGroup 스케줄링 정책을 참고하세요. 갱 스케줄링은 워크로드의 모든 Pod가 동시에 스케줄링될 수 있을 때만 스케줄링되도록 요구해요. 이는 스케줄링 봉쇄(scheduling deadlock)를 피하고 대규모 분산 워크로드가 시작 시점에 함께 올라가도록 보장하는 데 유용해요.

더 알아보기 (Learn more)