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 batch su larga scala e carichi di lavoro AI con GPU utilizzando l'avvio flessibile con provisioning in coda basato su Dynamic Workload Scheduler.

Prima di leggere questa pagina, assicurati di avere familiarità con quanto segue:

Questa guida è destinata a ingegneri di machine learning (ML), amministratori e operatori di piattaforme e a specialisti di dati e AI interessati a utilizzare le funzionalità di orchestrazione dei container Kubernetes per l'esecuzione di batch workload. Per maggiori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Trusted Cloud by S3NS , consulta Ruoli utente e attività comuni di GKE Enterprise.

Come funziona l'avvio flessibile con 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 carichi di lavoro batch e AI su larga scala quando i tuoi carichi di lavoro soddisfano i seguenti criteri:

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

Per i workload più piccoli che possono essere eseguiti su un singolo nodo, utilizza flex-start. Per ulteriori informazioni sul provisioning delle GPU in GKE, consulta Ottenere acceleratori per i carichi di lavoro 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à, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

Utilizzare i node pool 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 provisioning in coda può funzionare con pool di nodi specifici nel 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 che scegli per il pool di nodi.
  • 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 pool di nodi.
  • DRIVER_VERSION: la versione del driver NVIDIA da installare. Può corrispondere a uno dei seguenti:
    • default: installa la versione del driver predefinita per la tua versione di GKE.
    • latest: installa l'ultima versione del driver disponibile per la tua versione di GKE. Disponibile solo per i nodi che utilizzano Container-Optimized OS.
  • TOTAL_MAX_NODES: il numero massimo di nodi da scalare automaticamente per l'interopool di nodil.

  • 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 dei 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 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 indica a GKE di creare unpool di nodil con avvio flessibile con provisioning in coda attivato e di aggiungere il taint cloud.google.com/gke-queued apool di nodiol.
  • GKE consente il provisioning in coda e la scalabilità automatica del cluster.
  • Inizialmente il pool di nodi non contiene nodi.
  • Il flag --no-enable-autorepair disattiva le riparazioni automatiche, il che potrebbe interrompere i carichi di lavoro eseguiti sui nodi riparati.

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

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

Per abilitare il provisioning automatico dei nodi, considera le seguenti impostazioni e completa i passaggi descritti in Configurare i limiti delle GPU:

  • Specifica le risorse richieste 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 di cui è stato eseguito il provisioning automatico. Per saperne di più, vedi Installazione dei driver utilizzando il provisioning automatico dei nodi con le GPU.

Esegui i tuoi carichi di lavoro batch e di AI con l'avvio flessibile con provisioning in coda

Per eseguire carichi di lavoro batch con l'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 gestione delle code dei job e osserva lo stato dell'avvio flessibile con provisioning in coda. Kueue decide quando i job devono attendere e quando devono iniziare, in base a quote e a una gerarchia per la condivisione equa delle 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 quando utilizzi la tua piattaforma o i tuoi strumenti di pianificazione batch interni. Crei e annulli manualmente la richiesta di provisioning.

Best practice:

Utilizza Kueue per eseguire i carichi di lavoro batch e AI con avvio flessibile e 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:

  • Configurazione del pool di nodi con avvio flessibile e provisioning in coda.
  • Configurazione del pool di nodi con prenotazione e avvio flessibile con 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 con licenza Apache 2.

Per installare Kueue devi disporre delle autorizzazioni di amministratore. Per ottenerli, assicurati di avere il 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 l'ultima versione di Kueue nel tuo cluster:

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

    Sostituisci KUEUE_VERSION con l'ultima versione di Kueue.

Se utilizzi Kueue in una versione precedente alla 0.7.0, modifica la configurazione del feature gate di Kueue impostando il feature gate ProvisioningACC su true. Per una spiegazione più dettagliata e per i valori predefiniti dei gate, consulta Feature gate di Kueue. Per saperne di più 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"
---
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
---

La coda di questo cluster ha limiti di quota elevati ed è abilitata solo l'integrazione dell'avvio flessibile con provisioning in coda. 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 ulteriori LocalQueues utilizzando il modello precedente.

Esegui il job

Nel seguente manifest, 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 di avvio flessibile con provisioning in coda:

  • L'etichetta kueue.x-k8s.io/queue-name: dws-local-queue indica a GKE che Kueue è responsabile dell'orchestrazione di questo job. Questa etichetta definisce anche la coda in cui viene messo in coda il job.
  • Il flag suspend: true indica a GKE di creare la risorsa Job ma di non pianificare ancora i pod. Kueue cambia questo flag in false quando i nodi sono pronti per l'esecuzione del job.
  • nodeSelector indica a GKE di pianificare il job solo sul 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 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

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

  • RayJob
  • JobSet v0.5.2 o versioni successive
  • Kubeflow MPIJob, TFJob, PyTorchJob.
  • Pod Kubernetes utilizzati di frequente dagli orchestratori di flussi di lavoro
  • Mini cluster Flux

Per saperne di più su questo supporto, vedi Utente batch di Kueue.

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

Con il seguente manifest, crei due ResourceFlavors collegati a due node pool diversi: reservation-nodepool e dws-nodepool. I nomi di questi pool di nodi sono solo nomi esemplificativi. Modifica questi nomi in base alla configurazione del pool di nodi. Inoltre, con la configurazione ClusterQueue, i job in entrata tentano di utilizzare reservation-nodepool e, se non è disponibile 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 dell'avvio flessibile con provisioning in coda. Per ulteriori informazioni sulle API Kueue e su come impostare i limiti, consulta Concetti di Kueue.

Esegui il deployment del manifest utilizzando questo 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

Contrariamente alla configurazione precedente, questo manifest non include il campo nodeSelector perché viene compilato da Kueue, a seconda della capacità libera in 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 saperne di più 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 Kueue

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 GKE versione 1.31.1-gke.1678000 e successive, ti consigliamo di utilizzare v1 per stabilità e accesso alle funzionalità più recenti.
    • NAMESPACE_NAME: il nome dello spazio dei nomi Kubernetes. Lo spazio dei nomi deve essere lo stesso dei pod.
    • PROVISIONING_REQUEST_NAME: il nome di ProvisioningRequest. Farai riferimento a questo nome nell'annotazione del pod.
    • MAX_RUN_DURATION_SECONDS: facoltativamente, la durata massima di un nodo in secondi, fino al valore predefinito di sette giorni. Per scoprire di più, consulta l'articolo Come funziona l'avvio flessibile con il provisioning in coda. 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 di PodTemplate.
    • NODEPOOL_NAME: il nome che scegli per il pool di nodi. Rimuovi se vuoi utilizzare un pool di nodi di cui è stato eseguito il 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 tuoi pod. L'integrazione dell'avvio flessibile con il provisioning in coda supporta una sola specifica PodSet. Se vuoi combinare modelli di pod diversi, utilizza il modello che richiede più risorse. Non è supportato l'utilizzo di tipi di macchine diversi, ad esempio VM con tipi di GPU diversi.

    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 GKE versione 1.31.1-gke.1678000 e successive, ti consigliamo di utilizzare v1 per stabilità e accesso alle funzionalità più recenti.
    • NAMESPACE_NAME: il nome dello spazio dei nomi Kubernetes. Lo spazio dei nomi deve essere lo stesso dei pod.
    • PROVISIONING_REQUEST_NAME: il nome di ProvisioningRequest. Farai riferimento a questo nome nell'annotazione del pod.
    • MAX_RUN_DURATION_SECONDS: facoltativamente, la durata massima di un nodo in secondi, fino al valore predefinito di sette giorni. Per scoprire di più, consulta l'articolo Come funziona l'avvio flessibile con il provisioning in coda. 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 di PodTemplate.
    • GPU_TYPE: il tipo di hardware 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 tuoi pod.

  2. Applica il manifest:

    kubectl apply -f provisioning-request.yaml

Configura i pod

Questa sezione utilizza i job Kubernetes per configurare i pod. Tuttavia, puoi anche utilizzare un JobSet Kubernetes o qualsiasi altro framework come Kubeflow, Ray o controller personalizzati. Nella specifica 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 1.30.3-gke.1854000 di GKE, 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 1.31.1-gke.1678000 di GKE 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 utilizzare. GKE utilizza le annotazioni consume-provisioning-request e provisioning-class-name per eseguire le seguenti operazioni:

  • Per pianificare i pod solo nei nodi di cui è stato eseguito il provisioning con avvio flessibile con provisioning in coda.
  • Per evitare il doppio conteggio delle richieste di risorse tra i pod e l'avvio flessibile con il provisioning in coda nel gestore della scalabilità automatica del cluster.
  • Per inserire 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 annotazioni del pod.

Osservare 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 le osservazioni di Kubernetes per osservare le modifiche in modo efficiente o altri strumenti che utilizzi già per monitorare gli stati degli oggetti Kubernetes. La tabella seguente descrive i possibili stati di una richiesta di provisioning e ciascun risultato possibile:

Stato della richiesta di provisioning Descrizione Possibile risultato
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 ed è in attesa della disponibilità delle risorse. La richiesta deve passare allo stato Provisioned se sono state trovate risorse e sono stati forniti nodi o allo stato Failed se non è stato possibile.
Provisioned=true I nodi sono pronti. Hai 10 minuti di tempo per avviare i pod per utilizzare le risorse di cui è stato eseguito il provisioning. Trascorso questo periodo di tempo, il gestore della scalabilità automatica del cluster considera i nodi non necessari e li rimuove.
Failed=true Impossibile 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 I nodi non sono ancora stati sottoposti al provisioning.

Se Reason=NotProvisioned, questo è uno stato temporaneo prima che tutte le risorse siano disponibili.

Se Reason=QuotaExceeded, risolvi il problema relativo alla condizione in base a questo motivo e alle informazioni nel campo Message della condizione. Potresti dover richiedere una quota maggiore. Per ulteriori dettagli, consulta la sezione Verifica 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 contiene Expected time is indefinite, seleziona una zona o una regione diversa oppure modifica le risorse richieste.

Avviare i pod

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

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

Annullare la richiesta di provisioning

Per annullare la richiesta prima che venga eseguita, 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 i nodi erano già in fase di provisioning, 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 alla quota

Tutte le VM sottoposte a provisioning dalle richieste di provisioning utilizzano quote preemptible.

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

Controlla la quota nella console Trusted Cloud

Per controllare il nome del limite di quota e l'utilizzo attuale nella consoleTrusted Cloud , segui questi passaggi:

  1. Vai alla pagina Quote nella console Trusted Cloud :

    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 Richiedi un aggiustamento delle quote.

Controlla se la richiesta di provisioning è limitata dalla quota

Se l'elaborazione della richiesta di provisioning richiede più tempo del previsto, verifica che la richiesta non sia limitata dalla quota. Potresti dover richiedere una quota maggiore.

Per i cluster che eseguono la versione 1.29.2-gke.1181000 o successive, controlla se limitazioni di quota specifiche impediscono l'evasione della 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é non è disponibile una quota sufficiente nella regione europe-west4.

Esegui la migrazione dei node pool dal provisioning in coda all'avvio flessibile

Per i node pool esistenti creati utilizzando il flag --enable-queued-provisioning, esegui questo comando per eseguire la migrazione di questi node pool al nuovo flex-start:

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

Questa operazione esegue le seguenti operazioni:

  • Aggiorna il pool di nodi a un pool di nodi flex-start.
  • Applica i prezzi dei nodi 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 flex-start, utilizzano upgrade di breve durata.

Passaggi successivi