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

Questa pagina mostra come ottimizzare l'ottenibilità della GPU per carichi di lavoro batch su larga scala con GPU Pianificazione dei carichi di lavoro dinamici e ProvisioningRequest.

Consigliamo Dynamic Workload Scheduler per i carichi di lavoro batch su larga scala che possono essere eseguiti al di fuori delle 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 carico di lavoro è flessibile in termini di tempo e il caso d'uso può permettersi di aspettare tutta la capacità richiesta, ad esempio quando GKE alloca delle risorse GPU al di fuori delle ore di traffico più intenso.
  • 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 attività:

  • Attiva l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi inizializzare con gcloud CLI. Se hai già installato gcloud CLI, scarica 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 che scegli per il pool di nodi.
  • CLUSTER_NAME: il nome del cluster.
  • LOCATION: la regione Compute Engine del cluster, ad esempio come 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 del driver predefinita per GKE completamente gestita.
    • 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 la scalabilità automatica per l'intero pool di nodi.
  • MACHINE_TYPE: il tipo di macchina Compute Engine per dai nodi. Ti consigliamo di selezionare un tipo di macchina ottimizzato per l'acceleratore.

Facoltativamente, puoi utilizzare i seguenti flag:

  • --no-enable-autoupgrade: opzione consigliata. Disabilita gli upgrade automatici dei nodi. Supportato solo in cluster GKE non registrati in un canale di rilascio. Per saperne di più, consulta Disabilitare gli upgrade automatici dei nodi per un pool di nodi esistente.
  • --node-locations=COMPUTE_ZONES: i valori separati da virgole elenco di una o più zone in cui GKE crea i nodi GPU. La devono trovarsi nella stessa regione del cluster. Scegli 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 abilita il provisioning in coda e la scalabilità automatica del cluster.
  • Il pool di nodi inizialmente ha zero nodi.
  • Il flag --enable-queued-provisioning abilita Dynamic Workload Scheduler e aggiunge l'incompatibilità cloud.google.com/gke-queued rispetto 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. Rivedi 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 Dynamic Workload Scheduler sia abilitato per il corretto funzionamento del cluster.

  • Assicurati che il pool di nodi sia vuoto. Puoi ridimensiona il pool di nodi in modo che abbia zero 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 di Compute Engine del cluster, ad esempio come 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.

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

  • Disabilita gli upgrade automatici dei nodi: Ti consigliamo di disabilitare gli upgrade automatici dei nodi poiché gli upgrade del pool di nodi non supportato quando si utilizza Dynamic Workload Scheduler. a disabilitare il nodo assicurati che il cluster GKE non sia registrato in un canale di rilascio.
  • Attiva gVNIC nei pool di nodi GPU: NIC virtuale 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 versioni 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 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. Questo 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. Configurazione del programma di pianificazione dei carichi di lavoro dinamici per i job senza Kueue, vedi Dynamic Workload Scheduler per i job senza Kueue.

Scheduler dinamico di carichi di lavoro per job con Kueue

La sezione seguente mostra come configurare il Dynamic Workload Scheduler per Offerte di lavoro con Kueue. Questa sezione utilizza gli esempi presenti nella directory dws-examples dal repository ai-on-gke. Abbiamo pubblicato gli esempi nella directory dws-examples con 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 tuo cluster:

    VERSION=v0.7.0
kubectl apply --server-side -f https://github.com/kubernetes-sigs/kueue/releases/download/$VERSION/manifests.yaml
di Gemini Advanced.

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

crea le risorse Kueue

Con il manifest seguente, crei una coda a livello di cluster denominata dws-cluster-queue e Spazio dei nomi LocalQueue denominato dws-local-queue. Job che fanno riferimento alla coda dws-cluster-queue in questo utilizza 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

Il file manifest include i seguenti campi pertinenti per Configurazione dello scheduler dinamico dei carichi di lavoro:

  • L'etichetta kueue.x-k8s.io/queue-name: dws-local-queue indica a GKE che Kueue è responsabile dell'orchestrazione di quel 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 non per pianificare ancora i pod. Kueue cambia il flag in false quando i nodi sono pronti per l'esecuzione del job.
  • nodeSelector indica a GKE di pianificare Job solo sul pool di nodi specificato. Il valore deve corrispondere NODEPOOL_NAME, il nome del pool di nodi con 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

Lo Scheduler di carichi di lavoro dinamici con l'integrazione Kueue supporta anche altri carichi di lavoro disponibili nell'ecosistema open source, come i seguenti:

  • RayJob
  • JobSet v0.5.2 o versioni 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.

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

Pianificazione di carichi di lavoro dinamico per job senza Kueue

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
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 dell'elemento ProvisioningRequest. Farai riferimento a questo nome nell'annotazione del pod.
    • MAX_RUN_DURATION_SECONDS: facoltativamente, il numero massimo di un nodo in pochi secondi, fino al valore predefinito di sette giorni. Per ulteriori informazioni 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.

  2. Applica il manifest:

    kubectl apply -f provisioning-request.yaml

configura i pod

Nella specifica Job, collega i pod 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 Annotazioni consume-provisioning-request e provisioning-class-name da fare le seguenti:

  • Pianificare i pod solo nei nodi di cui è stato eseguito il provisioning da Dynamic Workload Scheduler.
  • Per evitare il doppio conteggio delle richieste di risorse tra i pod Dynamic Workload Scheduler nel gestore della scalabilità automatica dei cluster.
  • Per inserire l'annotazione safe-to-evict: false, in modo da impedire al gestore della scalabilità automatica dei cluster dallo spostamento dei pod tra nodi e dall'interruzione dei calcoli in batch. Puoi modifica questo comportamento specificando safe-to-evict: true nel pod annotazioni.

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 la modalità 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 dello scheduler di carichi di lavoro dinamici 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 è 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. Tu Avere 10 minuti per avviare i pod di cui è stato eseguito il provisioning Google Cloud. 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 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 i problemi relativi alla condizione in base a questo motivo e le 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.

Annulla 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 interrompe la creazione dei 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 dei cluster rimuove i nodi dopo 10 minuti se non viene creato alcun 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 dei cluster esegue il provisioning dei nodi necessari, se disponibili, una volta sola.
  5. Tutti i pod del carico di lavoro possono essere eseguiti insieme su nuovi pod di cui è stato eseguito il provisioning nodi.
  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 ulteriori informazioni vedi Limitare il runtime di un VM (anteprima). Questa funzionalità è disponibile con GKE versione 1.28.5-gke.1355000 o successive. Trascorso questo periodo, i nodi e i pod in esecuzione al loro interno vengono prerilasciata. Se i pod vengono terminati prima e i nodi non vengono utilizzati, il cluster il gestore della scalabilità automatica li rimuove in base alla scalabilità automatica profilo.
  7. I nodi non vengono riutilizzati nel Dynamic Workload Scheduler. Ciascuna ProvisioningRequest ordina la creazione di nuovi nodi con i nuovi sette giorni runtime.
di Gemini Advanced.

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. Configuri la quota per ogni progetto, una configurazione 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 elencati in Richiedi una guida per un limite di quota più elevato.

Controlla se Dynamic Workload Scheduler è limitato dalla quota

Se la tua richiesta Dynamic Workload Scheduler sta richiedendo più tempo del previsto completata, 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 successiva, controlla se Le limitazioni della quota impediscono il completamento 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é di quota sufficiente nella regione europe-west4.

Configura le impostazioni di interruzione per i pool di nodi con carichi di lavoro utilizzando 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 dell'esecuzione dei carichi di lavoro utilizzando Dynamic Workload Scheduler, consigliamo di adottare le seguenti misure:

  • A seconda del canale di rilascio del cluster registrazione, utilizza le seguenti best practice per impedire gli upgrade automatici dei nodi che interrompono i carichi di lavoro:
  • Disabilita nodo riparazione automatica.
  • Utilizza periodi di manutenzione ed esclusioni per ridurre al minimo le interruzioni dell'esecuzione carichi di lavoro, garantendo al contempo che ci sia una finestra temporale GKE può interrompere il pool di nodi per la manutenzione automatica. Se utilizzi questi strumenti di manutenzione, devi impostare una finestra temporale specifica in cui GKE può interrompere il pool di nodi, quindi ti consigliamo imposta questa finestra quando non ci sono carichi di lavoro in esecuzione.
  • 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. Questo 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. Lo scheduler dinamico dei carichi di lavoro richiede e supporta solo il criterio di località ANY 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 saperne di più, consulta Configurare le impostazioni di interruzione per i pool di nodi con carichi di lavoro utilizzando 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, 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