토폴로지 인지 스케줄링

토폴로지 인지 스케줄링 (Topology-Aware Scheduling)

토폴로지 인지 스케줄링(TAS)은 클러스터 내 파드 배치를 최적화하는 Workload API의 기능이에요.

TAS는 PodGroup의 모든 파드가 단일 서버 랙이나 존과 같은 특정 토폴로지 영역에 함께 배치(co-location)되도록 보장합니다. 이는 파드 간 통신 지연을 최소화하고 클러스터 인프라 전반에 걸친 워크로드 분산을 방지합니다.

출처: 문서

본문

갱 스케줄링 정책과 함께하는 토폴로지 인지 스케줄링

gang 스케줄링 정책을 가진 PodGroup에 적용되면, TAS는 파드 그룹 전체의 잠재적 배치(placement)를 한 번에 시뮬레이션합니다. 리소스를 확정하기 전에 지정된 minCount 이상의 파드가 같은 토폴로지 영역에 함께 들어갈 수 있음을 보장합니다. 실행 가능한 배치가 없으면 전체 PodGroup이 스케줄 불가가 됩니다.

이것은 파드 간 통신 지연을 최소화하기 위해 근접성을 엄격히 요구하는 분산 AI·ML 학습 같은 워크로드에 권장되는 접근 방식입니다.

일부 파드가 이미 스케줄링된 PodGroup에 새 파드가 추가되면(예: 파드가 재생성되는 경우), 스케줄러는 모든 새 수신 파드가 기존 파드가 있는 정확히 같은 토폴로지 영역에 배치되도록 강제합니다. 그 특정 영역에 새 파드를 위한 충분한 용량이 없으면, 설령 그 시점에 minCount보다 적은 파드가 스케줄링될지라도 파드는 Pending 상태로 남게 됩니다.

v1.36 기준으로 토폴로지 인지 스케줄링은 워크로드나 파드 선점을 트리거하지 않습니다. 선점을 트리거하지 않고 실행 가능한 배치를 찾을 수 없으면 PodGroup은 스케줄 불가가 됩니다.

기본 스케줄링 정책과 함께하는 토폴로지 인지 스케줄링

basic 스케줄링 정책과 TAS를 사용하면 일관성 없는 동작이 나타날 수 있어요. 스케줄러는 PodGroup 스케줄링 주기에 진입할 때 파드의 일부만 관찰할 수 있습니다 — 따라서 배치 가능성은 전체 PodGroup이 아닌 관찰된 파드에 대해서만 평가됩니다. 이 제한을 부분적으로 완화하려면 스케줄링 게이트를 사용해 PodGroup 내 모든 파드가 스케줄링 큐에 들어갈 때까지 PodGroup 스케줄링을 보류할 수 있습니다.

전체 PodGroup에 대한 실행 가능한 배치를 찾지 못하면 파드의 일부만 스케줄링될 수 있으며, 그들은 스케줄링 제약을 충족함이 보장됩니다.

일부 파드가 이미 스케줄링된 PodGroup에 새 파드가 추가되면, 스케줄러는 gang 정책의 경우와 똑같이 동작합니다 — 용량이 부족하지 않는 한 새 파드를 같은 영역에 강제로 배치합니다(용량이 부족하면 새 파드는 Pending 상태로 남습니다).

API 구성: 스케줄링 제약

모든 PodGroup(또는 PodGroupTemplate)은 선택적으로 schedulingConstraints 필드를 선언할 수 있으며, 이는 배치 기반 PodGroup 스케줄링 알고리즘에 의해 해석됩니다. 제약이 PodGroupTemplate에 정의되면 참조하는 PodGroup에 복사됩니다.

쿠버네티스 v1.36 기준으로 API는 토폴로지 제약을 지원합니다.

쿠버네티스 v1.36 기준으로 각 PodGroup에는 단일 토폴로지 제약만 지정할 수 있습니다.

토폴로지 제약

PodGroup의 토폴로지 제약을 정의하려면 대상 토폴로지 영역(예: 랙이나 존)을 나타내는 쿠버네티스 노드 라벨에 해당하는 key를 설정해야 해요. 스케줄러는 PodGroup 내 모든 파드가 이 지정된 라벨에 대해 정확히 같은 값을 공유하는 노드에 배치되도록 엄격히 강제합니다.

다음은 토폴로지 제약으로 구성된 PodGroup의 예시입니다:

apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: example-podgroup
spec:
  schedulingPolicy:
    gang:
      minCount: 4
  schedulingConstraints:
    topology:
      - key: topology.example.com/rack

멀티레벨 토폴로지 인지 스케줄링

복잡한 워크로드는 클러스터 인프라의 서로 다른 수준에서 파드의 공동 배치를 요구할 수 있어요. 예를 들어 전체 워크로드가 단일 가용성 영역 안에서 실행되어야 하는 반면, 워크로드의 다른 부분은 특정 서버 랙 안에서 엄격히 공동 배치되어야 할 수 있습니다.

이런 멀티레벨 공동 배치 요구 사항은 CompositePodGroup API와 그룹 계층의 서로 다른 수준에 토폴로지 제약을 지정함으로써 표현할 수 있어요.

CompositePodGroup API를 사용하려면 CompositePodGroup 기능 게이트와 scheduling.k8s.io/v1alpha3 API 버전을 활성화해야 합니다.

멀티레벨 토폴로지 제약 해석

CompositePodGroup 계층의 모든 그룹은 토폴로지 제약을 지정할 수 있으며, 이는 그 그룹의 모든 하위 파드가 그 그룹의 제약과 일치하는 같은 토폴로지 영역에 스케줄링되도록 보장합니다.

계층적 스케줄링 중에 스케줄러는 이런 제약을 하향식으로 해석합니다. 구체적으로, 하위 그룹의 스케줄링 중 고려되는 토폴로지 영역은 부모 그룹이 가정한 배치에 해당하는 토폴로지 영역 안으로 한정됩니다.

쿠버네티스는 토폴로지 라벨의 물리적 계층에 대해 어떤 엄격한 요구 사항도 부과하지 않습니다 — 토폴로지 키는 임의의 노드 라벨입니다. 그러나 부모에서 자식으로 토폴로지 제약을 지정하는 순서가 스케줄러가 토폴로지 영역을 세분화하는 순서를 결정합니다.

쿠버네티스 v1.37 기준으로 각 CompositePodGroup에는 단일 토폴로지 제약만 지정할 수 있습니다.

예시

다음 예시는 부모 CompositePodGroupTemplate이 전체 워크로드를 단일 가용성 영역(topology.example.com/zone)으로 제약하고, 두 하위 PodGroupTemplate 항목(workers와 driver)이 해당 영역 안의 서버 랙(topology.example.com/rack)으로 각각의 파드를 제약하는 Workload를 구성합니다:

apiVersion: scheduling.k8s.io/v1alpha3
kind: Workload
metadata:
  name: example-workload
spec:
  compositePodGroupTemplates:
  - name: root
    schedulingPolicy:
      gang:
        minGroupCount: 2
    schedulingConstraints:
      topology:
      - key: topology.example.com/zone
    podGroupTemplates:
    - name: workers
      schedulingPolicy:
        gang:
          minCount: 8
      schedulingConstraints:
        topology:
        - key: topology.example.com/rack
    - name: driver
      schedulingPolicy:
        gang:
          minCount: 1
      schedulingConstraints:
        topology:
        - key: topology.example.com/rack

Workload 객체를 만든 후, 해당 그룹 객체는 다음과 같이 생성됩니다:

root 템플릿을 참조하는 루트 CompositePodGroup.
각각 루트 CompositePodGroup을 부모 그룹으로 참조하는 두 하위 PodGroup 객체(workers와 driver).

apiVersion: scheduling.k8s.io/v1alpha3
kind: CompositePodGroup
metadata:
  name: workload-root
spec:
  workloadRef:
    workloadName: example-workload
    templateName: root
  schedulingPolicy:
    gang:
      minGroupCount: 2
  schedulingConstraints:
    topology:
    - key: topology.example.com/zone
---
apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: workload-workers
spec:
  parentCompositePodGroupName: workload-root
  workloadRef:
    workloadName: example-workload
    templateName: workers
  schedulingPolicy:
    gang:
      minCount: 8
  schedulingConstraints:
    topology:
    - key: topology.example.com/rack
---
apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: workload-driver
spec:
  parentCompositePodGroupName: workload-root
  workloadRef:
    workloadName: example-workload
    templateName: driver
  schedulingPolicy:
    gang:
      minCount: 1
  schedulingConstraints:
    topology:
    - key: topology.example.com/rack

스케줄링 중 스케줄러는 먼저 workload-root의 가용성 영역을 선택합니다. 그 다음 그 영역의 노드를 랙별로 세분화해 선택된 영역 안에서 workload-workers와 workload-driver의 실행 가능한 랙 배치를 찾습니다.

예를 들어, 다음과 같이 라벨이 지정된 다섯 개의 노드가 있는 클러스터를 생각해 보겠습니다:

노드	`topology.example.com/zone`	`topology.example.com/rack`
`node-a`	`zone-1`	`rack-1`
`node-b`	`zone-1`	`rack-1`
`node-c`	`zone-1`	`rack-2`
`node-d`	`zone-2`	`rack-1`
`node-e`	`zone-2`	`rack-3`

workload-root를 처리할 때 스케줄러는 topology.example.com/zone 토폴로지 키를 기반으로 모든 클러스터 노드에 걸쳐 후보 배치를 평가합니다:

평가된 후보 배치	후보 배치의 노드
`zone-1`	`node-a`, `node-b`, `node-c`
`zone-2`	`node-d`, `node-e`

workload-workers의 후보 배치를 평가할 때 스케줄러는 workload-root가 가정한 배치 안의 노드만을 topology.example.com/rack 토폴로지 키를 기반으로 세분화합니다:

부모 배치	평가된 후보 배치	후보 배치의 노드
`zone-1`	`rack-1`	`node-a`, `node-b`
`zone-1`	`rack-2`	`node-c`
`zone-2`	`rack-1`	`node-d`
`zone-2`	`rack-3`	`node-e`

형제 workload-driver PodGroup에 대해 생성된 후보 배치는 두 그룹이 같은 토폴로지 키(topology.example.com/rack)를 지정하므로 workload-workers에 대해 생성된 것과 동일합니다.

더 알아보기 (Learn more)

파드 그룹 정책 알아보기.
토폴로지 인지 스케줄링 관련 플러그인 알아보기.
갱 스케줄링 알고리즘 읽기.
스케줄링 구성 요소와 workloadbuilder 라이브러리 알아보기 (스케줄링 제약 구성 요소 포함).