Penjadwalan PyTorchJob multi-kluster dengan antrian prioritas - Container Service for Kubernetes

Pekerjaan pelatihan terdistribusi PyTorch memerlukan semua Pod dalam suatu pekerjaan untuk berjalan secara bersamaan—menjalankan hanya sebagian akan membuang sumber daya dan menyebabkan pekerjaan hang tanpa batas. Gang scheduling memberlakukan jaminan all-or-nothing: semua Pod dalam pekerjaan dijadwalkan bersama atau tidak sama sekali. Pendekatan ini mencegah deadlock sumber daya dalam skenario pelatihan multi-GPU dan multi-mesin.

Topik ini menjelaskan cara mengonfigurasi Kube Queue pada instans Fleet ACK untuk mengantrikan PyTorchJob serta menerapkan gang scheduling agar semua Pod ditempatkan secara atomik pada kluster anggota yang sama.

Cara kerja

Instans Fleet mengoordinasikan penjadwalan PyTorchJob di seluruh kluster anggota menggunakan dua komponen:

Kube Queue mengelola antrian pekerjaan dan menegakkan batas kuota elastis, menahan pekerjaan hingga sumber daya yang cukup tersedia di kluster anggota.
ACK Scheduler menerapkan semantik gang scheduling saat instans Fleet mendistribusikan Pod ke kluster anggota, memastikan semua replika (Master dan Worker) ditempatkan secara atomik.

Alur penjadwalan bekerja sebagai berikut:

PyTorchJob dikirim ke instans Fleet dengan PropagationPolicy yang menentukan customSchedulingType: Gang.
Jika manajemen antrian diaktifkan (suspension.scheduling: true), pekerjaan masuk ke Kube Queue dan menunggu hingga slot kuota tersedia.
Instans Fleet mengevaluasi sumber daya yang tersedia di seluruh kluster anggota dan memilih kluster target.
ACK Scheduler menempatkan semua Pod secara atomik pada kluster yang dipilih, mempertahankan semantik gang.
Instans Fleet memantau pekerjaan dan menyinkronkan status kembali.

Prasyarat

Sebelum memulai, pastikan Anda telah memiliki:

Suite AI cloud-native terinstal di kluster anggota — deploy hanya komponen Arena.
Kebijakan AliyunAdcpFullAccess RAM (Resource Access Management) dilampirkan pada Pengguna RAM Anda. Untuk detailnya, lihat Berikan izin kepada Pengguna RAM.
Tool baris perintah AMC terinstal. Untuk detailnya, lihat Gunakan AMC.
(Opsional) Pemesanan sumber daya diaktifkan jika Anda ingin instans Fleet menjamin konsistensi penjadwalan dengan kluster anggota. Pemesanan sumber daya memerlukan Kubernetes 1.28 atau lebih baru dan ACK Scheduler 6.8.0 atau lebih baru.

(Opsional) Aktifkan pemesanan sumber daya

Tanpa pemesanan sumber daya, instans Fleet memperkirakan kapasitas yang tersedia dengan menjumlahkan sisa sumber daya di seluruh node dalam kluster anggota. Dengan pemesanan sumber daya diaktifkan, instans Fleet menyimpan kapasitas aktual pada kluster target sebelum melakukan komitmen, sehingga keputusan penjadwalan tingkat Fleet sesuai dengan hasil di kluster anggota.

Login ke Konsol ACK dan klik Clusters di panel navigasi kiri.
Klik nama kluster Anda. Di panel navigasi kiri, klik Add-ons.
Di halaman Add-ons, temukan Kube Scheduler dan klik Configuration.
Di kotak dialog Kube Scheduler Parameters, atur enableReservation ke true dan klik OK.

Pilih mode penjadwalan

Dua mode tersedia:

Mode	Kapan digunakan	Konfigurasi utama
Gang scheduling only	Anda ingin Pod ditempatkan secara atomik tanpa mengelola antrian	Atur `customSchedulingType: Gang` dalam PropagationPolicy
Gang scheduling + queue management	Anda memiliki banyak pekerjaan yang bersaing untuk sumber daya terbatas dan memerlukan antrian teratur dengan penegakan kuota	Atur `customSchedulingType: Gang` dan `suspension.scheduling: true`

Ikuti Langkah 1 jika Anda memerlukan manajemen antrian; lewati ke Langkah 2 jika Anda hanya memerlukan gang scheduling.

Langkah 1 (Opsional): Siapkan antrian pekerjaan dengan Kube Queue

Gunakan ElasticQuotaTree untuk menentukan batas kuota dan mengontrol jumlah pekerjaan yang dapat berjalan secara konkuren di seluruh namespace.

Kirimkan ElasticQuotaTree ke instans Fleet. Contoh berikut mengonfigurasi kuota untuk namespace default yang hanya mengizinkan satu pekerjaan berjalan dalam satu waktu, dengan maksimum 10.000 CPU, 10.000 GiB memori, dan 10.000 GPU.

apiVersion: scheduling.sigs.k8s.io/v1beta1
kind: ElasticQuotaTree
metadata:
  name: elasticquotatree  # Hanya satu ElasticQuotaTree yang didukung.
  namespace: kube-system   # Harus dibuat di namespace kube-system.
spec:
  root:
    name: root
    max:
      cpu: 999900
      memory: 400000Gi
      kube-queue/max-jobs: 10000000000
      nvidia.com/gpu: 100000
    min:
      cpu: 999900
      memory: 400000Gi
      kube-queue/max-jobs: 10000000000
      nvidia.com/gpu: 100000
    children:
    - name: child-2
      max:
        kube-queue/max-jobs: 1  # Hanya satu pekerjaan yang dapat dikeluarkan dari antrian dalam satu waktu.
        cpu: 10000
        nvidia.com/gpu: 10000
        memory: 10000Gi
      namespaces:
        - default

Verifikasi bahwa Kube Queue telah membuat antrian yang sesuai:

kubectl get queue -n kube-queue

Output yang diharapkan:

NAME                 AGE
root-child-2-v5zxz   15d
root-kdzw7           15d

Langkah 2: Kirim PyTorchJob untuk penjadwalan multi-kluster

Kirim PropagationPolicy

PropagationPolicy memberi tahu instans Fleet cara mendistribusikan PyTorchJob di seluruh kluster anggota dan mode penjadwalan yang diterapkan.

Gang scheduling only

Atur customSchedulingType: Gang untuk mengaktifkan penempatan Pod atomik tanpa antrian.

apiVersion: policy.one.alibabacloud.com/v1alpha1
kind: PropagationPolicy
metadata:
  name: example-policy
  namespace: default
spec:
  propagateDeps: true
  failover:
    application:
      decisionConditions:
        tolerationSeconds: 30
      purgeMode: Immediately
  placement:
    replicaScheduling:
      replicaSchedulingType: Divided
      customSchedulingType: Gang
  resourceSelectors:
    - apiVersion: kubeflow.org/v1
      kind: PyTorchJob

Gang scheduling with queue management

Tambahkan suspension.scheduling: true agar instans Fleet menahan pekerjaan di Kube Queue hingga slot kuota tersedia, lalu menempatkan semua Pod secara atomik.

apiVersion: policy.one.alibabacloud.com/v1alpha1
kind: PropagationPolicy
metadata:
  name: example-policy
  namespace: default
spec:
  suspension:
    scheduling: true
  propagateDeps: true
  failover:
    application:
      decisionConditions:
        tolerationSeconds: 30
      purgeMode: Immediately
  placement:
    replicaScheduling:
      replicaSchedulingType: Divided
      customSchedulingType: Gang
  resourceSelectors:
    - apiVersion: kubeflow.org/v1
      kind: PyTorchJob

Kirim PyTorchJob

Kirimkan PyTorchJob berikut ke instans Fleet. Ini mendefinisikan satu Pod Master dan dua Pod Worker.

apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
  labels:
    app: pytorchjob
  name: pytorch-test
  namespace: default
spec:
  cleanPodPolicy: None
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      restartPolicy: Never
      template:
        metadata:
          labels:
            app: pytorchjob
          name: pytorch-test
        spec:
          schedulerName: default-scheduler
          containers:
          - command:
            - sh
            - -c
            - sleep 1h
            env:
            - name: NVIDIA_VISIBLE_DEVICES
              value: void
            - name: gpus
              value: "0"
            - name: workers
              value: "8"
            image: registry-cn-hangzhou.ack.aliyuncs.com/acs/nginx
            imagePullPolicy: Always
            name: pytorch
            resources:
              limits:
                cpu: "3"
              requests:
                cpu: "10m"
            volumeMounts:
            - mountPath: /dev/shm
              name: dshm
            workingDir: /root
          volumes:
          - emptyDir:
              medium: Memory
              sizeLimit: 2Gi
            name: dshm
    Worker:
      replicas: 2
      restartPolicy: OnFailure
      template:
        metadata:
          labels:
            app: pytorchjob
          name: pytorch-test
        spec:
          containers:
          - command:
            - bash
            - -c
            - |
              echo "$WORKER_INDEX"
              sleep 1h
            env:
            - name: WORKER_INDEX
              valueFrom:
                fieldRef:
                  fieldPath: metadata.labels['pytorch-replica-index']
            - name: NVIDIA_VISIBLE_DEVICES
              value: void
            - name: gpus
              value: "0"
            - name: workers
              value: "8"
            image: registry-cn-hangzhou.ack.aliyuncs.com/acs/nginx
            imagePullPolicy: Always
            name: pytorch
            resources:
              limits:
                cpu: "2"
              requests:
                cpu: "2"
                memory: "2Gi"
            volumeMounts:
            - mountPath: /dev/shm
              name: dshm
            workingDir: /root
          volumes:
          - emptyDir:
              medium: Memory
              sizeLimit: 2Gi
            name: dshm

Langkah 3: Verifikasi status pekerjaan

Jalankan perintah berikut pada instans Fleet untuk memastikan pekerjaan telah dijadwalkan dan semua Pod sedang berjalan.

Periksa status PyTorchJob pada instans Fleet:

kubectl get pytorchjob

Output yang diharapkan:

NAME           STATE     AGE
pytorch-test   Created   3m44s

Periksa kluster anggota tempat pekerjaan dijadwalkan:
```
kubectl describe pytorchjob pytorch-test
```
Cari ScheduleBindingSucceed dalam event. Bidang result menampilkan kluster target dan jumlah replika:
```
Normal   ScheduleBindingSucceed  4m59s   default-scheduler   Binding has been scheduled successfully. Result: {cfxxxxxx:0,[{master 1} {worker 2}]}
```
cfxxxxxx adalah ID kluster anggota tempat semua Pod akan berjalan.
Konfirmasi pekerjaan sedang berjalan di kluster anggota:
```
kubectl amc get pytorchjob -M
```
Output yang diharapkan:
```
NAME           CLUSTER    STATE     AGE     ADOPTION
pytorch-test   cfxxxxxx   Running   6m23s   Y
```
ADOPTION: Y berarti instans Fleet telah mengambil alih penjadwalan untuk pekerjaan ini.

Konfirmasi semua Pod sedang berjalan:

kubectl amc get pod -M

Output yang diharapkan:

NAME                    CLUSTER    READY   STATUS    RESTARTS   AGE
pytorch-test-master-0   cfxxxxxx   1/1     Running   0          7m16s
pytorch-test-worker-0   cfxxxxxx   1/1     Running   0          7m16s
pytorch-test-worker-1   cfxxxxxx   1/1     Running   0          7m16s

Ketiga Pod (satu Master dan dua Worker) berjalan di kluster yang sama, mengonfirmasi bahwa gang scheduling menempatkannya secara atomik.

Untuk memeriksa YAML lengkap PyTorchJob di kluster anggota, jalankan:

kubectl amc get pytorchjob pytorch-test -m ${member clusterid} -oyaml