使用彈性啟動搭配佈建佇列，執行大規模工作負載

自動駕駛 標準

---

注意： 彈性啟動搭配佈建佇列支援新標記，這些標記是彈性啟動搶先版的一部分。

本頁面說明如何使用「彈性啟動」和「排隊佈建」功能，搭配 Dynamic Workload Scheduler，為使用 GPU 的大規模批次和 AI 工作負載，盡量取得 GPU 資源。

閱讀本頁面之前，請先熟悉下列概念：

• 關於 GKE 中的 GPU
• 關於 GKE 中的 GPU 取得能力

本指南適用於機器學習 (ML) 工程師、平台管理員和操作員，以及有興趣使用 Kubernetes 容器自動化調度管理功能執行批次工作負載的資料和 AI 專家。如要進一步瞭解 Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見的 GKE Enterprise 使用者角色和工作」。

彈性啟動搭配佈建佇列的運作方式

如果使用彈性啟動搭配佈建佇列，GKE 會同時分配所有要求的資源。彈性啟動搭配佈建佇列會使用下列工具：

• 具備佈建佇列功能的彈性啟動功能，是以動態工作負載排程器搭配佈建要求自訂資源定義 (CRD) 為基礎。這些工具會根據可用資源和工作負載需求，管理分配的容量。
• (選用) Kueue 會自動處理彈性啟動的生命週期，並將佈建要求加入佇列。Kueue 會實作 Job 排隊機制，並自動處理 Provisioning Request 的生命週期。

如要搭配排隊佈建使用彈性啟動，您必須在建立節點集區時新增 --flex-start 和 --enable-queued-provisioning 標記。

最佳做法：

如果工作負載符合下列條件，請使用彈性啟動搭配佇列佈建，處理大規模批次和 AI 工作負載：

• 工作負載的開始時間很彈性。
• 工作負載必須同時在多個節點上執行。

如要執行可在單一節點上執行的小型工作負載，請使用彈性啟動。如要進一步瞭解如何在 GKE 中佈建 GPU，請參閱「取得 AI 工作負載的加速器」。

事前準備

開始之前，請確認你已完成下列工作：

• 啟用 Google Kubernetes Engine API。
啟用 Google Kubernetes Engine API
• 如要使用 Google Cloud CLI 執行這項工作，請安裝並初始化 gcloud CLI。如果您先前已安裝 gcloud CLI，請執行 gcloud components update，取得最新版本。
  注意：如果是現有的 gcloud CLI 安裝項目，請務必設定 compute/region 和 compute/zone 屬性。設定預設位置後，即可避免 gcloud CLI 發生下列錯誤： One of [--zone, --region] must be supplied: Please specify location.

• 請確認您已完成下列任一事項：
  • 版本為 1.28.3-gke.1098000 以上的現有標準叢集。
  • 版本為 1.30.3-gke.1451000 以上的現有 Autopilot 叢集。
• 請確認叢集控制層執行 1.32.2-gke.1652000 以上版本，才能使用彈性啟動功能。
• 請務必管理使用動態工作負載排程器的工作負載中斷情形，避免工作負載中斷。
• 請務必熟悉彈性啟動搭配佇列佈建的限制。
• 使用標準叢集時，請確保至少維護一個節點集區，且該集區未啟用彈性啟動功能，但已啟用叢集的佈建佇列功能，叢集才能正常運作。

使用彈性啟動搭配佈建佇列的節點集區

本節內容僅適用於標準叢集。

您可以透過下列任一方法，指定叢集中的特定節點集區可使用「彈性啟動」搭配「已排入佇列的佈建」：

• 建立節點集區。
• 設定節點自動佈建功能，建立啟用排隊佈建功能的彈性啟動節點集區。

建立節點集區

使用 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 \
    --flex-start \
    --enable-autoscaling  \
    --num-nodes=0   \
    --total-max-nodes TOTAL_MAX_NODES  \
    --location-policy=ANY  \
    --reservation-affinity=none  \
    --no-enable-autorepair

更改下列內容：

• NODEPOOL_NAME：您為節點集區選擇的名稱。
• CLUSTER_NAME：叢集名稱。
• LOCATION：叢集的 Compute Engine 區域，例如 us-central1。
• GPU_TYPE：GPU 類型。
• AMOUNT：要附加至節點集區中節點的 GPU 數量。
• DRIVER_VERSION：要安裝的 NVIDIA 驅動程式版本。 可以是下列任一值：
  • default：安裝 GKE 版本的預設驅動程式版本。
  • latest：為 GKE 版本安裝最新可用驅動程式版本。僅適用於使用 Container-Optimized OS 的節點。
• TOTAL_MAX_NODES：整個節點集區自動調度節點數量上限。

• MACHINE_TYPE：節點的 Compute Engine 機器類型。

  最佳做法：

  使用加速器最佳化機型，提升 AI/機器學習工作負載的效能和效率。

您也可以使用下列標記：

• --node-locations=COMPUTE_ZONES：以半形逗號分隔的一或多個可用區清單，GKE 會在這些可用區中建立 GPU 節點。可用區必須與叢集位於相同區域。選擇提供 GPU 的區域。
• --enable-gvnic：這個旗標會在 GPU 節點集區上啟用 gVNIC，以提高網路流量速度。

這項指令會建立具有下列設定的節點集區：

• --flex-start 旗標與 --enable-queued-provisioning 旗標搭配使用時，會指示 GKE 建立節點集區，並啟用排隊佈建功能，以及將 cloud.google.com/gke-queued 汙點新增至節點集區。
• GKE 支援排隊佈建和叢集自動調度資源。
• 節點集區一開始沒有任何節點。
• --no-enable-autorepair 旗標會停用自動修復功能，這可能會中斷在修復節點上執行的工作負載。

啟用節點自動佈建功能，為採用排隊佈建的彈性啟動模式建立節點集區

如果叢集執行的是 1.29.2-gke.1553000 以上版本，您可以使用節點自動佈建功能，管理彈性啟動節點集區的佇列佈建作業。啟用節點自動佈建功能後，GKE 會建立節點集區，並為相關聯的工作負載提供必要資源。

如要啟用節點自動佈建功能，請考量下列設定，並完成「設定 GPU 限制」中的步驟：

• 啟用這項功能後，請指定彈性啟動和佇列佈建所需的資源。如要列出可用的 resourceTypes，請執行 gcloud compute accelerator-types list 指令。
• 使用 --no-enable-autoprovisioning-autorepair 旗標停用節點自動修復功能。
• 讓 GKE 自動在自動佈建的 GPU 節點中安裝 GPU 驅動程式。詳情請參閱使用節點自動佈建功能安裝 GPU 驅動程式。

使用彈性啟動搭配佈建佇列，執行批次和 AI 工作負載

如要使用彈性啟動搭配佈建佇列執行批次工作負載，請使用下列任一設定：

• 搭配 Kueue 使用彈性啟動搭配佈建佇列功能，處理工作：您可以搭配 Kueue 使用彈性啟動搭配佈建佇列功能，自動處理佈建要求的生命週期。Kueue 會實作工作佇列，並觀察已排入佇列的佈建作業，瞭解彈性啟動的狀態。Kueue 會根據配額和資源共用階層，決定 Job 應等待或啟動的時間，確保各團隊公平分配資源。

• 彈性啟動搭配佈建佇列，適用於沒有 Kueue 的工作：使用自己的內部批次排程工具或平台時，可以不搭配 Kueue 使用彈性啟動搭配佈建佇列。您手動建立及取消佈建要求。

最佳做法：

使用 Kueue 執行批次和 AI 工作負載，並透過佇列佈建功能彈性啟動。

使用 Kueue 搭配佈建佇列，以彈性啟動模式執行 Job

以下各節說明如何為使用 Kueue 的 Job 設定彈性啟動，並排隊等待佈建：

• 設定彈性啟動搭配佈建佇列的節點集區。
• 設定預留項目和彈性啟動搭配佈建佇列的節點集區。

本節使用 ai-on-gke 存放區中 dws-examples 目錄的範例。我們已在 Apache2 授權下，將範例發布至 dws-examples 目錄。

您必須具備管理員權限，才能安裝 Kueue。如要取得這些權限，請確認您已獲授 roles/container.admin IAM 角色。如要進一步瞭解 GKE IAM 角色，請參閱建立 IAM 允許政策指南。

準備環境

1. 在 Cloud Shell 中執行下列指令：

   git clone https://github.com/GoogleCloudPlatform/ai-on-gke
   cd ai-on-gke/tutorials-and-examples/workflow-orchestration/dws-examples
   

2. 在叢集中安裝最新版 Kueue：

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

   將 KUEUE_VERSION 替換為最新版 Kueue。

如果使用 0.7.0 之前的 Kueue 版本，請將 ProvisioningACC 特徵閘設定為 true，變更 Kueue 特徵閘設定。如需更詳細的說明和預設閘道值，請參閱 Kueue 的功能閘道。如要進一步瞭解如何安裝 Kueue，請參閱「安裝」一文。

建立 Kueue 資源，僅適用於 Dynamic Workload Scheduler 節點集區設定

使用下列資訊清單，建立名為 dws-cluster-queue 的叢集層級佇列，以及名為 dws-local-queue 的 LocalQueue 命名空間。如果作業在這個命名空間中參照 dws-cluster-queue 佇列，系統會使用彈性啟動搭配佇列佈建功能，取得 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: 1000000000 # "Infinite" quota
            - name: "memory"
              nominalQuota: 1000000000Gi # "Infinite" quota
            - name: "nvidia.com/gpu"
              nominalQuota: 1000000000 # "Infinite" quota
            - name: "ephemeral-storage"
              nominalQuota: 1000000000Ti # "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"
---
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  labels:
    control-plane: controller-manager
  name: controller-manager-metrics-monitor
  namespace: kueue-system
spec:
  endpoints:
    - path: /metrics
      port: 8080
      scheme: http
      interval: 30s
  selector:
    matchLabels:
      control-plane: controller-manager
---

這個叢集的佇列配額上限較高，且只啟用「彈性啟動並排隊佈建」整合功能。如要進一步瞭解 Kueue API 和如何設定限制，請參閱「Kueue 概念」。

部署 LocalQueue：

kubectl create -f ./dws-queues.yaml

輸出結果會與下列內容相似：

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

如要在其他命名空間中執行使用彈性啟動和佇列佈建的 Job，可以運用上述範本建立其他 LocalQueues。

執行工作

在下列資訊清單中，範例工作使用「已排隊」佈建的彈性啟動：

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

這個資訊清單包含下列欄位，與排隊佈建設定的彈性啟動相關：

• kueue.x-k8s.io/queue-name: dws-local-queue 標籤會告知 GKE，Kueue 負責協調該工作。這個標籤也會定義工作排入佇列的佇列。
• suspend: true 旗標會告知 GKE 建立 Job 資源，但暫時不要排定 Pod。節點準備好執行 Job 時，Kueue 會將該標記變更為 false。
• nodeSelector 會告知 GKE 只在指定的節點集區中排定 Job。這個值應與 NODEPOOL_NAME 相符，也就是啟用佇列佈建的節點集區名稱。

1. 執行工作：

   kubectl create -f ./job.yaml
   

   輸出結果會與下列內容相似：

   job.batch/sample-job created
   

2. 查看工作狀態：

   kubectl describe job sample-job
   

   輸出結果會與下列內容相似：

   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
   

透過 Kueue 整合的佇列佈建彈性啟動功能，也支援開放原始碼生態系統中的其他工作負載類型，例如：

• RayJob
• JobSet v0.5.2 以上版本
• Kubeflow MPIJob、TFJob、PyTorchJob。
• 工作流程自動化調度工具經常使用的 Kubernetes Pod
• Flux 迷你叢集

如要進一步瞭解這項支援，請參閱 Kueue 的批次使用者。

建立 Kueue 資源，用於預留項目和動態工作負載排程器節點集區設定

使用下列資訊清單，建立與兩個不同節點集區 (reservation-nodepool 和 dws-nodepool) 綁定的兩個 ResourceFlavors。這些節點集區的名稱僅為範例。請根據節點集區設定修改這些名稱。 此外，透過 ClusterQueue 設定，傳入的工作會嘗試使用 reservation-nodepool，如果沒有容量，這些工作會使用動態工作負載排程器取得 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: 1000000000 # "Infinite" quota
            - name: "memory"
              nominalQuota: 1000000000Gi # "Infinite" quota
            - name: "nvidia.com/gpu"
              nominalQuota: 1000000000 # "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

這個叢集的佇列配額上限較高，且只啟用「彈性啟動並排隊佈建」整合功能。如要進一步瞭解 Kueue API 和如何設定限制，請參閱「Kueue 概念」。

使用下列指令部署資訊清單：

kubectl create -f ./dws_and_reservation.yaml

輸出結果會與下列內容相似：

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

執行工作

與先前的設定相反，這個資訊清單不包含 nodeSelector 欄位，因為該欄位是由 Kueue 填入，視 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. 執行工作：

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

   輸出結果會與下列內容相似：

   job.batch/sample-job-v8xwm created
   

如要找出工作使用的節點集區，請先瞭解工作使用的 ResourceFlavor。

疑難排解

如要進一步瞭解如何排解 Kueue 問題，請參閱「排解 Kueue 中的佈建要求問題」。

不使用 Kueue 的工作，可採用彈性啟動搭配佈建佇列

定義 ProvisioningRequest 物件

透過「Provisioning Request」(佈建要求) 為每個工作建立要求。 彈性啟動搭配佈建佇列不會啟動 Pod，只會佈建節點。

1. 建立下列 provisioning-request.yaml 資訊清單：

   標準

   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
         cloud.google.com/gke-flex-start: "true"
       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
   

   更改下列內容：

   • API_VERSION：API 版本，可以是 v1 或 v1beta1。如果是 GKE 1.31.1-gke.1678000 以上版本，建議使用 v1，確保穩定性並存取最新功能。
   • NAMESPACE_NAME：Kubernetes 命名空間的名稱。命名空間必須與 Pod 的命名空間相同。
   • PROVISIONING_REQUEST_NAME：ProvisioningRequest 的名稱。您會在 Pod 註解中參照這個名稱。
   • MAX_RUN_DURATION_SECONDS：(選用) 節點的執行時間上限，以秒為單位，最多為預設的七天。詳情請參閱「如何使用排隊佈建功能彈性啟動」。要求建立後，您就無法變更這個值。這個欄位適用於 GKE 1.28.5-gke.1355000 以上版本。
   • COUNT：要求的 Pod 數量。節點會以不可分割的形式排定在一個可用區中。
   • POD_TEMPLATE_NAME：PodTemplate 的名稱。
   • NODEPOOL_NAME：您為節點集區選擇的名稱。如要使用自動佈建的節點集區，請移除此項目。

   GKE 可能會在建立 Pod 時套用驗證和突變。GKE 可透過 cloud.google.com/apply-warden-policies 標籤，對 PodTemplate 物件套用相同的驗證和突變。 GKE 必須使用這個標籤，才能計算 Pod 的節點資源需求。整合彈性啟動和佇列佈建時，只能支援一個 PodSet 規格。如要混合使用不同的 Pod 範本，請使用要求最多資源的範本。系統不支援混用不同機器類型，例如使用不同 GPU 類型的 VM。

   節點自動佈建

   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
         cloud.google.com/gke-flex-start: "true"
       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
   

   更改下列內容：

   • API_VERSION：API 版本，可以是 v1 或 v1beta1。如果是 GKE 1.31.1-gke.1678000 以上版本，建議使用 v1，確保穩定性並存取最新功能。
   • NAMESPACE_NAME：Kubernetes 命名空間的名稱。命名空間必須與 Pod 的命名空間相同。
   • PROVISIONING_REQUEST_NAME：ProvisioningRequest 的名稱。您會在 Pod 註解中參照這個名稱。
   • MAX_RUN_DURATION_SECONDS：(選用) 節點的執行時間上限，以秒為單位，最多為預設的七天。詳情請參閱「如何使用排隊佈建功能彈性啟動」。要求建立後，您就無法變更這個值。這個欄位適用於 GKE 1.28.5-gke.1355000 以上版本。
   • COUNT：要求的 Pod 數量。節點會以不可分割的形式排定在一個可用區中。
   • POD_TEMPLATE_NAME：PodTemplate 的名稱。
   • GPU_TYPE：GPU 硬體類型。

   GKE 可能會在建立 Pod 時套用驗證和突變。GKE 可透過 cloud.google.com/apply-warden-policies 標籤，對 PodTemplate 物件套用相同的驗證和突變。 GKE 必須使用這個標籤，才能計算 Pod 的節點資源需求。

2. 套用資訊清單：

   kubectl apply -f provisioning-request.yaml
   

設定 Pod

本節會使用 Kubernetes 工作設定 Pod。不過，您也可以使用 Kubernetes JobSet 或任何其他架構，例如 Kubeflow、Ray 或自訂控制器。在 Job 規格中，使用下列註解將 Pod 連結至 ProvisioningRequest：

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:
      ...

在 GKE 1.30.3-gke.1854000 之前的版本中，您必須使用下列舊版註解：

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

請注意，從 GKE 1.31.1-gke.1678000 版開始，cluster-autoscaler.kubernetes.io/consume-provisioning-request 和 cluster-autoscaler.kubernetes.io/provisioning-class-name 註解已淘汰。

Pod 註解鍵 consume-provisioning-request 會定義要使用的 ProvisioningRequest。GKE 會使用 consume-provisioning-request 和 provisioning-class-name 註解執行下列操作：

• 只在透過彈性啟動搭配佈建佇列佈建的節點中排程 Pod。
• 為避免重複計算 Pod 之間的資源要求，請在叢集自動調度器中，使用排隊佈建功能彈性啟動。
• 如要插入 safe-to-evict: false 註解，請防止叢集自動調度器在節點之間移動 Pod，並中斷批次運算。如要變更這項行為，請在 Pod 註解中指定 safe-to-evict: true。

觀察佈建要求狀態

佈建要求的狀態會決定 Pod 是否可排程。 您可以運用 Kubernetes 監控功能有效觀察變更，或是使用您已用於追蹤 Kubernetes 物件狀態的其他工具。下表說明「佈建要求」要求的可能狀態，以及每種可能結果：

佈建要求狀態	說明	可能結果
待處理	我們尚未看到並處理這項要求。	處理完畢後，要求會轉換為 Accepted 或 Failed 狀態。
Accepted=true	要求已獲准，正在等待資源可用。	如果找到資源並佈建節點，要求應轉換為 Provisioned 狀態；如果無法佈建節點，則應轉換為 Failed 狀態。
Provisioned=true	節點已準備就緒。	你必須在 10 分鐘內啟動 Pod，才能使用已佈建的資源。時間一到，叢集自動配置器就會將節點視為不需要，並移除節點。
Failed=true	發生錯誤，因此無法佈建節點。Failed=true 為終端狀態。	根據條件的 Reason 和 Message 欄位中的資訊，排解條件問題。建立並重試新的 Provisioning Request 要求。
Provisioned=false	節點尚未佈建。	如果是 Reason=NotProvisioned，這表示所有資源尚未完全就緒，目前處於暫時狀態。 如果 Reason=QuotaExceeded，請根據這個原因和條件的 Message 欄位資訊，排解條件問題。您可能需要申請提高配額。詳情請參閱「檢查佈建要求是否受配額限制」一節。這項 Reason 僅適用於 GKE 1.29.2-gke.1181000 以上版本。 如果 Reason=ResourcePoolExhausted，且 Message 包含 Expected time is indefinite，請選取其他可用區或區域，或調整要求的資源。

啟動 Pod

當「Provisioning Request」要求達到 Provisioned=true 狀態時，您可以執行「Job」來啟動 Pod。這樣一來，待處理或失敗的要求就不會導致無法排程的 Pod 大量增加，進而影響 kube-scheduler 和叢集自動調度資源的效能。

或者，如果您不在意有無法排程的 Pod，可以與佈建要求並行建立 Pod。

取消佈建要求

如要在佈建要求前取消，可以刪除 ProvisioningRequest：

kubectl delete provreq PROVISIONING_REQUEST_NAME -n NAMESPACE

在大多數情況下，刪除 ProvisioningRequest 會停止建立節點。不過，視時間而定 (例如節點已佈建)，節點可能仍會建立。在這些情況下，如果沒有建立任何 Pod，叢集自動調度器會在 10 分鐘後移除節點。

排解配額問題

透過 Provisioning Request 要求佈建的所有 VM 都會使用搶占型配額。

處於 Accepted 狀態的 ProvisioningRequests 數量受專屬配額限制。您可以為每個專案設定配額，每個區域各設定一個配額。

在 Google Cloud 控制台中查看配額

如要在Google Cloud 控制台中查看配額上限名稱和目前用量，請按照下列步驟操作：

1. 前往 Google Cloud 控制台的「配額」頁面：

   前往配額頁面

2. 在「篩選器」方塊中，選取「指標」屬性，輸入 active_resize_requests，然後按 Enter 鍵。

預設值為 100。如要提高配額，請按照「申請調整配額」一文中的步驟操作。

檢查佈建要求是否受配額限制

如果佈建要求處理時間超出預期，請確認要求是否受配額限制。您可能需要申請提高配額。

如果叢集執行的是 1.29.2-gke.1181000 以上版本，請檢查特定配額限制是否導致要求無法完成：

kubectl describe provreq PROVISIONING_REQUEST_NAME \
    --namespace NAMESPACE

輸出結果會與下列內容相似：

…
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
…

在本例中，由於 europe-west4 區域的配額不足，GKE 無法部署節點。

將節點集區從排入佇列佈建遷移至彈性啟動

如要將使用 --enable-queued-provisioning 旗標建立的現有節點集區遷移至新的彈性啟動模式，請執行下列指令：

  gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME --flex-start

這項作業會執行下列動作：

• 將節點集區更新為彈性啟動節點集區。
• 套用彈性啟動節點的價格。

在 1.32.2-gke.1652000 以上版本 (彈性啟動節點的最低版本) 上執行的叢集，所有節點都會使用短期升級。

後續步驟

• 進一步瞭解 GKE 中的 GPU。
• 瞭解如何在 Autopilot 中部署 GPU 工作負載。
• 瞭解如何在機密 GKE 節點上執行 GPU (預先發布版)。