Men-deploy GPU untuk workload batch dan AI dengan Dynamic Workload Scheduler


Halaman ini menunjukkan cara mengoptimalkan ketersediaan GPU untuk workload batch dan AI skala besar dengan GPU menggunakan Dynamic Workload Scheduler dan ProvisioningRequest.

Praktik terbaik:

Gunakan Dynamic Workload Scheduler untuk workload batch dan AI berskala besar yang dapat berjalan selama jam non-puncak dengan kondisi pengelolaan kapasitas GPU yang ditentukan. Hal ini dapat mencakup workload seperti pelatihan model deep learning atau simulasi dengan sejumlah besar GPU yang dibuat secara bersamaan.

Untuk menjalankan workload GPU di Google Kubernetes Engine (GKE) tanpa Dynamic Workload Scheduler, lihat Menjalankan GPU di node pool GKE Standard.

Kapan harus menggunakan Dynamic Workload Scheduler

Sebaiknya gunakan Dynamic Workload Scheduler jika workload Anda memenuhi semua kondisi berikut:

  • Anda meminta GPU untuk menjalankan workload.
  • Anda memiliki kapasitas GPU yang direservasi terbatas atau tidak ada dan ingin meningkatkan ketersediaan resource GPU.
  • Workload Anda fleksibel waktunya dan kasus penggunaan Anda dapat menunggu untuk mendapatkan semua kapasitas yang diminta, misalnya saat GKE mengalokasikan resource GPU di luar jam tersibuk.
  • Workload Anda memerlukan beberapa node dan tidak dapat mulai berjalan hingga semua node GPU disediakan dan siap secara bersamaan (misalnya, pelatihan machine learning terdistribusi).

Sebelum memulai

Sebelum memulai, pastikan Anda telah menjalankan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
  • Aktifkan Google Kubernetes Engine API
  • Jika ingin menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan gcloud components update.

Menggunakan node pool dengan Dynamic Workload Scheduler

Bagian ini hanya berlaku untuk cluster Standard.

Anda dapat menggunakan salah satu dari tiga metode berikut untuk menetapkan bahwa Dynamic Workload Scheduler dapat berfungsi dengan kumpulan node tertentu di cluster Anda:

Membuat node pool

Buat node pool dengan Dynamic Workload Scheduler yang diaktifkan menggunakan gcloud CLI:

gcloud container node-pools create NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
     --enable-queued-provisioning \
    --accelerator type=GPU_TYPE,count=AMOUNT,gpu-driver-version=DRIVER_VERSION \
    --machine-type=MACHINE_TYPE \
    --enable-autoscaling  \
    --num-nodes=0   \
    --total-max-nodes TOTAL_MAX_NODES  \
    --location-policy=ANY  \
    --reservation-affinity=none  \
    --no-enable-autorepair

Ganti kode berikut:

  • NODEPOOL_NAME: Nama yang Anda pilih untuk node pool.
  • CLUSTER_NAME: Nama cluster.
  • LOCATION: Region Compute Engine cluster, seperti us-central1.
  • GPU_TYPE: Jenis GPU.
  • AMOUNT: Jumlah GPU yang akan dipasang ke node di node pool.
  • DRIVER_VERSION: versi driver NVIDIA yang akan diinstal. Dapat berupa salah satu dari hal berikut:
    • default: Menginstal versi driver default untuk versi GKE Anda.
    • latest: Instal versi driver terbaru yang tersedia untuk versi GKE Anda. Hanya tersedia untuk node yang menggunakan Container-Optimized OS.
  • TOTAL_MAX_NODES: jumlah maksimum node yang akan diskalakan secara otomatis untuk seluruh node pool.
  • MACHINE_TYPE: Jenis mesin Compute Engine untuk node Anda.

    Praktik terbaik:

    Gunakan jenis mesin yang dioptimalkan untuk akselerator guna meningkatkan performa dan efisiensi untuk workload AI/ML.

Secara opsional, Anda dapat menggunakan flag berikut:

  • --no-enable-autoupgrade: Direkomendasikan. Menonaktifkan upgrade otomatis node. Hanya didukung di cluster GKE yang tidak terdaftar di saluran rilis. Untuk mempelajari lebih lanjut, lihat Menonaktifkan upgrade otomatis node untuk node pool yang sudah ada.
  • --node-locations=COMPUTE_ZONES: Daftar yang dipisahkan koma untuk satu atau beberapa zona tempat GKE membuat node GPU. Zona harus berada di region yang sama dengan cluster. Pilih zona yang memiliki GPU yang tersedia.
  • --enable-gvnic: Flag ini mengaktifkan gVNIC di node pool GPU untuk meningkatkan kecepatan traffic jaringan.

Perintah ini membuat node pool dengan konfigurasi berikut:

  • GKE mengaktifkan penyediaan dalam antrean dan penskalaan otomatis cluster.
  • Node pool awalnya tidak memiliki node.
  • Flag --enable-queued-provisioning mengaktifkan Dynamic Workload Scheduler dan menambahkan taint cloud.google.com/gke-queued ke kumpulan node.
  • Flag --no-enable-autorepair dan --no-enable-autoupgrade menonaktifkan perbaikan dan upgrade node otomatis, yang dapat mengganggu workload yang berjalan di node yang diperbaiki atau diupgrade. Anda hanya dapat menonaktifkan upgrade otomatis node di cluster yang tidak terdaftar di saluran rilis.

Memperbarui node pool yang ada dan mengaktifkan Dynamic Workload Scheduler

Aktifkan Dynamic Workload Scheduler untuk node pool yang sudah ada. Tinjau prasyarat untuk mengonfigurasi node pool dengan benar.

Prasyarat

  • Pastikan Anda membuat node pool dengan flag --reservation-affinity=none. Flag ini diperlukan untuk mengaktifkan Dynamic Workload Scheduler nanti, karena Anda tidak dapat mengubah afinitas reservasi setelah pembuatan node pool.

  • Pastikan Anda mempertahankan minimal satu node pool tanpa penanganan Dynamic Workload Scheduler yang diaktifkan agar cluster berfungsi dengan benar.

  • Pastikan kumpulan node kosong. Anda dapat mengubah ukuran node pool sehingga tidak memiliki node.

  • Pastikan autoscaling diaktifkan dan dikonfigurasi dengan benar.

  • Pastikan perbaikan otomatis dinonaktifkan.

Mengaktifkan Dynamic Workload Scheduler untuk node pool yang ada

Anda dapat mengaktifkan Dynamic Workload Scheduler untuk node pool yang ada menggunakan gcloud CLI:

gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
     --enable-queued-provisioning

Ganti kode berikut:

  • NODEPOOL_NAME: nama node pool yang dipilih.
  • CLUSTER_NAME: nama cluster.
  • LOCATION: region Compute Engine cluster, seperti us-central1.

Perintah update node pool ini menghasilkan perubahan konfigurasi berikut:

  • Flag --enable-queued-provisioning mengaktifkan Dynamic Workload Scheduler dan menambahkan taint cloud.google.com/gke-queued ke kumpulan node.

Secara opsional, Anda juga dapat memperbarui setelan node pool berikut:

Praktik terbaik:

Saat menggunakan Dynamic Workload Scheduler, lakukan hal berikut:

Mengaktifkan penyediaan otomatis node untuk membuat node pool bagi Dynamic Workload Scheduler

Anda dapat menggunakan penyediaan otomatis node untuk mengelola node pool bagi Dynamic Workload Scheduler untuk cluster yang menjalankan versi 1.29.2-gke.1553000 atau yang lebih baru. Saat Anda mengaktifkan penyediaan otomatis node dan mengaktifkan Dynamic Workload Scheduler, GKE akan membuat node pool dengan resource yang diperlukan untuk workload terkait.

Untuk mengaktifkan penyediaan otomatis node, pertimbangkan setelan berikut dan selesaikan langkah-langkah di Mengonfigurasi batas GPU:

Menjalankan workload batch dan AI dengan Dynamic Workload Scheduler

Untuk menjalankan beban kerja batch dengan Dynamic Workload Scheduler, gunakan salah satu konfigurasi berikut:

  • Dynamic Workload Scheduler untuk Tugas dengan Kueue: Anda dapat menggunakan Dynamic Workload Scheduler dengan Kueue untuk mengotomatiskan siklus proses permintaan Dynamic Workload Scheduler. Kueue menerapkan antrean Tugas dan mengamati status Dynamic Workload Scheduler. Kueue memutuskan kapan Job harus menunggu dan kapan harus dimulai, berdasarkan kuota dan hierarki untuk berbagi resource antar-tim secara adil.

  • Dynamic Workload Scheduler untuk Tugas tanpa Kueue: Anda dapat menggunakan Dynamic Workload Scheduler tanpa Kueue saat menggunakan alat atau platform penjadwalan batch internal Anda sendiri. Anda mengamati dan membatalkan permintaan Dynamic Workload Scheduler secara manual.

Praktik terbaik:

Gunakan Kueue untuk menjalankan batch dan workload AI dengan Dynamic Workload Scheduler.

Dynamic Workload Scheduler untuk Tugas dengan Kueue

Bagian berikut menunjukkan cara mengonfigurasi Dynamic Workload Scheduler untuk Tugas dengan Kueue. Anda dapat mengonfigurasi penyiapan node pool umum berikut:

  • Penyiapan kumpulan node Dynamic Workload Scheduler.
  • Reservasi dan penyiapan kumpulan node Dynamic Workload Scheduler.

Bagian ini menggunakan contoh di direktori dws-examples dari repositori ai-on-gke. Kami telah memublikasikan contoh di direktori dws-examples berdasarkan lisensi Apache2.

Anda harus memiliki izin administrator untuk menginstal Kueue. Untuk mendapatkannya, pastikan Anda diberi peran IAM roles/container.admin. Untuk mengetahui peran IAM GKE lebih lanjut, lihat Panduan membuat kebijakan izin IAM.

Menyiapkan lingkungan Anda

  1. Jalankan perintah berikut di Cloud Shell:

    git clone https://github.com/GoogleCloudPlatform/ai-on-gke
    cd ai-on-gke/tutorials-and-examples/workflow-orchestration/dws-examples
    
  2. Instal versi Kueue terbaru di cluster Anda:

    VERSION=v0.7.0
    kubectl apply --server-side -f https://github.com/kubernetes-sigs/kueue/releases/download/$VERSION/manifests.yaml
    

Jika Anda menggunakan Kueue dalam versi yang lebih lama dari 0.7.0, ubah konfigurasi gate fitur Kueue dengan menetapkan gate fitur ProvisioningACC ke true. Lihat Gate fitur Kueue untuk mengetahui penjelasan yang lebih mendetail dan nilai gate default. Untuk mempelajari lebih lanjut penginstalan Kueue, lihat Penginstalan.

Membuat resource Kueue untuk penyiapan khusus kumpulan node Dynamic Workload Scheduler

Dengan manifes berikut, Anda membuat antrean tingkat cluster bernama dws-cluster-queue dan namespace LocalQueue bernama dws-local-queue. Tugas yang merujuk ke antrean dws-cluster-queue di namespace ini menggunakan Dynamic Workload Scheduler untuk mendapatkan resource GPU.

apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
  name: dws-prov
spec:
  controllerName: kueue.x-k8s.io/provisioning-request
  parameters:
    apiGroup: kueue.x-k8s.io
    kind: ProvisioningRequestConfig
    name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
  name: dws-config
spec:
  provisioningClassName: queued-provisioning.gke.io
  managedResources:
  - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: "dws-cluster-queue"
spec:
  namespaceSelector: {} 
  resourceGroups:
  - coveredResources: ["cpu", "memory", "nvidia.com/gpu", "ephemeral-storage"]
    flavors:
    - name: "default-flavor"
      resources:
      - name: "cpu"
        nominalQuota: 10000  # Infinite quota.
      - name: "memory"
        nominalQuota: 10000Gi # Infinite quota.
      - name: "nvidia.com/gpu"
        nominalQuota: 10000  # Infinite quota.
      - name: "ephemeral-storage"
        nominalQuota: 10000Ti # Infinite quota.
  admissionChecks:
  - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  namespace: "default"
  name: "dws-local-queue"
spec:
  clusterQueue: "dws-cluster-queue"
---

Antrean cluster ini memiliki batas kuota yang tinggi dan hanya integrasi Dynamic Workload Scheduler yang diaktifkan. Untuk mempelajari Kueue API dan cara menyiapkan batas lebih lanjut, lihat Konsep Kueue.

Men-deploy LocalQueue:

kubectl create -f ./dws-queues.yaml

Outputnya mirip dengan hal berikut ini:

resourceflavor.kueue.x-k8s.io/default-flavor created
admissioncheck.kueue.x-k8s.io/dws-prov created
provisioningrequestconfig.kueue.x-k8s.io/dws-config created
clusterqueue.kueue.x-k8s.io/dws-cluster-queue created
localqueue.kueue.x-k8s.io/dws-local-queue created

Jika ingin menjalankan Tugas yang menggunakan Dynamic Workload Scheduler di namespace lain, Anda dapat membuat LocalQueues tambahan menggunakan template sebelumnya.

Menjalankan Tugas

Dalam manifes berikut, contoh Tugas menggunakan Dynamic Workload Scheduler:

apiVersion: batch/v1
kind: Job
metadata:
  name: sample-job
  namespace: default
  labels:
    kueue.x-k8s.io/queue-name: dws-local-queue
  annotations:
    provreq.kueue.x-k8s.io/maxRunDurationSeconds: "600"
spec:
  parallelism: 1
  completions: 1
  suspend: true
  template:
    spec:
      nodeSelector:
        cloud.google.com/gke-nodepool: NODEPOOL_NAME
      tolerations:
      - key: "nvidia.com/gpu"
        operator: "Exists"
        effect: "NoSchedule"
      containers:
      - name: dummy-job
        image: gcr.io/k8s-staging-perf-tests/sleep:v0.0.3
        args: ["120s"]
        resources:
          requests:
            cpu: "100m"
            memory: "100Mi"
            nvidia.com/gpu: 1
          limits:
            cpu: "100m"
            memory: "100Mi"
            nvidia.com/gpu: 1
      restartPolicy: Never

Manifes ini mencakup kolom berikut yang relevan untuk konfigurasi Dynamic Workload Scheduler:

  • Label kueue.x-k8s.io/queue-name: dws-local-queue memberi tahu GKE bahwa Kueue bertanggung jawab untuk mengatur Tugas tersebut. Label ini juga menentukan antrean tempat Tugas diantrekan.
  • Flag suspend: true memberi tahu GKE untuk membuat resource Tugas, tetapi belum menjadwalkan Pod. Kueue mengubah tanda tersebut menjadi false saat node siap untuk eksekusi Tugas.
  • nodeSelector memberi tahu GKE untuk menjadwalkan Tugas hanya di kumpulan node yang ditentukan. Nilainya harus cocok dengan NODEPOOL_NAME, nama node pool dengan penyediaan antrean yang diaktifkan.
  1. Jalankan Tugas Anda:

    kubectl create -f ./job.yaml
    

    Outputnya mirip dengan hal berikut ini:

    job.batch/sample-job created
    
  2. Periksa status Tugas Anda:

    kubectl describe job sample-job
    

    Outputnya mirip dengan hal berikut ini:

    Events:
      Type    Reason            Age    From                        Message
      ----    ------            ----   ----                        -------
      Normal  Suspended         5m17s  job-controller              Job suspended
      Normal  CreatedWorkload   5m17s  batch/job-kueue-controller  Created Workload: default/job-sample-job-7f173
      Normal  Started           3m27s  batch/job-kueue-controller  Admitted by clusterQueue dws-cluster-queue
      Normal  SuccessfulCreate  3m27s  job-controller              Created pod: sample-job-9qsfd
      Normal  Resumed           3m27s  job-controller              Job resumed
      Normal  Completed         12s    job-controller              Job completed
    

Dynamic Workload Scheduler dengan integrasi Kueue juga mendukung jenis workload lain yang tersedia di ekosistem open source, seperti berikut:

  • RayJob
  • JobSet v0.5.2 atau yang lebih baru
  • Kubeflow MPIJob, TFJob, PyTorchJob.
  • Pod Kubernetes yang sering digunakan oleh orkestrator alur kerja
  • Cluster mini Flux

Untuk mempelajari dukungan ini lebih lanjut, lihat Pengguna batch Kueue.

Membuat resource Kueue untuk penyiapan node pool Dynamic Workload Scheduler dan Reservasi

Dengan manifes berikut, Anda membuat dua ResourceFlavors yang terikat dengan dua node pool yang berbeda: reservation-nodepool dan dws-nodepool. Nama node pool ini hanya contoh nama. Ubah nama ini sesuai dengan konfigurasi node pool Anda. Selain itu, dengan konfigurasi ClusterQueue, Tugas yang masuk akan mencoba menggunakan reservation-nodepool, dan jika tidak ada kapasitas, Tugas ini akan menggunakan Dynamic Workload Scheduler untuk mendapatkan resource GPU.

apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: "reservation"
spec:
  nodeLabels:
    cloud.google.com/gke-nodepool: "reservation-nodepool" # placeholder value
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: "dws"
spec:
  nodeLabels:
    cloud.google.com/gke-nodepool: "dws-nodepool" # placeholder value
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: "cluster-queue"
spec:
  namespaceSelector: {} # match all.
  resourceGroups:
  - coveredResources: ["cpu", "memory", "nvidia.com/gpu"]
    flavors:
    - name: "reservation" # first we try reservation
      resources:
      - name: "cpu"
        nominalQuota: 9
      - name: "memory"
        nominalQuota: 36Gi
      - name: "nvidia.com/gpu"
        nominalQuota: 9
    - name: "dws"         # if reservation is saturated we try dws
      resources:
      - name: "cpu"
        nominalQuota: 10000   # Infinite quota.
      - name: "memory"
        nominalQuota: 10000Gi # Infinite quota.
      - name: "nvidia.com/gpu"
        nominalQuota: 10000   # Infinite quota.
  admissionChecksStrategy:
    admissionChecks:
      - name: "dws-prov"
        onFlavors: [dws]
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  namespace: "default"
  name: "user-queue"
spec:
  clusterQueue: "cluster-queue"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
  name: dws-prov
spec:
  controllerName: kueue.x-k8s.io/provisioning-request
  parameters:
    apiGroup: kueue.x-k8s.io
    kind: ProvisioningRequestConfig
    name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
  name: dws-config
spec:
  provisioningClassName: queued-provisioning.gke.io
  managedResources:
  - nvidia.com/gpu

Antrean cluster ini memiliki batas kuota yang tinggi dan hanya integrasi Dynamic Workload Scheduler yang diaktifkan. Untuk mempelajari Kueue API dan cara menyiapkan batas lebih lanjut, lihat Konsep Kueue.

Deploy manifes menggunakan perintah berikut:

kubectl create -f ./dws_and_reservation.yaml

Outputnya mirip dengan hal berikut ini:

resourceflavor.kueue.x-k8s.io/reservation created
resourceflavor.kueue.x-k8s.io/dws created
clusterqueue.kueue.x-k8s.io/cluster-queue created
localqueue.kueue.x-k8s.io/user-queue created
admissioncheck.kueue.x-k8s.io/dws-prov created
provisioningrequestconfig.kueue.x-k8s.io/dws-config created

Menjalankan Tugas

Berbeda dengan penyiapan sebelumnya, manifes ini tidak menyertakan kolom nodeSelector, karena diisi oleh Kueue, bergantung pada kapasitas kosong di ClusterQueue.

apiVersion: batch/v1
kind: Job
metadata:
  generateName: sample-job-
  namespace: default
  labels:
    kueue.x-k8s.io/queue-name: user-queue
  annotations:
    provreq.kueue.x-k8s.io/maxRunDurationSeconds: "600"
spec:
  parallelism: 1
  completions: 1
  suspend: true
  template:
    spec:
      tolerations:
      - key: "nvidia.com/gpu"
        operator: "Exists"
        effect: "NoSchedule"
      containers:
      - name: dummy-job
        image: gcr.io/k8s-staging-perf-tests/sleep:v0.0.3
        args: ["120s"]
        resources:
          requests:
            cpu: "100m"
            memory: "100Mi"
            nvidia.com/gpu: 1
          limits:
            cpu: "100m"
            memory: "100Mi"
            nvidia.com/gpu: 1
      restartPolicy: Never
  1. Jalankan Tugas Anda:

    kubectl create -f ./job-without-node-selector.yaml
    

    Outputnya mirip dengan hal berikut ini:

    job.batch/sample-job-v8xwm created
    

Untuk mengetahui node pool yang digunakan Tugas, Anda perlu mengetahui ResourceFlavor yang digunakan Tugas.

Pemecahan masalah

Untuk mempelajari pemecahan masalah Kueue lebih lanjut, lihat Memecahkan Masalah Permintaan Penyediaan di Kueue

Dynamic Workload Scheduler untuk Tugas tanpa Kueue

Menentukan objek ProvisioningRequest

Buat permintaan melalui ProvisioningRequest API untuk setiap Tugas. Dynamic Workload Scheduler tidak memulai Pod, tetapi hanya menyediakan node.

  1. Buat manifes provisioning-request.yaml berikut:

    Standard

    apiVersion: v1
    kind: PodTemplate
    metadata:
      name: POD_TEMPLATE_NAME
      namespace: NAMESPACE_NAME
      labels:
        cloud.google.com/apply-warden-policies: "true"
    template:
      spec:
        nodeSelector:
          cloud.google.com/gke-nodepool: NODEPOOL_NAME
        tolerations:
          - key: "nvidia.com/gpu"
            operator: "Exists"
            effect: "NoSchedule"
        containers:
          - name: pi
            image: perl
            command: ["/bin/sh"]
            resources:
              limits:
                cpu: "700m"
                nvidia.com/gpu: 1
              requests:
                cpu: "700m"
                nvidia.com/gpu: 1
        restartPolicy: Never
    ---
    apiVersion: autoscaling.x-k8s.io/API_VERSION
    kind: ProvisioningRequest
    metadata:
      name: PROVISIONING_REQUEST_NAME
      namespace: NAMESPACE_NAME
    spec:
      provisioningClassName: queued-provisioning.gke.io
      parameters:
        maxRunDurationSeconds: "MAX_RUN_DURATION_SECONDS"
      podSets:
      - count: COUNT
        podTemplateRef:
          name: POD_TEMPLATE_NAME
    

    Ganti kode berikut:

    • API_VERSION: Versi API, baik v1 maupun v1beta1. Untuk GKE versi 1.31.1-gke.1678000 dan yang lebih baru, sebaiknya gunakan v1 untuk stabilitas dan akses ke fitur terbaru.
    • NAMESPACE_NAME: Nama namespace Kubernetes Anda. Namespace harus sama dengan namespace Pod.
    • PROVISIONING_REQUEST_NAME: Nama ProvisioningRequest. Anda akan melihat nama ini dalam anotasi Pod.
    • MAX_RUN_DURATION_SECONDS: Secara opsional, runtime maksimum node dalam detik, hingga default tujuh hari. Untuk mempelajari lebih lanjut, lihat Cara kerja Dynamic Workload Scheduler. Anda tidak dapat mengubah nilai ini setelah pembuatan permintaan. Kolom ini tersedia di GKE versi 1.28.5-gke.1355000 atau yang lebih baru.
    • COUNT: Jumlah Pod yang diminta. Node dijadwalkan secara atomik di satu zona.
    • POD_TEMPLATE_NAME: Nama PodTemplate.
    • NODEPOOL_NAME: Nama yang Anda pilih untuk node pool. Hapus jika Anda ingin menggunakan node pool yang disediakan secara otomatis.

    GKE dapat menerapkan validasi dan mutasi ke Pod selama pembuatannya. Label cloud.google.com/apply-warden-policies memungkinkan GKE menerapkan validasi dan mutasi yang sama ke objek PodTemplate. Label ini diperlukan agar GKE dapat menghitung persyaratan resource node untuk Pod Anda.

    Penyediaan otomatis node

    apiVersion: v1
    kind: PodTemplate
    metadata:
      name: POD_TEMPLATE_NAME
      namespace: NAMESPACE_NAME
      labels:
        cloud.google.com/apply-warden-policies: "true"
    template:
      spec:
        nodeSelector:
          cloud.google.com/gke-accelerator: GPU_TYPE
        tolerations:
          - key: "nvidia.com/gpu"
            operator: "Exists"
            effect: "NoSchedule"
        containers:
          - name: pi
            image: perl
            command: ["/bin/sh"]
            resources:
              limits:
                cpu: "700m"
                nvidia.com/gpu: 1
              requests:
                cpu: "700m"
                nvidia.com/gpu: 1
        restartPolicy: Never
    ---
    apiVersion: autoscaling.x-k8s.io/API_VERSION
    kind: ProvisioningRequest
    metadata:
      name: PROVISIONING_REQUEST_NAME
      namespace: NAMESPACE_NAME
    spec:
      provisioningClassName: queued-provisioning.gke.io
      parameters:
        maxRunDurationSeconds: "MAX_RUN_DURATION_SECONDS"
      podSets:
      - count: COUNT
        podTemplateRef:
          name: POD_TEMPLATE_NAME
    

    Ganti kode berikut:

    • API_VERSION: Versi API, baik v1 maupun v1beta1. Untuk GKE versi 1.31.1-gke.1678000 dan yang lebih baru, sebaiknya gunakan v1 untuk stabilitas dan akses ke fitur terbaru.
    • NAMESPACE_NAME: Nama namespace Kubernetes Anda. Namespace harus sama dengan namespace Pod.
    • PROVISIONING_REQUEST_NAME: Nama ProvisioningRequest. Anda akan melihat nama ini dalam anotasi Pod.
    • MAX_RUN_DURATION_SECONDS: Secara opsional, runtime maksimum node dalam detik, hingga default tujuh hari. Untuk mempelajari lebih lanjut, lihat Cara kerja Dynamic Workload Scheduler. Anda tidak dapat mengubah nilai ini setelah pembuatan permintaan. Kolom ini tersedia di GKE versi 1.28.5-gke.1355000 atau yang lebih baru.
    • COUNT: Jumlah Pod yang diminta. Node dijadwalkan secara atomik di satu zona.
    • POD_TEMPLATE_NAME: Nama PodTemplate.
    • GPU_TYPE: jenis hardware GPU.

    GKE dapat menerapkan validasi dan mutasi ke Pod selama pembuatannya. Label cloud.google.com/apply-warden-policies memungkinkan GKE menerapkan validasi dan mutasi yang sama ke objek PodTemplate. Label ini diperlukan agar GKE dapat menghitung persyaratan resource node untuk Pod Anda.

  2. Terapkan manifes:

    kubectl apply -f provisioning-request.yaml
    

Mengonfigurasi Pod

Bagian ini menggunakan Kubernetes Jobs untuk mengonfigurasi Pod. Namun, Anda juga dapat menggunakan Kubernetes JobSet atau framework lainnya seperti Kubeflow, Ray, atau pengontrol kustom. Dalam spec Job, tautkan Pod ke ProvisioningRequest menggunakan anotasi berikut:

apiVersion: batch/v1
kind: Job
spec:
  template:
    metadata:
      annotations:
        autoscaling.x-k8s.io/consume-provisioning-request: PROVISIONING_REQUEST_NAME
        autoscaling.x-k8s.io/provisioning-class-name: "queued-provisioning.gke.io"
    spec:
      ...

Sebelum GKE versi 1.30.3-gke.1854000, Anda harus menggunakan anotasi lama berikut:

      annotations:
        cluster-autoscaler.kubernetes.io/consume-provisioning-request: PROVISIONING_REQUEST_NAME
        cluster-autoscaler.kubernetes.io/provisioning-class-name: "queued-provisioning.gke.io"

Perhatikan bahwa mulai dari GKE versi 1.31.1-gke.1678000, anotasi cluster-autoscaler.kubernetes.io/consume-provisioning-request dan cluster-autoscaler.kubernetes.io/provisioning-class-name tidak digunakan lagi.

Kunci anotasi Pod consume-provisioning-request menentukan ProvisioningRequest yang akan digunakan. GKE menggunakan anotasi consume-provisioning-request dan provisioning-class-name untuk melakukan hal berikut:

  • Untuk menjadwalkan Pod hanya di node yang disediakan oleh Dynamic Workload Scheduler.
  • Untuk menghindari penghitungan ganda permintaan resource antara Pod dan Dynamic Workload Scheduler di autoscaler cluster.
  • Untuk memasukkan anotasi safe-to-evict: false, agar autoscaler cluster tidak memindahkan Pod di antara node dan mengganggu komputasi batch. Anda dapat mengubah perilaku ini dengan menentukan safe-to-evict: true dalam anotasi Pod.

Mengamati status Dynamic Workload Scheduler

Status Dynamic Workload Scheduler menentukan apakah Pod dapat dijadwalkan atau tidak. Anda dapat menggunakan smartwatch Kubernetes untuk mengamati perubahan secara efisien atau alat lain yang sudah Anda gunakan untuk melacak status objek Kubernetes. Tabel berikut menjelaskan kemungkinan status Dynamic Workload Scheduler dan setiap kemungkinan hasilnya:

Status Dynamic Workload Scheduler Deskripsi Kemungkinan hasil
Tertunda Permintaan belum dilihat dan diproses. Setelah diproses, permintaan akan bertransisi ke status Accepted atau Failed.
Accepted=true Permintaan diterima dan menunggu resource tersedia. Permintaan harus bertransisi ke status Provisioned, jika resource ditemukan dan node disediakan, atau ke status Failed jika tidak memungkinkan.
Provisioned=true Node sudah siap. Anda memiliki waktu 10 menit untuk memulai Pod guna menggunakan resource yang disediakan. Setelah waktu ini, autoscaler cluster menganggap node tidak diperlukan dan menghapusnya.
Failed=true Node tidak dapat disediakan karena error. Failed=true adalah status terminal. Pecahkan masalah kondisi berdasarkan informasi di kolom Reason dan Message kondisi. Buat dan coba lagi permintaan Dynamic Workload Scheduler baru.
Provisioned=false Node belum disediakan.

Jika Reason=NotProvisioned, ini adalah status sementara sebelum semua resource tersedia.

Jika Reason=QuotaExceeded, pecahkan masalah kondisi berdasarkan alasan ini dan informasi di kolom Message kondisi. Anda mungkin perlu meminta lebih banyak kuota. Untuk mengetahui detail selengkapnya, lihat bagian Memeriksa apakah Dynamic Workload Scheduler dibatasi oleh kuota. Reason ini hanya tersedia dengan GKE versi 1.29.2-gke.1181000 atau yang lebih baru.

Jika Reason=ResourcePoolExhausted, dan Message berisi Expected time is indefinite, pilih zona atau region yang berbeda, atau sesuaikan resource yang diminta.

Memulai Pod

Saat permintaan Dynamic Workload Scheduler mencapai status Provisioned=true, Anda dapat menjalankan Tugas untuk memulai Pod. Hal ini menghindari proliferasi Pod yang tidak dapat dijadwalkan untuk permintaan yang tertunda atau gagal, yang dapat memengaruhi performa kube-scheduler dan autoscaler cluster.

Atau, jika tidak masalah memiliki Pod yang tidak dapat dijadwalkan, Anda dapat membuat Pod secara paralel dengan Dynamic Workload Scheduler.

Membatalkan permintaan Dynamic Workload Scheduler

Untuk membatalkan permintaan sebelum disediakan, Anda dapat menghapus ProvisioningRequest:

kubectl delete provreq PROVISIONING_REQUEST_NAME -n NAMESPACE

Dalam sebagian besar kasus, menghapus ProvisioningRequest akan menghentikan pembuatan node. Namun, bergantung pada waktu, misalnya jika node sudah disediakan, node mungkin masih akan dibuat. Dalam hal ini, autoscaler cluster akan menghapus node setelah 10 menit jika tidak ada Pod yang dibuat.

Cara kerja Dynamic Workload Scheduler

Dengan ProvisioningRequest API, Dynamic Workload Scheduler melakukan hal berikut:

  1. Anda memberi tahu GKE bahwa workload Anda dapat menunggu, selama waktu yang tidak ditentukan, hingga semua node yang diperlukan siap digunakan secara bersamaan.
  2. Autoscaler cluster menerima permintaan Anda dan menghitung jumlah node yang diperlukan, memperlakukannya sebagai satu unit.
  3. Permintaan menunggu hingga semua resource yang diperlukan tersedia di satu zona. Untuk cluster yang menjalankan 1.29.1-gke.1708000 dan yang lebih baru, zona ini dipilih menggunakan informasi tentang kapasitas yang tersedia untuk memastikan waktu tunggu yang lebih rendah. Untuk cluster yang menjalankan versi sebelumnya, zona dipilih tanpa informasi ini, yang dapat menyebabkan antrean di zona dengan waktu tunggu yang jauh lebih lama.
  4. Autoscaler cluster menyediakan node yang diperlukan jika tersedia, sekaligus.
  5. Semua Pod beban kerja dapat berjalan bersama di node yang baru disediakan.
  6. Node yang disediakan dibatasi hingga tujuh hari runtime, atau lebih awal jika Anda menetapkan parameter maxRunDurationSeconds untuk menunjukkan bahwa workload memerlukan lebih sedikit waktu untuk dijalankan. Untuk mempelajari lebih lanjut, lihat Membatasi runtime VM. Kemampuan ini tersedia dengan GKE versi 1.28.5-gke.1355000 atau yang lebih baru. Setelah waktu ini, node dan Pod yang berjalan di node tersebut akan didahului. Jika Pod selesai lebih cepat dan node tidak digunakan, autoscaler cluster akan menghapusnya sesuai dengan profil penskalaan otomatis.
  7. Node tidak digunakan kembali di antara Dynamic Workload Scheduler. Setiap ProvisioningRequest memerintahkan pembuatan node baru dengan runtime tujuh hari baru.

GKE mengukur runtime di tingkat node. Waktu yang tersedia untuk menjalankan Pod mungkin sedikit lebih kecil karena keterlambatan selama startup. Percobaan ulang Pod berbagi runtime ini, yang berarti ada lebih sedikit waktu yang tersedia untuk Pod setelah percobaan ulang. GKE menghitung runtime untuk setiap permintaan Dynamic Workload Scheduler secara terpisah.

Kuota

Semua VM yang disediakan oleh permintaan Dynamic Workload Scheduler menggunakan kuota preemptible.

Jumlah ProvisioningRequests yang berada dalam status Accepted dibatasi oleh kuota khusus. Anda mengonfigurasi kuota untuk setiap project, satu konfigurasi kuota per region.

Memeriksa kuota di konsol Google Cloud

Untuk memeriksa nama batas kuota dan penggunaan saat ini di Konsol Google Cloud, ikuti langkah-langkah berikut:

  1. Buka halaman Kuota di Konsol Google Cloud:

    Buka Kuota

  2. Di kotak Filter , pilih properti Metric, masukkan active_resize_requests, lalu tekan Enter.

Nilai defaultnya adalah 100. Untuk meningkatkan kuota, ikuti langkah-langkah yang tercantum dalam Panduan meminta batas kuota yang lebih tinggi.

Memeriksa apakah Dynamic Workload Scheduler dibatasi oleh kuota

Jika permintaan Dynamic Workload Scheduler Anda memerlukan waktu lebih lama dari yang diharapkan untuk dipenuhi, pastikan permintaan tersebut tidak dibatasi oleh kuota. Anda mungkin perlu meminta lebih banyak kuota.

Untuk cluster yang menjalankan versi 1.29.2-gke.1181000 atau yang lebih baru, periksa apakah batasan kuota tertentu mencegah permintaan Anda terpenuhi:

kubectl describe provreq PROVISIONING_REQUEST_NAME \
    --namespace NAMESPACE

Outputnya mirip dengan yang berikut ini:

…
Last Transition Time:  2024-01-03T13:56:08Z
    Message:               Quota 'NVIDIA_P4_GPUS' exceeded. Limit: 1.0 in region europe-west4.
    Observed Generation:   1
    Reason:                QuotaExceeded
    Status:                False
    Type:                  Provisioned
…

Dalam contoh ini, GKE tidak dapat men-deploy node karena tidak ada kuota yang memadai di region europe-west4.

Mengelola gangguan pada workload menggunakan Dynamic Workload Scheduler

Workload yang memerlukan ketersediaan semua node, atau sebagian besar node, dalam node pool sensitif terhadap pengusiran. Perbaikan atau upgrade otomatis node yang disediakan menggunakan ProvisioningRequest API tidak didukung karena operasi ini mengeluarkan semua beban kerja yang berjalan di node tersebut dan membuat beban kerja tidak dapat dijadwalkan.

Praktik terbaik untuk meminimalkan gangguan beban kerja

Untuk meminimalkan gangguan pada workload yang sedang berjalan menggunakan Dynamic Workload Scheduler, lakukan tugas berikut:

  • Bergantung pada pendaftaran saluran rilis cluster Anda, gunakan praktik terbaik berikut untuk mencegah upgrade otomatis node mengganggu workload Anda:
  • Nonaktifkan perbaikan otomatis node.
  • Gunakan masa pemeliharaan dan pengecualian untuk meminimalkan gangguan pada workload yang sedang berjalan, sekaligus memastikan bahwa GKE masih memiliki waktu untuk melakukan pemeliharaan otomatis. Pastikan untuk menentukan waktu tersebut saat tidak ada beban kerja yang berjalan.
  • Untuk memastikan node pool Anda tetap yang terbaru, upgrade node pool secara manual saat tidak ada permintaan Dynamic Workload Scheduler yang aktif dan node pool kosong.

Batasan

  • Anti-afinitas antar-pod tidak didukung. Autoscaler cluster tidak mempertimbangkan aturan anti-afinitas antar-pod selama penyediaan node yang dapat menyebabkan workload yang tidak dapat dijadwalkan. Hal ini dapat terjadi jika node untuk dua atau beberapa objek Dynamic Workload Scheduler disediakan di kumpulan node yang sama.
  • Hanya node GPU yang didukung.
  • Pemesanan tidak didukung dengan Dynamic Workload Scheduler. Anda harus menentukan--reservation-affinity=none saat membuat node pool. Dynamic Workload Scheduler hanya memerlukan dan mendukung kebijakan lokasi ANY untuk penskalaan otomatis cluster.
  • Satu permintaan Dynamic Workload Scheduler dapat membuat hingga 1.000 VM, yang merupakan jumlah maksimum node per zona untuk satu node pool.
  • GKE menggunakan kuota ACTIVE_RESIZE_REQUESTS Compute Engine untuk mengontrol jumlah permintaan Dynamic Workload Scheduler yang tertunda dalam antrean. Secara default, kuota ini memiliki batas 100 di tingkat project Google Cloud. Jika Anda mencoba membuat permintaan Dynamic Workload Scheduler yang lebih besar dari kuota ini, permintaan baru akan gagal.
  • Node pool yang menggunakan Dynamic Workload Scheduler sensitif terhadap gangguan karena node disediakan secara bersamaan. Untuk mempelajari lebih lanjut, lihat mengonfigurasi setelan gangguan untuk node pool dengan workload menggunakan Dynamic Workload Scheduler.
  • Anda mungkin melihat VM tambahan berumur pendek yang tercantum di konsol Google Cloud. Perilaku ini dimaksudkan karena Compute Engine dapat membuat dan segera menghapus VM hingga kapasitas untuk menyediakan semua mesin yang diperlukan tersedia.
  • Integrasi Dynamic Workload Scheduler hanya mendukung satu PodSet. Jika Anda ingin menggabungkan template Pod yang berbeda, gunakan template dengan resource yang paling banyak diminta. Menggabungkan berbagai jenis mesin, seperti VM dengan jenis GPU yang berbeda, tidak didukung.

Langkah selanjutnya