Men-deploy GPU untuk workload batch dengan ProvisioningRequest

Men-deploy GPU untuk workload batch dengan ProvisioningRequest

Halaman ini menunjukkan cara mengoptimalkan kemampuan GPU yang dapat diperoleh melalui ProvisioningRequest API. Kami merekomendasikan fitur ini untuk workload batch berskala besar yang dapat dijalankan di luar jam sibuk dengan kondisi pengelolaan kapasitas GPU yang ditetapkan. Workload ini mungkin berupa pelatihan model deep learning atau simulasi yang membutuhkan GPU dalam jumlah besar dengan model penyediaan atomik, yang berarti semua resource dibuat secara bersamaan.

Untuk menjalankan beban kerja GPU di Google Kubernetes Engine (GKE) tanpa ProvisioningRequest API, lihat Menjalankan GPU di node pool Standar GKE.

Kapan harus menggunakan ProvisioningRequest

Sebaiknya gunakan ProvisioningRequest jika beban kerja Anda memenuhi semua kondisi berikut:

  • Anda meminta GPU untuk menjalankan beban kerja Anda.
  • Kapasitas GPU Anda yang dicadangkan terbatas atau tidak ada dan Anda ingin meningkatkan kemampuan resource GPU.
  • Workload Anda fleksibel dari waktu ke waktu dan kasus penggunaan Anda mampu 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 sampai semua node GPU disediakan dan siap pada saat yang sama (misalnya, pelatihan machine learning terdistribusi).

Untuk mempelajari detail ProvisioningRequest lebih lanjut, lihat Cara kerja ProvisioningRequest.

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 initialize gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan gcloud components update.

Membuat node pool

Buat kumpulan node dengan ProvisioningRequest yang diaktifkan menggunakan gcloud CLI:

gcloud beta 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 \
    --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 kumpulan node.
  • CLUSTER_NAME: Nama cluster.
  • LOCATION: Region Compute Engine cluster, seperti us-central1.
  • GPU_TYPE: Jenis GPU.
  • AMOUNT: Jumlah GPU yang harus dipasang ke node di kumpulan node.
  • 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 kumpulan node.

Secara opsional, Anda dapat menggunakan tanda berikut:

  • --no-enable-autoupgrade: Direkomendasikan. Menonaktifkan upgrade otomatis node. Hanya didukung di cluster GKE yang saat ini tidak terdaftar di saluran rilis. Untuk mempelajari lebih lanjut, lihat Menonaktifkan upgrade otomatis node untuk kumpulan node yang 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.
  • --machine-type=MACHINE_TYPE: Jenis mesin Compute Engine untuk node. Wajib jika GPU_TYPE adalah tesla-a100 atau nvidia-a100-80gb, yang hanya dapat menggunakan jenis mesin A2, atau jika GPU_TYPE adalah nvidia-l4, yang hanya dapat menggunakan jenis mesin G2. Untuk semua GPU lainnya, flag ini bersifat opsional.
  • --enable-gvnic: Flag ini memungkinkan gVNIC pada kumpulan node GPU untuk meningkatkan kecepatan traffic jaringan.

Perintah ini membuat kumpulan node dengan konfigurasi berikut:

  • GKE memungkinkan penyediaan dalam antrean dan penskalaan otomatis cluster.
  • Kumpulan node awalnya memiliki nol node.
  • Flag --enable-queued-provisioning mengaktifkan ProvisioningRequests dan menambahkan taint cloud.google.com/gke-queued ke kumpulan node.
  • Flag --no-enable-autorepair dan --no-enable-autoupgrade menonaktifkan perbaikan dan upgrade otomatis node, yang dapat mengganggu beban kerja yang berjalan pada node yang diperbaiki atau diupgrade. Anda hanya dapat menonaktifkan upgrade otomatis node pada cluster yang tidak terdaftar di saluran rilis.

Memperbarui kumpulan node yang ada dan mengaktifkan ProvisioningRequests

Mengaktifkan ProvisioningRequests untuk kumpulan node yang ada, sehingga memastikan Anda meninjau prasyarat untuk mengonfigurasi kumpulan node dengan benar.

Prasyarat

  • Pastikan Anda membuat kumpulan node dengan flag --reservation-affinity=none. Tanda ini diperlukan untuk mengaktifkan ProvisioningRequests di lain waktu, karena Anda tidak dapat mengubah afinitas reservasi setelah pembuatan kumpulan node.

  • Pastikan Anda mempertahankan minimal satu kumpulan node tanpa mengaktifkan penanganan ProvisioningRequest agar cluster berfungsi dengan benar.

  • Pastikan kumpulan node kosong. Anda dapat mengubah ukuran kumpulan node agar memiliki nol node.

  • Pastikan penskalaan otomatis diaktifkan dan dikonfigurasi dengan benar.

  • Pastikan perbaikan otomatis dinonaktifkan.

Aktifkan ProvisioningRequests untuk kumpulan node yang ada

Anda dapat mengaktifkan ProvisioningRequest untuk kumpulan node yang ada menggunakan gcloud CLI:

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

Ganti kode berikut:

  • NODEPOOL_NAME: nama kumpulan node 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 ProvisioningRequests dan menambahkan taint cloud.google.com/gke-queued ke kumpulan node.

Anda juga dapat memperbarui setelan kumpulan node berikut:

  • Nonaktifkan upgrade otomatis node: Sebaiknya nonaktifkan upgrade otomatis node karena upgrade kumpulan node tidak didukung saat menggunakan ProvisioningRequests. Untuk menonaktifkan upgrade otomatis node, pastikan cluster GKE Anda tidak terdaftar di saluran rilis.
  • Aktifkan gVNIC di kumpulan node GPU: NIC Virtual Google (gVNIC) meningkatkan kecepatan traffic jaringan untuk node GPU.

Menjalankan beban kerja batch dengan ProvisioningRequest

Untuk menggunakan ProvisioningRequest, sebaiknya gunakan Kueue. Kueue menerapkan antrean pekerjaan, memutuskan kapan Pekerjaan harus menunggu dan kapan pekerjaan tersebut harus dimulai, berdasarkan kuota dan hierarki untuk berbagi resource secara adil di antara tim. Hal ini menyederhanakan penyiapan yang diperlukan untuk menggunakan VM dalam antrean.

Anda dapat menggunakan ProvisioningRequest tanpa Kueue saat menggunakan platform atau alat penjadwalan batch internal Anda sendiri. Untuk mengonfigurasi Permintaan Penyediaan untuk Pekerjaan tanpa Kueue, lihat Permintaan Penyediaan untuk Pekerjaan tanpa Kueue.

Penyediaan Permintaan untuk Pekerjaan dengan Kueue

Bagian berikut menunjukkan cara mengonfigurasi ProvisioningRequests untuk Lowongan dengan Kueue. Bagian ini menggunakan contoh di repositori dws-examples. Kami telah memublikasikan contoh di repositori dws-examples dengan lisensi Apache2.

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 Kueue di cluster Anda dengan konfigurasi yang diperlukan untuk mengaktifkan integrasi Permintaan Penyediaan:

    kubectl apply --server-side -f ./kueue-manifests.yaml

Untuk mempelajari penginstalan Kueue lebih lanjut, lihat Penginstalan.

Membuat sumber daya Kueue

Dengan manifes berikut, Anda akan membuat antrean level cluster bernama dws-cluster-queue dan namespace LocalQueue bernama dws-local-queue. Tugas yang merujuk ke antrean dws-cluster-queue dalam namespace ini menggunakan ProvisioningRequests 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"]
    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.
  admissionChecks:
  - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  namespace: "default"
  name: "dws-local-queue"
spec:
  clusterQueue: "dws-cluster-queue"
---

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 ProvisioningRequests di namespace lain, Anda dapat membuat LocalQueue tambahan menggunakan template sebelumnya.

Menjalankan Tugas Anda

Dalam manifes berikut, contoh Tugas menggunakan ProvisioningRequest:

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: dws-nodepool
      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 ProvisioningRequest:

  • Label kueue.x-k8s.io/queue-name: dws-local-queue memberi tahu GKE bahwa Kueue bertanggung jawab untuk mengorkestrasi 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 flag tersebut menjadi false saat node siap untuk eksekusi Tugas.

  1. Jalankan Tugas Anda:

    kubectl create -f ./job.yaml

    Outputnya mirip dengan hal berikut ini:

    job.batch/sample-job created

  2. Memeriksa status Pekerjaan 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

Integrasi ProvisioningRequest dengan Kueue juga mendukung jenis beban kerja lain yang tersedia di ekosistem open source, seperti berikut:

  • RayJob
  • JobSet
  • Kubeflow MPIJob, TFJob, PyTorchJob.
  • Pod Kubernetes yang sering digunakan oleh orkestrasi alur kerja
  • Cluster mini Flux

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

Permintaan Penyediaan untuk Pekerjaan tanpa Kueue

Membuat permintaan melalui ProvisioningRequest API untuk setiap Tugas. PenyediaanRequest tidak memulai Pod, tetapi hanya menyediakan node.

  1. Buat manifes provisioning-request.yaml berikut:

    apiVersion: v1
kind: PodTemplate
metadata:
  name: POD_TEMPLATE_NAME
  namespace: NAMESPACE_NAME
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/v1beta1
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:

    • NAMESPACE_NAME: Nama namespace Kubernetes Anda. Namespace harus sama dengan namespace Pod.
    • PROVISIONING_REQUEST_NAME: Nama ProvisioningRequest. Anda akan merujuk ke nama ini dalam anotasi Pod.
    • MAX_RUN_DURATION_SECONDS: Opsional, runtime maksimum node dalam hitungan detik, hingga default tujuh hari. Untuk mempelajari lebih lanjut, lihat Cara kerja ProvisioningRequest. Anda tidak dapat mengubah nilai ini setelah membuat permintaan. Kolom ini tersedia dalam Pratinjau di GKE versi 1.28.5-gke.1355000 atau yang lebih baru.
    • COUNT: Jumlah Pod yang diminta. Node dijadwalkan secara atomik dalam satu zona.
    • POD_TEMPLATE_NAME: Nama standar Kubernetes. GKE merujuk ke nilai ini dalam PodSet Permintaan Penyediaan.
    • NODEPOOL_NAME: Nama yang Anda pilih untuk kumpulan node.

  2. Terapkan manifes:

    kubectl apply -f provisioning-request.yaml

Mengonfigurasi Pod

Pada spesifikasi JobSet, tautkan Pod ke ProvisioningRequest menggunakan anotasi berikut:

apiVersion: batch/v1
kind: Job
spec:
  template:
    spec:
      ...
      annotations:
        cluster-autoscaler.kubernetes.io/consume-provisioning-request: PROVISIONING_REQUEST_NAME
        cluster-autoscaler.kubernetes.io/provisioning-class-name: "queued-provisioning.gke.io"

Kunci anotasi Pod cluster-autoscaler.kubernetes.io/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 ProvisioningRequest.
  • Agar permintaan resource tidak dihitung dua kali antara Pod dan ProvisioningRequest di otomatis cluster.
  • Untuk memasukkan anotasi safe-to-evict: false, untuk mencegah penskalaan otomatis cluster 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 ProvisioningRequest

Status ProvisioningRequest 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 ProvisioningRequest dan setiap kemungkinan hasilnya:

Status ProvisioningRequest Deskripsi Kemungkinan hasilnya
Dalam proses Permintaan belum terlihat dan diproses. Setelah diproses, permintaan akan bertransisi ke status Accepted atau Failed.
Accepted=true Permintaan diterima dan sedang menunggu sumber daya 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 untuk menggunakan resource yang disediakan. Setelahnya, penskala otomatis cluster menganggap node tidak diperlukan dan akan menghapusnya.
Failed=true Node tidak dapat disediakan karena terjadi error. Failed=true adalah status terminal. Pecahkan masalah kondisi berdasarkan informasi di kolom Reason dan Message kondisi tersebut. Buat dan coba lagi ProvisioningRequest 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 ProvisioningRequest dibatasi oleh kuota. Reason ini hanya tersedia dengan GKE versi 1.29.2-gke.1181000 atau yang lebih baru.

Memulai Pod

Saat ProvisioningRequest 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 performa penskalaan otomatis cluster.

Atau, jika tidak ingin memiliki Pod yang tidak dapat dijadwalkan, Anda dapat membuat Pod secara paralel dengan ProvisioningRequest.

Batalkan permintaan PenyediaanRequest

Untuk membatalkan permintaan sebelum disediakan, Anda dapat menghapus ProvisioningRequest:

kubectl delete provreq PROVISIONING_REQUEST_NAME -n NAMESPACE

Dalam kebanyakan kasus, menghapus ProvisioningRequest akan menghentikan pembuatan node. Namun, bergantung pada waktunya, misalnya jika node sudah disediakan, node mungkin tetap dibuat. Dalam kasus ini, scaler cluster menghapus node setelah 10 menit jika tidak ada Pod yang dibuat.

Cara kerja ProvisioningRequest

Dengan ProvisioningRequest API, langkah-langkah berikut akan terjadi:

  1. Anda memberi tahu GKE bahwa workload Anda dapat menunggu selama waktu yang tidak tentu, hingga semua node yang diperlukan siap digunakan sekaligus.
  2. Autoscaler cluster menerima permintaan Anda dan menghitung jumlah node yang diperlukan, dan memperlakukannya sebagai satu unit.
  3. Permintaan tersebut akan menunggu hingga semua resource yang diperlukan tersedia dalam satu zona.
  4. Autoscaler cluster menyediakan node yang diperlukan saat tersedia, semuanya sekaligus.
  5. Semua Pod beban kerja dapat berjalan bersama pada node yang baru disediakan.
  6. Node yang disediakan dibatasi hingga tujuh hari runtime, atau lebih awal jika Anda menetapkan parameter maxRunDurationSeconds untuk menunjukkan bahwa beban kerja memerlukan lebih sedikit waktu untuk dijalankan. Untuk mempelajari lebih lanjut, lihat Membatasi runtime VM (Pratinjau). Kemampuan ini tersedia dengan GKE versi 1.28.5-gke.1355000 atau yang lebih baru. Setelah itu, node dan Pod yang menjalankannya akan di-preempt. Jika Pod selesai lebih cepat dan node tidak digunakan, penskalaan otomatis cluster akan menghapusnya sesuai dengan profil penskalaan otomatis.
  7. Node tidak digunakan kembali di antara ProvisioningRequest. Setiap PenyediaanRequest akan memesan pembuatan node baru dengan runtime tujuh hari yang baru.

Kuota

Jumlah ProvisioningRequest yang memiliki status Accepted dibatasi oleh kuota khusus, yang dikonfigurasi per project, secara terpisah untuk setiap region.

Memeriksa kuota di Konsol Google Cloud

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

  1. Buka halaman Kuota di Konsol Google Cloud:

    Buka Quotas

  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 ProvisioningRequest dibatasi kuota

Jika permintaan ProvisioningRequest Anda memerlukan waktu lebih lama dari yang diperkirakan untuk dipenuhi, pastikan permintaan tersebut tidak dibatasi 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

Output-nya mirip dengan 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 cukup kuota di region europe-west4.

Mengonfigurasi setelan gangguan untuk kumpulan node dengan workload menggunakan ProvisioningRequest

Workload yang memerlukan ketersediaan semua node, atau sebagian besar node, di dalam kumpulan node sensitif terhadap penghapusan. Perbaikan atau upgrade otomatis node yang disediakan menggunakan ProvisioningRequest API tidak didukung karena operasi ini akan menghapus semua workload yang berjalan pada node tersebut dan membuat workload tidak dapat dijadwalkan.

Untuk meminimalkan gangguan pada workload yang berjalan menggunakan ProvisioningRequest, sebaiknya lakukan langkah-langkah berikut:

  • Bergantung pada pendaftaran saluran rilis cluster Anda, gunakan praktik terbaik berikut untuk mencegah upgrade otomatis node mengganggu beban kerja Anda:
  • Nonaktifkan perbaikan otomatis node.
  • Gunakan masa pemeliharaan dan pengecualian untuk meminimalkan gangguan pada beban kerja yang berjalan, sekaligus memastikan bahwa ada jangka waktu saat GKE dapat mengganggu kumpulan node untuk pemeliharaan otomatis. Jika menggunakan alat pemeliharaan ini, Anda harus menetapkan periode waktu tertentu ketika GKE dapat mengganggu kumpulan node. Jadi, sebaiknya tetapkan periode ini saat tidak ada workload yang berjalan.
  • Untuk memastikan kumpulan node Anda tetap terbaru, sebaiknya upgrade kumpulan node secara manual saat tidak ada permintaan ProvisioningRequest yang aktif dan kumpulan node kosong.

Batasan

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

Langkah selanjutnya