Esegui il deployment di GPU per i carichi di lavoro batch con Dynamic Workload Scheduler

Questa pagina mostra come ottimizzare l'ottenibilità delle GPU per i carichi di lavoro batch su larga scala con GPU utilizzando Dynamic Workload Scheduler e ProvisioningRequest.

Consigliamo Dynamic Workload Scheduler per i carichi di lavoro batch su larga scala che possono essere eseguiti non nelle ore di punta con condizioni di gestione della capacità della GPU definite. Questi carichi di lavoro come l'addestramento del modello di deep learning o una simulazione che richiede grandi quantità di GPU con un modello di provisioning atomico, il che significa che tutte le risorse vengono creati contemporaneamente.

Per eseguire carichi di lavoro GPU in Google Kubernetes Engine (GKE) senza Dynamic Workload Scheduler, consulta Esegui GPU in pool di nodi GKE Standard.

Quando utilizzare Dynamic Workload Scheduler

Ti consigliamo di utilizzare Dynamic Workload Scheduler se i carichi di lavoro soddisfano tutte le le seguenti condizioni:

  • Le GPU devono essere richieste per eseguire i carichi di lavoro.
  • Hai limitato o nessun GPU prenotata e vuoi migliorare la ottenimento delle risorse GPU.
  • Il tuo carico di lavoro è flessibile in termini di tempo e il tuo caso d'uso può permettersi di attendere per ottenere tutta la capacità richiesta, ad esempio quando GKE alloca le risorse GPU al di fuori delle ore di punta.
  • Il carico di lavoro richiede più nodi e non può essere eseguito finché non viene eseguito il provisioning di tutti i nodi GPU e sono pronti contemporaneamente (ad esempio, per l'addestramento distribuito di machine learning).

Prima di iniziare

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

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

Usa i pool di nodi con Dynamic Workload Scheduler

Puoi utilizzare uno qualsiasi dei tre metodi seguenti per designare Lo scheduler dinamico dei carichi di lavoro può funzionare con pool di nodi specifici nel tuo cluster:

Crea un pool di nodi

Crea un pool di nodi con Dynamic Workload Scheduler abilitato utilizzando il comando 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 \
    --machine-type=MACHINE_TYPE \
    --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 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 in pool di nodi.
  • DRIVER_VERSION: la versione del driver NVIDIA da installare. Può essere uno dei seguenti:
    • default: installa la versione predefinita del driver per la tua versione GKE.
    • latest: installa la versione del driver più recente disponibile per il tuo 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. Ti consigliamo di selezionare un tipo di macchina ottimizzato per l'acceleratore.

Se vuoi, puoi utilizzare i seguenti flag:

  • --no-enable-autoupgrade: consigliato. Disattiva gli upgrade automatici dei nodi. Supportato solo nei cluster GKE non registrati in un canale di rilascio. Per scoprire di più, consulta Disattivare gli upgrade automatici dei nodi per un pool di nodi esistente.
  • --node-locations=COMPUTE_ZONES: l'elenco separato da virgole di una o più zone in cui GKE crea i nodi GPU. La devono trovarsi nella stessa regione del cluster. Scegli le zone con GPU disponibili.
  • --enable-gvnic: questo flag consente a gVNIC sui pool di nodi GPU di aumentare la velocità del traffico di rete.

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

  • GKE consente il provisioning in coda e la scalabilità automatica dei cluster.
  • Il pool di nodi inizialmente ha zero nodi.
  • Il flag --enable-queued-provisioning attiva Dynamic Workload Scheduler e aggiunge il taint cloud.google.com/gke-queued al pool di nodi.
  • I flag --no-enable-autorepair e --no-enable-autoupgrade sono disattivati la riparazione e l'upgrade automatici dei nodi, il che potrebbe interrompere i carichi di lavoro in esecuzione sui nodi riparati o con upgrade eseguito. Puoi disabilitare solo l'upgrade automatico dei nodi sui cluster che non sono registrati in un canale di rilascio.

Aggiorna il pool di nodi esistente e abilita Dynamic Workload Scheduler

Abilita Dynamic Workload Scheduler per un pool di nodi esistente. Esamina i prerequisiti per configurare correttamente il pool di nodi.

Prerequisiti

  • Assicurati di creare un pool di nodi con --reservation-affinity=none flag. Questo flag è obbligatorio per abilitare Dynamic Workload Scheduler in un secondo momento, non puoi modificare l'affinità di prenotazione dopo la creazione del pool di nodi.

  • Assicurati di mantenere almeno un pool di nodi senza il trattamento di Dynamic Workload Scheduler attivo per il corretto funzionamento del cluster.

  • Assicurati che il pool di nodi sia vuoto. Puoi ridimensionare il pool di nodi in modo che non abbia nodi.

  • Assicurati che la scalabilità automatica sia abilitata e configurata correttamente.

  • Assicurati che le riparazioni automatiche siano disattivate.

Abilita Dynamic Workload Scheduler per il pool di nodi esistente

Puoi abilitare Dynamic Workload Scheduler per un pool di nodi esistente utilizzando gcloud CLI:

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

Sostituisci quanto segue:

  • NODEPOOL_NAME: nome del pool di nodi scelto.
  • CLUSTER_NAME: nome del cluster.
  • LOCATION: la regione Compute Engine del cluster, ad esempio us-central1.

Questo comando di aggiornamento del pool di nodi determina le seguenti modifiche alla configurazione:

  • Il flag --enable-queued-provisioning abilita Dynamic Workload Scheduler e aggiunge l'incompatibilità cloud.google.com/gke-queued rispetto al pool di nodi.

Se vuoi, puoi anche aggiornare le seguenti impostazioni del pool di nodi:

  • Disattiva gli upgrade automatici dei nodi: consigliamo di disattivare gli upgrade automatici dei nodi poiché gli upgrade dei pool di nodi non sono supportati quando si utilizza il pianificatore dei carichi di lavoro dinamico. Per disattivare gli upgrade automatici dei nodi, assicurati che il cluster GKE non sia registrato in un canale di rilascio.
  • Attiva gVNIC sui pool di nodi GPU: la scheda NIC virtuale di Google (gVNIC) aumenta la velocità del traffico di rete per i nodi GPU.

Abilita il provisioning automatico dei nodi per creare pool di nodi per Dynamic Workload Scheduler

Puoi utilizzare il provisioning automatico dei nodi per gestire i pool di nodi per Dynamic Workload Scheduler per i cluster che eseguono la versione 1.29.2-gke.1553000 o successive. Quando abiliti il nodo il provisioning automatico e l'abilitazione del programma di pianificazione dei carichi di lavoro dinamici, GKE crea pool di nodi con le risorse richieste per il carico di lavoro associato.

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

Esegui i carichi di lavoro batch con Dynamic Workload Scheduler

Per usare Dynamic Workload Scheduler, ti consigliamo di usare Cuore. Kueue implementa l'accodamento dei job, decidendo quando i job devono attendere e quando devono avviarsi, in base alle quote e per condividere le risorse in modo equo tra i team. Ciò semplifica la configurazione necessarie per utilizzare le VM in coda.

Puoi utilizzare Dynamic Workload Scheduler senza Kueue quando usi i tuoi server strumenti o piattaforma di pianificazione batch. Per configurare Dynamic Workload Scheduler per i job senza Kueue, consulta Dynamic Workload Scheduler per i job senza Kueue.

Dynamic Workload Scheduler per i job con Kueue

Le sezioni seguenti mostrano come configurare il Dynamic Workload Scheduler per Offerte di lavoro con Kueue. Puoi configurare le seguenti configurazioni comuni del pool di nodi:

  • Configurazione del pool di nodi dello strumento di pianificazione dei carichi di lavoro dinamici.
  • Configurazione del pool di nodi di prenotazione e Dynamic Workload Scheduler.

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

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=v0.7.0
kubectl apply --server-side -f https://github.com/kubernetes-sigs/kueue/releases/download/$VERSION/manifests.yaml

Per scoprire di più sull'installazione di Kueue, consulta Installazione.

Crea le risorse Kueue solo per la configurazione del pool di nodi dello strumento di pianificazione dei carichi di lavoro dinamici

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 Dynamic Workload Scheduler 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"]
    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"
---

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 Dynamic Workload Scheduler in altri spazi dei nomi, puoi creare altri LocalQueues utilizzando il modello precedente.

Esegui il job

Nel manifest seguente, il job di esempio utilizza Dynamic Workload Scheduler:

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

Questo manifest include i seguenti campi pertinenti per la configurazione di Dynamic Workload Scheduler:

  • L'etichetta kueue.x-k8s.io/queue-name: dws-local-queue indica a GKE che Kueue è responsabile dell'orchestrazione del job. Questo l'etichetta definisce anche la coda in cui il job è in coda.
  • 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

Dynamic Workload Scheduler con 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 del flusso di lavoro
  • Mini cluster di flusso

Per scoprire di più su questo tipo di assistenza, vedi Utente batch di Kueue.

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

Con il manifest seguente, crei due ResourceFlavors associati a due diversi pool di nodi: reservation-nodepool e dws-nodepool. I nomi di questi pool di nodi sono solo nomi esemplari. 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 lo scheduler dei carichi di lavoro dinamico 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: 10000   # Infinite quota.
      - name: "memory"
        nominalQuota: 10000Gi # Infinite quota.
      - name: "nvidia.com/gpu"
        nominalQuota: 10000   # Infinite quota.
  admissionChecksStrategy:
    admissionChecks:
      - name: "dws-prov"
        onFlavors: [dws]
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  namespace: "default"
  name: "user-queue"
spec:
  clusterQueue: "cluster-queue"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
  name: dws-prov
spec:
  controllerName: kueue.x-k8s.io/provisioning-request
  parameters:
    apiGroup: kueue.x-k8s.io
    kind: ProvisioningRequestConfig
    name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
  name: dws-config
spec:
  provisioningClassName: queued-provisioning.gke.io
  managedResources:
  - nvidia.com/gpu

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

Contrariamente alla configurazione precedente, questo manifest non include il campo nodeSelector, poiché viene compilato da Kueue, a seconda della capacità gratuita 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 scoprire quale pool di nodi utilizza il tuo job, devi sapere quale ResourceFlavor utilizza il tuo job.

Risoluzione dei problemi

Per scoprire di più sulla risoluzione dei problemi di Kueue, vedi Risoluzione dei problemi relativi alla richiesta di provisioning in Kueue

Dynamic Workload Scheduler per i job senza coda

Crea una richiesta tramite l'API ProvisioningRequest per ogni job. Dynamic Workload Scheduler non avvia i pod, ma esegue solo il provisioning dei nodi.

  1. Crea il seguente manifest 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
    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

    Sostituisci quanto segue:

    • NAMESPACE_NAME: il nome dello spazio dei nomi Kubernetes. Lo spazio dei nomi deve essere uguale a quello 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 apprendere vedi Come funziona Dynamic Workload Scheduler. Non puoi modificare questo valore dopo la creazione della richiesta. Questo campo è disponibile in Anteprima nella versione GKE 1.28.5-gke.1355000 o versioni successive.
    • COUNT: numero di pod richiesti. I nodi sono pianificati atomicamente in una zona.
    • POD_TEMPLATE_NAME: un'infrastruttura il nome standard. GKE fa riferimento a questo valore nel PodSet della richiesta di provisioning.
    • NODEPOOL_NAME: il nome che scegli per il pool di nodi.

  1. Applica il manifest:

    kubectl apply -f provisioning-request.yaml

Configura i pod

Nella specifica Job, collega i pod a ProvisioningRequest utilizzando le seguenti annotazioni:

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

Chiave di annotazione dei pod cluster-autoscaler.kubernetes.io/consume-provisioning-request stabilisce quale ProvisioningRequest da utilizzare. 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 da Dynamic Workload Scheduler.
  • Per evitare il conteggio doppio delle richieste di risorse tra i pod e lo scheduler dei carichi di lavoro dinamici nel gestore della scalabilità automatica dei 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.

Osserva lo stato del Dynamic Workload Scheduler

Lo stato di un Dynamic Workload Scheduler definisce se un pod può essere pianificato o meno. Puoi utilizzare Smartwatch Kubernetes per osservare le modifiche in modo efficiente o altri strumenti che già utilizzi per il monitoraggio degli oggetti Kubernetes. Nella tabella seguente viene descritto il possibile stato uno scheduler di carichi di lavoro dinamici e ogni possibile risultato:

Stato di Dynamic Workload Scheduler 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 è stata accettata ed è in attesa di risorse disponibili. La richiesta deve passare allo stato Provisioned, se le risorse sono state ed è stato eseguito il provisioning dei nodi oppure nello stato Failed se non era 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. Dopodiché, il gestore della scalabilità automatica dei cluster considera i nodi come necessari e li rimuove.
Failed=true Non è possibile eseguire il provisioning dei nodi a causa di errori. Failed=true è uno stato terminale. Risolvere i problemi la condizione in base alle informazioni contenute in Reason e Message campi della condizione. Crea e riprova una nuova richiesta di Dynamic Workload Scheduler.
Provisioned=false Non è stato ancora eseguito il provisioning dei nodi.

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 Controllare se Dynamic Workload Scheduler è limitato dalla quota . Questo Reason è disponibile solo con GKE versione 1.29.2-gke.1181000 o successive.

Avvia i pod

Quando la richiesta dello strumento di pianificazione dei carichi di lavoro dinamici raggiunge lo stato Provisioned=true, puoi eseguire il job per avviare i pod. Ciò evita la proliferazione dei pod non pianificabili per i pod in attesa o non riuscite, il che può influire kube-scheduler e del cluster per le prestazioni del gestore della scalabilità automatica.

In alternativa, se non ti interessa avere pod non pianificabili, creare pod in parallelo con Dynamic Workload Scheduler.

Annullare la richiesta di Dynamic Workload Scheduler

Per annullare la richiesta prima che ne venga eseguito il 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 delle tempistiche, ad esempio se i nodi erano già di cui viene eseguito il provisioning, 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.

Come funziona Dynamic Workload Scheduler

Con ProvisioningRequest API, Dynamic Workload Scheduler esegue le seguenti operazioni:

  1. Devi dire a GKE che il carico di lavoro può attendere, indeterminato, finché tutti i nodi richiesti non saranno pronti per l'uso contemporaneamente.
  2. Il gestore della scalabilità automatica dei cluster accetta la richiesta e calcola il numero nodi necessari, trattandoli come una singola unità.
  3. La richiesta attende che tutte le risorse necessarie siano disponibili in una singola zona. Per i cluster che eseguono la versione 1.29.1-gke.1708000 e versioni successive, questa zona viene scelta utilizzando informazioni sulla capacità disponibile per garantire tempi di attesa più bassi. Per che eseguono versioni precedenti, la zona è stata scelta senza informazioni, il che può comportare la coda nelle zone in cui i tempi di attesa molto più a lungo.
  4. Il gestore della scalabilità automatica del cluster esegue il provisioning dei nodi necessari, se disponibili, contemporaneamente.
  5. Tutti i pod del carico di lavoro possono essere eseguiti insieme sui nodi appena provisionati.
  6. I nodi di cui è stato eseguito il provisioning sono limitati a sette giorni di runtime o prima, se imposti il parametro maxRunDurationSeconds su indicano che i carichi di lavoro richiedono meno tempo per l'esecuzione. Per scoprire di più, consulta Limitare il tempo di esecuzione di una VM (anteprima). Questa funzionalità è disponibile con GKE 1.28.5-gke.1355000 o versioni successive. Dopo questo periodo, i nodi e i pod in esecuzione vengono prenotati. Se i pod terminano prima e i nodi non vengono utilizzati, l'autoscaler del cluster li rimuove in base al profilo di scalabilità automatica.
  7. I nodi non vengono riutilizzati nel Dynamic Workload Scheduler. Ogni ProvisioningRequest ordina la creazione di nuovi nodi con il nuovo tempo di esecuzione di sette giorni.

Quota

Tutte le VM di cui è stato eseguito il provisioning dalle richieste dello strumento di pianificazione dei carichi di lavoro dinamici utilizzano quote prerilasciabili.

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

Controlla la quota nella console Google Cloud

Per verificare il nome del limite della quota e l'utilizzo attuale nella nella console Google Cloud, segui questi passaggi:

  1. Vai alla pagina Quote nella console Google 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 descritti nella guida per richiedere un limite di quota più alto.

Verificare se Dynamic Workload Scheduler è limitato dalla quota

Se la richiesta di pianificatore dei carichi di lavoro dinamici richiede più tempo del previsto per essere soddisfatta, verifica che la richiesta non sia limitata dalla quota. Potresti dover e richiedere una quota maggiore.

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.

Configurare le impostazioni di interruzione per i pool di nodi con carichi di lavoro che utilizzano Dynamic Workload Scheduler

Carichi di lavoro che richiedono la disponibilità di tutti i nodi, o della maggior parte dei nodi, in un pool di nodi sensibili agli espulsioni. È stato eseguito il provisioning della riparazione o dell'upgrade automatico di un nodo l'utilizzo di ProvisioningRequest API non è supportato perché queste operazioni rimuovono tutti i carichi di lavoro in esecuzione su quel nodo e rende i carichi di lavoro non pianificabili.

Per ridurre al minimo le interruzioni dei carichi di lavoro in esecuzione utilizzando Dynamic Workload Scheduler, consigliamo di adottare le seguenti misure:

  • A seconda della registrazione al canale di rilascio del tuo cluster, segui le best practice riportate di seguito per evitare che gli upgrade automatici dei nodi interrompano i tuoi carichi di lavoro:
  • Disabilita nodo riparazione automatica.
  • Utilizza i periodi di manutenzione ed esclusioni per ridurre al minimo le interruzioni dei carichi di lavoro in esecuzione, garantendo al contempo che sia presente un periodo di tempo in cui GKE può interrompere il pool di nodi per la manutenzione automatica. Se utilizzi questi strumenti di manutenzione, devi impostare un periodo di tempo specifico in cui GKE può interrompere il pool di nodi, quindi ti consigliamo di impostare questo periodo di tempo quando non sono in esecuzione carichi di lavoro.
  • Per assicurarti che il pool di nodi sia sempre aggiornato, ti consigliamo di eseguire l'upgrade manuale del nodo pool quando non ci sono richieste attive dello strumento di pianificazione dei carichi di lavoro dinamici e il pool di nodi è vuoto.

Limitazioni

  • Anti-affinità tra i pod non è supportato. Il gestore della scalabilità automatica dei cluster non considera le regole di anti-affinità tra i pod durante il provisioning dei nodi, il che potrebbe portare a carichi di lavoro non pianificabili. Ciò può accadere quando è stato eseguito il provisioning dei nodi per due o più oggetti Dynamic Workload Scheduler nello stesso pool di nodi.
  • Sono supportati solo i nodi GPU.
  • Le prenotazioni non sono supportate con Dynamic Workload Scheduler. Devi specificare --reservation-affinity=none durante la creazione del pool di nodi. Dynamic Workload Scheduler richiede e supporta solo il ANYcriterio della località per la scalabilità automatica del cluster.
  • Una singola richiesta dello strumento di pianificazione dei carichi di lavoro dinamici può creare fino a 1000 VM, ovvero il numero massimo di nodi per zona per un singolo pool di nodi.
  • GKE usa la quota ACTIVE_RESIZE_REQUESTS di Compute Engine per controlla il numero di richieste di Dynamic Workload Scheduler in attesa in una coda. Per impostazione predefinita, questa quota ha un limite di 100 a livello di progetto Google Cloud. Se tenti di creare un Richiesta di Dynamic Workload Scheduler superiore a questa quota, la nuova richiesta non va a buon fine.
  • I pool di nodi che utilizzano Dynamic Workload Scheduler sono sensibili alle interruzioni perché i nodi il provisioning viene eseguito contemporaneamente. Per scoprire di più, consulta Configurare le impostazioni di interruzione per i pool di nodi con carichi di lavoro che utilizzano Dynamic Workload Scheduler.
  • Potresti vedere altre VM a breve durata elencate nella console Google Cloud. Questo comportamento è previsto perché Compute Engine potrebbe creare e rimuovere tempestivamente le VM finché non sarà disponibile la capacità di eseguire il provisioning di tutte le macchine richieste.
  • L'integrazione dello strumento di pianificazione dei carichi di lavoro dinamici supporta un solo PodSet. Se vuoi combinare diversi modelli di pod, e usare quello con la maggior parte delle risorse richieste. La combinazione di tipi di macchine diversi, ad esempio VM con tipi di GPU diversi, non è supportata.

Passaggi successivi