Esegui un carico di lavoro su larga scala con avvio flessibile con il provisioning in coda

Questa pagina mostra come ottimizzare l'ottenibilità delle GPU per i workload batch e di AI su larga scala con GPU che utilizzano l'avvio flessibile con il provisioning in coda basato su Dynamic Workload Scheduler.

Prima di leggere questa pagina, assicurati di conoscere quanto segue:

Questa guida è rivolta a data engineer, amministratori e operatori della piattaforma e a specialisti di dati e IA interessati a utilizzare le funzionalità di orchestrazione dei container Kubernetes per l'esecuzione di carichi di lavoro batch. Per ulteriori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Come funziona l'avvio flessibile con il provisioning in coda

Con l'avvio flessibile con provisioning in coda, GKE alloca tutte le risorse richieste contemporaneamente. L'avvio flessibile con provisioning in coda utilizza i seguenti strumenti:

Per utilizzare l'avvio flessibile con il provisioning in coda, devi aggiungere i flag --flex-start e --enable-queued-provisioning quando crei il pool di nodi.

Best practice:

Utilizza l'avvio flessibile con provisioning in coda per i carichi di lavoro batch e di IA su larga scala quando soddisfano i seguenti criteri:

  • I carichi di lavoro hanno orari di inizio flessibili.
  • I carichi di lavoro devono essere eseguiti su più nodi contemporaneamente.

Per carichi di lavoro più piccoli che possono essere eseguiti su un singolo nodo, utilizza la modalità di provisioning con avvio flessibile. Per ulteriori informazioni sul provisioning delle GPU in GKE, consulta Ottenere acceleratori per i workload AI.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Attiva l'API Google Kubernetes Engine.
    • Attiva l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza gcloud CLI. Se hai già installato l'interfaccia a riga di comando gcloud, ottieni la versione più recente eseguendo gcloud components update.

Utilizzare i pool di nodi con avvio flessibile con provisioning in coda

Questa sezione si applica solo ai cluster standard.

Puoi utilizzare uno dei seguenti metodi per indicare che l'avvio flessibile con il provisioning in coda può funzionare con pool di nodi specifici nel tuo cluster:

Crea un node pool

Crea un pool di nodi con avvio flessibile e provisioning in coda abilitato utilizzando 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

Sostituisci quanto segue:

  • NODEPOOL_NAME: il nome scelto per il node pool.
  • CLUSTER_NAME: il nome del cluster.
  • LOCATION: la regione Compute Engine del cluster, ad esempio us-central1.
  • GPU_TYPE: il tipo di GPU.
  • AMOUNT: il numero di GPU da collegare ai nodi nel node pool.
  • DRIVER_VERSION: la versione del driver NVIDIA da installare. Può essere uno dei seguenti:
    • default: installa la versione predefinita del driver per la versione GKE.
    • latest: installa la versione più recente del driver disponibile per la tua versione GKE. Disponibile solo per i nodi che utilizzano Container-Optimized OS.
  • TOTAL_MAX_NODES: il numero massimo di nodi da scalare automaticamente per l'intero pool di nodi.

  • MACHINE_TYPE: il tipo di macchina Compute Engine per i tuoi nodi.

    Best practice:

    Utilizza un tipo di macchina ottimizzato per l'acceleratore per migliorare le prestazioni e l'efficienza per i carichi di lavoro di AI/ML.

Se vuoi, puoi utilizzare i seguenti flag:

  • --node-locations=COMPUTE_ZONES: l'elenco separato da virgole di una o più zone in cui GKE crea i nodi GPU. Le zone devono trovarsi nella stessa regione del cluster. Scegli le zone con GPU disponibili.
  • --enable-gvnic: questo flag attiva gVNIC nei pool di nodi GPU per aumentare la velocità del traffico di rete.

Questo comando crea un pool di nodi con la seguente configurazione:

  • Il flag --flex-start combinato con il flag --enable-queued-provisioning incarica GKE di creare un node pool con avvio flessibile con provisioning in coda attivo e di aggiungere l'attributo cloud.google.com/gke-queued al node pool.
  • GKE consente il provisioning in coda e la scalabilità automatica dei cluster.
  • Il pool di nodi inizialmente non ha nodi.
  • Il flag --no-enable-autorepair disattiva le riparazioni automatiche, il che potrebbe interrompere i carichi di lavoro in esecuzione sui nodi riparati.

Abilita il provisioning automatico dei nodi per creare pool di nodi per l'avvio flessibile con il provisioning in coda

Puoi utilizzare il provisioning automatico dei nodi per gestire i pool di nodi per l'avvio flessibile con il provisioning in coda per i cluster che eseguono la versione 1.29.2-gke.1553000 o successiva. Quando attivi il provisioning automatico dei nodi, GKE crea i pool di nodi con le risorse richieste per il carico di lavoro associato.

Per attivare il provisioning automatico dei nodi, prendi in considerazione le seguenti impostazioni e completa i passaggi descritti in Configurare i limiti GPU:

  • Specifica le risorse necessarie per l'avvio flessibile con il provisioning in coda quando attivi la funzionalità. Per elencare i resourceTypes disponibili, esegui il comando gcloud compute accelerator-types list.
  • Utilizza il flag --no-enable-autoprovisioning-autorepair per disattivare la riparazione automatica dei nodi.
  • Consenti a GKE di installare automaticamente i driver GPU nei nodi GPU con provisioning automatico. Per ulteriori informazioni, consulta Installare i driver utilizzando il provisioning automatico dei nodi con le GPU.

Esegui i carichi di lavoro batch e di IA con avvio flessibile e provisioning in coda

Per eseguire carichi di lavoro batch con avvio flessibile con provisioning in coda, utilizza una delle seguenti configurazioni:

  • Avvio flessibile con provisioning in coda per i job con Kueue: puoi utilizzare l'avvio flessibile con provisioning in coda con Kueue per automatizzare il ciclo di vita delle richieste di Provisioning Request. Kueue implementa la coda dei job e osserva lo stato dell'avvio flessibile con il provisioning in coda. Kueue decide quando i job devono attendere e quando devono iniziare, in base a quote e a una gerarchia per condividere equamente le risorse tra i team.

  • Avvio flessibile con provisioning in coda per i job senza Kueue: puoi utilizzare l'avvio flessibile con provisioning in coda senza Kueue se utilizzi la tua piattaforma o i tuoi strumenti di pianificazione batch interni. Devi creare e annullare manualmente la richiesta di provisioning.

Best practice:

Utilizza Kueue per eseguire i carichi di lavoro batch e di IA con avvio flessibile con provisioning in coda.

Avvio flessibile con provisioning in coda per i job con Kueue

Le sezioni seguenti mostrano come configurare l'avvio flessibile con il provisioning in coda per i job con Kueue:

  • Avvio flessibile con configurazione del pool di nodi di provisioning in coda.
  • Prenotazione e avvio flessibile con configurazione del pool di nodi di provisioning in coda.

Questa sezione utilizza gli esempi nella directory dws-examples del repository ai-on-gke. Abbiamo pubblicato gli esempi nella directory dws-examples in base alla licenza Apache2.

Per installare Kueue devi disporre delle autorizzazioni di amministratore. Per ottenerli, assicurati di disporre del ruolo IAM roles/container.admin. Per scoprire di più sui ruoli IAM di GKE, consulta la guida alla creazione di criteri di autorizzazione IAM.

prepara l'ambiente

  1. In Cloud Shell, esegui questo comando:

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

  2. Installa la versione più recente di Kueue nel cluster:

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

    Sostituisci KUEUE_VERSION con la versione più recente di Kueue.

Se utilizzi Kueue in una versione precedente a 0.7.0, modifica la configurazione del gate delle funzionalità di Kueue impostando il gate delle funzionalità ProvisioningACC su true. Per una spiegazione più dettagliata e i valori predefiniti dei cancelli, consulta la sezione Cancelli delle funzionalità di Kueue. Per ulteriori informazioni sull'installazione di Kueue, consulta Installazione.

Crea le risorse Kueue per la configurazione solo del pool di nodi Dynamic Workload Scheduler

Con il seguente manifest, crei una coda a livello di cluster denominata dws-cluster-queue e lo spazio dei nomi LocalQueue denominato dws-local-queue. I job che fanno riferimento alla coda dws-cluster-queue in questo spazio dei nomi utilizzano flex-start con il provisioning in coda per ottenere le risorse 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"
---

La coda di questo cluster ha limiti di quota elevati ed è abilitata solo l'integrazione del provisioning in coda con inizio flessibile. Per ulteriori informazioni sulle API Kueue e su come impostare i limiti, consulta Concetti di Kueue.

Esegui il deployment di LocalQueue:

kubectl create -f ./dws-queues.yaml

L'output è simile al seguente:

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

Se vuoi eseguire job che utilizzano l'avvio flessibile con il provisioning in coda in altri spazi dei nomi, puoi creare altri LocalQueues utilizzando il modello precedente.

Esegui il job

Nel manifest seguente, il job di esempio utilizza l'avvio flessibile con il provisioning in coda:

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

Questo manifest include i seguenti campi pertinenti per la configurazione del provisioning in coda con inizio flessibile:

  • L'etichetta kueue.x-k8s.io/queue-name: dws-local-queue indica a GKE che Kueue è responsabile dell'orchestrazione del job. Questa etichetta definisce anche la coda in cui è in coda il job.
  • Il flag suspend: true indica a GKE di creare la risorsa Job, ma di non pianificare ancora i pod. Kueue modifica questo flag in false quando i nodi sono pronti per l'esecuzione del job.
  • nodeSelector indica a GKE di pianificare il compito solo nel pool di nodi specificato. Il valore deve corrispondere a NODEPOOL_NAME, il nome del pool di nodi con il provisioning in coda abilitato.

  1. Esegui il job:

    kubectl create -f ./job.yaml

    L'output è simile al seguente:

    job.batch/sample-job created

  2. Controlla lo stato del tuo job:

    kubectl describe job sample-job

    L'output è simile al seguente:

    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

L'avvio flessibile con il provisioning in coda con l'integrazione di Kueue supporta anche altri tipi di carichi di lavoro disponibili nell'ecosistema open source, ad esempio:

  • RayJob
  • JobSet versione 0.5.2 o successive
  • Kubeflow MPIJob, TFJob, PyTorchJob.
  • Pod Kubernetes utilizzati di frequente dagli orchestratori dei flussi di lavoro
  • Mini cluster Flux

Per ulteriori informazioni su questo supporto, consulta Utente batch di Kueue.

Crea le risorse Kueue per la configurazione del pool di nodi di prenotazione e Dynamic Workload Scheduler

Con il seguente manifest, crei due ResourceFlavors associati a due diversi node pool: reservation-nodepool e dws-nodepool. I nomi di questi pool di nodi sono solo esempi. Modifica questi nomi in base alla configurazione del pool di nodi. Inoltre, con la configurazione ClusterQueue, i job in arrivo tentano di utilizzare reservation-nodepool e, se non è presente alcuna capacità, questi job utilizzano Dynamic Workload Scheduler per ottenere le risorse 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

La coda di questo cluster ha limiti di quota elevati ed è abilitata solo l'integrazione del provisioning in coda con inizio flessibile. Per ulteriori informazioni sulle API Kueue e su come impostare i limiti, consulta Concetti di Kueue.

Esegui il deployment del manifest utilizzando il seguente comando:

kubectl create -f ./dws_and_reservation.yaml

L'output è simile al seguente:

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

Esegui il job

A differenza della configurazione precedente, questo manifest non include il campo nodeSelector perché viene compilato da Kueue, a seconda della capacità libera nel 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. Esegui il job:

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

    L'output è simile al seguente:

    job.batch/sample-job-v8xwm created

Per identificare il pool di nodi utilizzato dal tuo job, devi scoprire quale ResourceFlavor utilizza il tuo job.

Risoluzione dei problemi

Per ulteriori informazioni sulla risoluzione dei problemi di Kueue, consulta Risoluzione dei problemi relativi alla richiesta di provisioning in Kueue.

Avvio flessibile con provisioning in coda per i job senza coda

Definisci un oggetto ProvisioningRequest

Crea una richiesta tramite la Richiesta di provisioning per ogni job. L'avvio flessibile con provisioning in coda non avvia i pod, ma esegue solo il provisioning dei nodi.

  1. Crea il seguente manifest provisioning-request.yaml:

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

    Sostituisci quanto segue:

    • API_VERSION: la versione dell'API, v1 o v1beta1. Per la versione GKE 1.31.1-gke.1678000 e quelle successive, consigliamo di utilizzare v1 per la stabilità e l'accesso alle funzionalità più recenti.
    • NAMESPACE_NAME: il nome dello spazio dei nomi Kubernetes. Lo spazio dei nomi deve essere lo stesso dello spazio dei nomi dei pod.
    • PROVISIONING_REQUEST_NAME: il nome del ProvisioningRequest. Farai riferimento a questo nome nell'annotazione del pod.
    • MAX_RUN_DURATION_SECONDS: facoltativo, il tempo di esecuzione massimo di un nodo in secondi, fino al valore predefinito di sette giorni. Per scoprire di più, consulta Come funziona il provisioning in coda con inizio flessibile. Non puoi modificare questo valore dopo la creazione della richiesta. Questo campo è disponibile in GKE versione 1.28.5-gke.1355000 o successive.
    • COUNT: numero di pod richiesti. I nodi vengono pianificati in modo atomico in una zona.
    • POD_TEMPLATE_NAME: il nome del PodTemplate.
    • NODEPOOL_NAME: il nome scelto per il node pool. Rimuovi se vuoi utilizzare un node pool con provisioning automatico.

    GKE potrebbe applicare convalide e mutazioni ai pod durante la loro creazione. L'etichetta cloud.google.com/apply-warden-policies consente a GKE di applicare le stesse convalide e mutazioni agli oggetti PodTemplate. Questa etichetta è necessaria per consentire a GKE di calcolare i requisiti delle risorse dei nodi per i pod. L'integrazione dell'avvio flessibile con il provisioning in coda supporta una sola specifica PodSet. Se vuoi combinare diversi modelli di pod, utilizza quello che richiede più risorse. La combinazione di diversi tipi di macchine, ad esempio VM con diversi tipi di GPU, non è supportata.

    Provisioning automatico dei nodi 

    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

    Sostituisci quanto segue:

    • API_VERSION: la versione dell'API, v1 o v1beta1. Per la versione GKE 1.31.1-gke.1678000 e quelle successive, consigliamo di utilizzare v1 per la stabilità e l'accesso alle funzionalità più recenti.
    • NAMESPACE_NAME: il nome dello spazio dei nomi Kubernetes. Lo spazio dei nomi deve essere lo stesso dello spazio dei nomi dei pod.
    • PROVISIONING_REQUEST_NAME: il nome del ProvisioningRequest. Farai riferimento a questo nome nell'annotazione del pod.
    • MAX_RUN_DURATION_SECONDS: facoltativo, il tempo di esecuzione massimo di un nodo in secondi, fino al valore predefinito di sette giorni. Per scoprire di più, consulta Come funziona il provisioning in coda con inizio flessibile. Non puoi modificare questo valore dopo la creazione della richiesta. Questo campo è disponibile in GKE versione 1.28.5-gke.1355000 o successive.
    • COUNT: numero di pod richiesti. I nodi vengono pianificati in modo atomico in una zona.
    • POD_TEMPLATE_NAME: il nome del PodTemplate.
    • GPU_TYPE: il tipo di hardware della GPU.

    GKE potrebbe applicare convalide e mutazioni ai pod durante la loro creazione. L'etichetta cloud.google.com/apply-warden-policies consente a GKE di applicare le stesse convalide e mutazioni agli oggetti PodTemplate. Questa etichetta è necessaria per consentire a GKE di calcolare i requisiti delle risorse dei nodi per i pod.

  2. Applica il manifest:

    kubectl apply -f provisioning-request.yaml

Configura i pod

Questa sezione utilizza Kubernetes Jobs per configurare i pod. Tuttavia, puoi anche utilizzare un JobSet Kubernetes o qualsiasi altro framework come Kubeflow, Ray o controller personalizzati. Nella specifica del job, collega i pod a ProvisioningRequest utilizzando le seguenti annotazioni:

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

Prima della versione GKE 1.30.3-gke.1854000, devi utilizzare le seguenti annotazioni legacy:

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

Tieni presente che, a partire dalla versione GKE 1.31.1-gke.1678000, le annotazioni cluster-autoscaler.kubernetes.io/consume-provisioning-request e cluster-autoscaler.kubernetes.io/provisioning-class-name sono ritirate.

La chiave di annotazione del pod consume-provisioning-request definisce quale ProvisioningRequest consumare. GKE utilizza le annotazioni consume-provisioning-request e provisioning-class-name per eseguire quanto segue:

  • Per pianificare i pod solo nei nodi di cui è stato eseguito il provisioning con avvio flessibile con provisioning in coda.
  • Per evitare il conteggio doppio delle richieste di risorse tra i pod e il provisioning in coda con inizio flessibile nel gestore della scalabilità automatica del cluster.
  • Per iniettare l'annotazione safe-to-evict: false, per impedire al gestore della scalabilità automatica del cluster di spostare i pod tra i nodi e interrompere i calcoli batch. Puoi modificare questo comportamento specificando safe-to-evict: true nelle annotazione del podcast.

Controllare lo stato di una richiesta di provisioning

Lo stato di una richiesta di provisioning definisce se un pod può essere pianificato o meno. Puoi utilizzare Kubernetes Watches per osservare le modifiche in modo efficiente o altri strumenti che utilizzi già per monitorare gli stati degli oggetti Kubernetes. La tabella seguente descrive il possibile stato di una richiesta di provisioning e ogni possibile esito:

Stato della richiesta di provisioning Descrizione Possibile esito
In attesa La richiesta non è stata ancora visualizzata ed elaborata. Dopo l'elaborazione, la richiesta passa allo stato Accepted o Failed.
Accepted=true La richiesta è accettata e attende che le risorse siano disponibili. La richiesta deve passare allo stato Provisioned se sono state trovate risorse e sono stati eseguiti il provisioning dei nodi oppure allo stato Failed se non è stato possibile.
Provisioned=true I nodi sono pronti. Hai 10 minuti di tempo per avviare i pod in modo da consumare le risorse di cui è stato eseguito il provisioning. Dopo questo periodo di tempo, il gestore della scalabilità automatica del cluster considera i nodi come non necessari e li rimuove.
Failed=true Non è possibile eseguire il provisioning dei nodi a causa di errori. Failed=true è uno stato terminale. Risolvi i problemi relativi alla condizione in base alle informazioni nei campi Reason e Message della condizione. Crea e riprova una nuova richiesta di provisioning.
Provisioned=false Il provisioning dei nodi non è ancora stato eseguito.

Se Reason=NotProvisioned, si tratta di uno stato temporaneo prima che tutte le risorse siano disponibili.

Se Reason=QuotaExceeded, risolvi il problema della condizione in base a questo motivo e alle informazioni nel campo Message della condizione. Potresti dover richiedere una quota maggiore. Per maggiori dettagli, consulta la sezione Verificare se la richiesta di provisioning è limitata dalla quota. Questo Reason è disponibile solo con GKE 1.29.2-gke.1181000 o versioni successive.

Se Reason=ResourcePoolExhausted e Message contengono Expected time is indefinite, seleziona una zona o una regione diversa oppure modifica le risorse richieste.

Avvia i pod

Quando la richiesta di provisioning raggiunge lo stato Provisioned=true, puoi eseguire il tuo job per avviare i pod. In questo modo si evita la proliferazione di pod non pianificabili per richieste in attesa o non riuscite, che possono influire sul rendimento di kube-scheduler e del gestore della scalabilità automatica dei cluster.

In alternativa, se non ti interessa avere pod non pianificabili, puoi creare i pod in parallelo con la richiesta di provisioning.

Annullare la richiesta di Provisioning Request

Per annullare la richiesta prima del provisioning, puoi eliminare ProvisioningRequest:

kubectl delete provreq PROVISIONING_REQUEST_NAME -n NAMESPACE

Nella maggior parte dei casi, l'eliminazione di ProvisioningRequest impedisce la creazione di nodi. Tuttavia, a seconda dei tempi, ad esempio se il provisioning dei nodi è già in corso, i nodi potrebbero comunque essere creati. In questi casi, il gestore della scalabilità automatica del cluster rimuove i nodi dopo 10 minuti se non vengono creati pod.

Risolvere i problemi relativi alle quote

Tutte le VM di cui viene eseguito il provisioning tramite le richieste di provisioning utilizzano quote preassegnate.

Il numero di ProvisioningRequests in stato Accepted è limitato da una quota dedicata. Configura la quota per ogni progetto, una configurazione della quota per regione.

Controllare la quota nella Google Cloud console

Per controllare il nome del limite di quota e l'utilizzo corrente nella Google Cloud console, segui questi passaggi:

  1. Vai alla pagina Quote nella Google Cloud console:

    Vai a Quote

  2. Nella casella Filtro, seleziona la proprietà Metrica, inserisci active_resize_requests e premi Invio.

Il valore predefinito è 100. Per aumentare la quota, segui i passaggi elencati in Richiedere un aggiustamento della quota.

Verificare se la richiesta di provisioning è limitata dalla quota

Se la richiesta di provisioning richiede più tempo del previsto per essere completata, controlla che la richiesta non sia limitata dalla quota. Potresti dover richiedere un aumento della quota.

Per i cluster che eseguono la versione 1.29.2-gke.1181000 o successive, controlla se limitazioni specifiche delle quote impediscono l'accettazione della tua richiesta:

kubectl describe provreq PROVISIONING_REQUEST_NAME \
    --namespace NAMESPACE

L'output è simile al seguente:

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

In questo esempio, GKE non può eseguire il deployment dei nodi perché la quota nella regione europe-west4 non è sufficiente.

Esegui la migrazione dei pool di nodi dal provisioning in coda alla modalità di provisioning con avvio flessibile

Per i pool di nodi esistenti creati utilizzando il flag --enable-queued-provisioning, esegui il seguente comando per eseguirne la migrazione alla nuova modalità di provisioning flex-start:

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

Questa operazione esegue quanto segue:

  • Aggiorna il node pool a un node pool con modalità di provisioning con avvio flessibile.
  • Applica i prezzi dei nodi con modalità di provisioning con avvio flessibile.

Tutti i nodi dei cluster in esecuzione su 1.32.2-gke.1652000 o versioni successive, la versione minima per i nodi in modalità di provisioning flex-start, utilizzano gli upgrade di breve durata.

Passaggi successivi