GPUs für Batch-Arbeitslasten mit dem Dynamic Workload Scheduler bereitstellen

Auf dieser Seite erfahren Sie, wie Sie die GPU-Erreichbarkeit über den Dynamic Workload Scheduler optimieren. Wir empfehlen den Dynamic Workload Scheduler für umfangreiche Batcharbeitslasten, die außerhalb der Spitzenzeiten mit definierten GPU-Kapazitätsverwaltungsbedingungen ausgeführt werden können. Diese Arbeitslasten können ein Deep-Learning-Modelltraining oder eine Simulation sein, die große GPUs mit einem atomaren Bereitstellungsmodell erfordert. Dies bedeutet, dass alle Ressourcen gleichzeitig erstellt werden.

Informationen zum Ausführen von GPU-Arbeitslasten in Google Kubernetes Engine (GKE) ohne den Dynamic Workload Scheduler finden Sie unter GPUs in GKE-Standardknotenpools ausführen.

Wann sollte der Dynamic Workload Scheduler verwendet werden?

Wir empfehlen die Verwendung des Dynamic Workload Schedulers, wenn Ihre Arbeitslasten die folgenden Bedingungen erfüllen:

  • Sie fordern GPUs zum Ausführen Ihrer Arbeitslasten an.
  • Sie haben eine begrenzte oder keine reservierte GPU-Kapazität und möchten die Erreichbarkeit von GPU-Ressourcen verbessern.
  • Ihre Arbeitslast ist zeitflexibel und Ihr Anwendungsfall kann es sich leisten, die gesamte angeforderte Kapazität zu erhalten, z. B. wenn GKE die GPU-Ressourcen außerhalb der stärksten Stunden zuweist.
  • Ihre Arbeitslast erfordert mehrere Knoten und kann erst ausgeführt werden, wenn alle GPU-Knoten bereitgestellt und bereit sind (z. B. verteiltes Training für maschinelles Lernen).

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

Knotenpools mit Dynamic Workload Scheduler verwenden

Mit einer der folgenden drei Methoden können Sie festlegen, dass der Dynamic Workload Scheduler mit bestimmten Knotenpools in Ihrem Cluster arbeiten kann:

Knotenpool erstellen

Erstellen Sie mit der gcloud CLI einen Knotenpool, für den der Dynamic Workload Scheduler aktiviert ist:

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

Ersetzen Sie Folgendes:

  • NODEPOOL_NAME: Der Name, den Sie für den Knotenpool auswählen.
  • CLUSTER_NAME: Der Name des Clusters.
  • LOCATION: Die Compute Engine-Region des Clusters, z. B. us-central1.
  • GPU_TYPE: Der GPU-Typ.
  • AMOUNT: Die Anzahl der GPUs, die an Knoten im Knotenpool angehängt werden sollen.
  • DRIVER_VERSION: Die zu installierende NVIDIA-Treiberversion. Kann eines der Folgenden sein:
    • default: Installieren Sie die Standardtreiberversion für Ihre GKE-Version.
    • latest: Installieren Sie die neueste verfügbare Treiberversion für Ihre GKE-Version. Nur für Knoten verfügbar, die Container-Optimized OS verwenden.
  • TOTAL_MAX_NODES: Die maximale Anzahl von Knoten, die automatisch für den gesamten Knotenpool skaliert werden sollen.
  • MACHINE_TYPE: der Compute Engine-Maschinentyp für Ihre Knoten. Wir empfehlen die Auswahl eines beschleunigungsoptimierten Maschinentyps.

Optional können Sie die folgenden Flags verwenden:

  • --no-enable-autoupgrade: empfohlen. Deaktiviert automatische Knotenupgrades. Wird nur in GKE-Clustern unterstützt, die nicht für eine Release-Version registriert sind. Weitere Informationen finden Sie unter Automatische Knotenupgrades für einen vorhandenen Knotenpool deaktivieren.
  • --node-locations=COMPUTE_ZONES: Die durch Kommas getrennte Liste mit einer oder mehreren Zonen, in denen GKE die GPU-Knoten erstellt. Die Zonen müssen sich in derselben Region wie der Cluster befinden. Wählen Sie Zonen mit verfügbaren GPUs aus.
  • --enable-gvnic: Dieses Flag aktiviert gVNIC auf den GPU-Knotenpools, um die Netzwerktraffic-Geschwindigkeit zu erhöhen.

Dieser Befehl erstellt einen Knotenpool mit der folgenden Konfiguration:

  • GKE aktiviert die Warteschlangenbereitstellung und das Cluster-Autoscaling.
  • Der Knotenpool hat anfangs null Knoten.
  • Das Flag --enable-queued-provisioning aktiviert den Dynamic Workload Scheduler und fügt dem Knotenpool die Markierung cloud.google.com/gke-queued hinzu.
  • Die Flags --no-enable-autorepair und --no-enable-autoupgrade deaktivieren die automatische Reparatur und das Upgrade von Knoten, was Arbeitslasten unterbrechen kann, die auf reparierten oder aktualisierten Knoten ausgeführt werden. Sie können automatische Knotenupgrades nur auf Clustern deaktivieren, die nicht für eine Release-Version registriert sind.

Vorhandenen Knotenpool aktualisieren und Dynamic Workload Scheduler aktivieren

Aktivieren Sie den Dynamic Workload Scheduler für einen vorhandenen Knotenpool. Prüfen Sie die Voraussetzungen, um den Knotenpool korrekt zu konfigurieren.

Vorbereitung

  • Erstellen Sie einen Knotenpool mit dem Flag --reservation-affinity=none. Dieses Flag ist erforderlich, um später den Dynamic Workload Scheduler zu aktivieren, da Sie die Reservierungsaffinität nach der Erstellung des Knotenpools nicht mehr ändern können.

  • Achten Sie darauf, dass mindestens ein Knotenpool ohne aktivierte Dynamic Workload Scheduler-Verarbeitung vorhanden ist, damit der Cluster ordnungsgemäß funktioniert.

  • Prüfen Sie, ob der Knotenpool leer ist. Sie können die Größe des Knotenpools so ändern, dass er null Knoten enthält.

  • Prüfen Sie, ob Autoscaling aktiviert und korrekt konfiguriert ist.

  • Achten Sie darauf, dass automatische Reparaturen deaktiviert sind.

Dynamic Workload Scheduler für vorhandenen Knotenpool aktivieren

Sie können Dynamic Workload Scheduler für einen vorhandenen Knotenpool mit der gcloud CLI aktivieren:

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

Ersetzen Sie Folgendes:

  • NODEPOOL_NAME ist der Name des ausgewählten Knotenpools.
  • CLUSTER_NAME: Name des Clusters
  • LOCATION: Die Compute Engine-Region des Clusters, z. B. us-central1.

Dieser Befehl zum Aktualisieren des Knotenpools führt zu folgenden Konfigurationsänderungen:

  • Das Flag --enable-queued-provisioning aktiviert den Dynamic Workload Scheduler und fügt dem Knotenpool die Markierung cloud.google.com/gke-queued hinzu.

Optional können Sie auch die folgenden Knotenpooleinstellungen aktualisieren:

  • Automatische Knotenupgrades deaktivieren: Wir empfehlen, dass Sie automatische Knotenupgrades deaktivieren, da Upgrades von Knotenpools bei Verwendung des Dynamic Workload Schedulers nicht unterstützt werden. Achten Sie darauf, dass Ihr GKE-Cluster nicht für eine Release-Version registriert ist, damit Sie automatische Knotenupgrades deaktivieren können.
  • gVNIC in den GPU-Knotenpools aktivieren: Google Virtual NIC (gVNIC) erhöht die Netzwerktraffic-Geschwindigkeit für GPU-Knoten.

Automatische Knotenbereitstellung aktivieren, um Knotenpools für Dynamic Workload Scheduler zu erstellen

Sie können die automatische Knotenbereitstellung verwenden, um Knotenpools für den Dynamic Workload Scheduler für Cluster zu verwalten, auf denen Version 1.29.2-gke.1553000 oder höher ausgeführt wird. Wenn Sie die automatische Knotenbereitstellung aktivieren und den Dynamic Workload Scheduler aktivieren, erstellt GKE Knotenpools mit den erforderlichen Ressourcen für die zugehörige Arbeitslast.

Beachten Sie zum Aktivieren der automatischen Knotenbereitstellung die folgenden Einstellungen und führen Sie die Schritte unter GPU-Limits konfigurieren aus:

  • Geben Sie die erforderlichen Ressourcen für den Dynamic Workload Scheduler an, wenn Sie das Feature aktivieren. Führen Sie den Befehl gcloud compute accelerator-types list aus, um die verfügbaren resourceTypes aufzulisten.
  • Wir empfehlen, die Flags --no-enable-autoprovisioning-autoupgrade und --no-enable-autoprovisioning-autorepair zu verwenden, um automatische Knotenupgrades und automatische Knotenreparaturen zu deaktivieren. Weitere Informationen finden Sie unter Unterbrechungseinstellungen für Knotenpools mit Arbeitslasten mithilfe des Dynamic Workload Schedulers konfigurieren.

Batch-Arbeitslasten mit Dynamic Workload Scheduler ausführen

Zur Verwendung des Dynamic Workload Schedulers empfehlen wir die Verwendung von Kueue. Kueue implementiert die Jobwarteschlangen und entscheidet anhand der Kontingente und einer Hierarchie für die faire Freigabe von Ressourcen, wann Jobs warten und wann sie gestartet werden sollen. Dies vereinfacht die Einrichtung für VMs in der Warteschlange.

Sie können den Dynamic Workload Scheduler ohne Kueue verwenden, wenn Sie Ihre eigenen internen Batch-Planungstools oder -Plattform verwenden. Informationen zum Konfigurieren des Dynamic Workload Schedulers für Jobs ohne Kueue finden Sie unter Dynamic Workload Scheduler für Jobs ohne Kueue.

Dynamic Workload Scheduler für Jobs mit Kueue

Im folgenden Abschnitt erfahren Sie, wie Sie den Dynamic Workload Scheduler für Jobs mit Kueue konfigurieren. In diesem Abschnitt werden die Beispiele im Repository dws-examples verwendet. Wir haben die Beispiele im Repository dws-examples unter der Apache2-Lizenz veröffentlicht.

Umgebung vorbereiten

  1. Führen Sie in Cloud Shell den folgenden Befehl aus:

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

  2. Installieren Sie Kueue in Ihrem Cluster mit der erforderlichen Konfiguration, um die Einbindung der Bereitstellungsanfrage zu aktivieren:

    kubectl apply --server-side -f ./kueue-manifests.yaml

Weitere Informationen zur Kueue-Installation finden Sie unter Installation.

Kueue-Ressourcen erstellen

Mit dem folgenden Manifest erstellen Sie eine Warteschlange auf Clusterebene mit dem Namen dws-cluster-queue und den Namespace LocalQueue dws-local-queue. Jobs, die auf die Warteschlange dws-cluster-queue in diesem Namespace verweisen, verwenden Dynamic Workload Scheduler, um die GPU-Ressourcen abzurufen.

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

LocalQueue bereitstellen:

kubectl create -f ./dws-queues.yaml

Die Ausgabe sieht in etwa so aus:

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

Wenn Sie Jobs ausführen möchten, die Dynamic Workload Scheduler in anderen Namespaces verwenden, können Sie mithilfe der vorherigen Vorlage zusätzliche LocalQueues erstellen.

Job ausführen

Im folgenden Manifest verwendet der Beispieljob den 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

Dieses Manifest enthält folgende Felder, die für die Konfiguration des Dynamischen Arbeitslastplans relevant sind:

  • Das Label kueue.x-k8s.io/queue-name: dws-local-queue teilt GKE mit, dass Kueue für die Orchestrierung dieses Jobs verantwortlich ist. Mit diesem Label wird auch die Warteschlange definiert, in der der Job in die Warteschlange gestellt wird.
  • Das Flag suspend: true weist GKE an, die Jobressource zu erstellen, die Pods jedoch noch nicht zu planen. Kueue ändert das Flag in false, wenn die Knoten für die Jobausführung bereit sind.
  • nodeSelector weist GKE an, den Job nur im angegebenen Knotenpool zu planen. Der Wert sollte mit NODEPOOL_NAME übereinstimmen, dem Namen des Knotenpools mit aktivierter Warteschlangenbereitstellung.

  1. Job ausführen:

    kubectl create -f ./job.yaml

    Die Ausgabe sieht in etwa so aus:

    job.batch/sample-job created

  2. Überprüfen Sie den Status Ihres Jobs:

    kubectl describe job sample-job

    Die Ausgabe sieht in etwa so aus:

    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

Der Dynamic Workload Scheduler mit Kueue-Integration unterstützt auch andere Arbeitslasttypen, die in der Open-Source-Umgebung verfügbar sind, z. B.:

  • RayJob
  • Job-Set
  • Kubeflow MPIJob, TFJob, PyTorchJob.
  • Kubernetes-Pods, die häufig von Workflow-Orchestratoren verwendet werden
  • Flux-Minicluster

Weitere Informationen zu dieser Unterstützung finden Sie unter Batchnutzer von Kueue.

Dynamic Workload Scheduler für Jobs ohne Kueue

Erstellen Sie für jeden Job eine Anfrage über die ProvisioningRequest API. Der Dynamic Workload Scheduler startet die Pods nicht, sondern stellt nur die Knoten bereit.

  1. Erstellen Sie das folgende provisioning-request.yaml-Manifest:

    apiVersion: v10
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

    Ersetzen Sie Folgendes:

    • NAMESPACE_NAME: Der Name Ihres Kubernetes-Namespace. Der Namespace muss mit dem Namespace der Pods übereinstimmen.
    • PROVISIONING_REQUEST_NAMEDer Name des ProvisioningRequest. Sie finden diesen Namen in der Pod-Annotation.
    • MAX_RUN_DURATION_SECONDS: Optional die maximale Laufzeit eines Knotens in Sekunden bis zur Standardeinstellung von sieben Tagen. Weitere Informationen finden Sie unter Funktionsweise des Dynamic Workload Scheduler. Sie können diesen Wert nach dem Erstellen der Anfrage nicht mehr ändern. Dieses Feld ist in der Vorschau in der GKE-Version 1.28.5-gke.1355000 oder höher verfügbar.
    • COUNT: Anzahl der angeforderten Pods. Die Knoten werden in einer einzigen Zone atomar geplant.
    • POD_TEMPLATE_NAME: Der Standardname von Kubernetes. GKE verweist auf diesen Wert im PodSet der Bereitstellungsanfrage.
    • NODEPOOL_NAME: Der Name, den Sie für den Knotenpool auswählen.

  2. Wenden Sie das Manifest an:

    kubectl apply -f provisioning-request.yaml

Pods konfigurieren

Verknüpfen Sie in der Jobspezifikation die Pods mithilfe der folgenden Annotationen mit dem ProvisioningRequest:

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

Der Pod-Annotationsschlüssel cluster-autoscaler.kubernetes.io/consume-provisioning-request definiert, welche ProvisioningRequest genutzt werden soll. GKE verwendet die Annotationen consume-provisioning-request und provisioning-class-name, um Folgendes zu tun:

  • Um die Pods nur in den vom Dynamic Workload Scheduler bereitgestellten Knoten zu planen.
  • Vermeiden Sie eine doppelte Zählung von Ressourcenanfragen zwischen Pods und Dynamic Workload Scheduler im Cluster-Autoscaling.
  • Fügen Sie die Annotation safe-to-evict: false ein, um zu verhindern, dass Cluster Autoscaler Pods zwischen Knoten verschiebt und Batchberechnungen unterbricht. Sie können dieses Verhalten ändern. Geben Sie dazu safe-to-evict: true in den Pod-Annotationen an.

Status des Dynamic Workload Schedulers beobachten

Der Status eines Dynamic Workload Schedulers definiert, ob ein Pod geplant werden kann oder nicht. Mit Überwachungen von Kubernetes können Sie effizient Änderungen oder andere Tools beobachten, die Sie bereits zum Verfolgen des Status von Kubernetes-Objekten verwenden. In der folgenden Tabelle werden der mögliche Status eines Dynamic Workload Schedulers und die möglichen Ergebnisse beschrieben:

Status des Dynamic Workload Schedulers Beschreibung Mögliches Ergebnis
Ausstehend Die Anfrage wurde noch nicht gesehen und verarbeitet. Nach der Verarbeitung wechselt die Anfrage in den Status Accepted oder Failed.
Accepted=true Die Anfrage wird akzeptiert und wartet darauf, dass Ressourcen verfügbar sind. Die Anfrage sollte in den Status Provisioned wechseln, wenn Ressourcen gefunden und Knoten bereitgestellt wurden, oder in den Status Failed, wenn dies nicht möglich war.
Provisioned=true Die Knoten sind bereit. Sie haben 10 Minuten Zeit, um die Pods zu starten, um bereitgestellte Ressourcen zu verbrauchen. Nach diesem Zeitpunkt betrachtet der Cluster Autoscaler die Knoten als nicht erforderlich und entfernt sie.
Failed=true Die Knoten können aufgrund von Fehlern nicht bereitgestellt werden. Failed=true ist ein Terminalstatus. Beheben Sie Probleme mit der Bedingung anhand der Informationen in den Feldern Reason und Message der Bedingung. Erstellen Sie eine neue Anfrage für den Dynamic Workload Scheduler und wiederholen Sie sie.
Provisioned=false Die Knoten wurden noch nicht bereitgestellt.

Bei Reason=NotProvisioned ist dies ein temporärer Status, bevor alle Ressourcen verfügbar sind.

Bei Reason=QuotaExceeded beheben Sie den Fehler in der Bedingung anhand dieses Grunds und der Informationen im Feld Message der Bedingung. Möglicherweise müssen Sie ein höheres Kontingent anfordern. Weitere Informationen finden Sie im Abschnitt Prüfen, ob der Dynamic Workload Scheduler durch das Kontingent begrenzt ist. Dieser Reason ist nur mit der GKE-Version 1.29.2-gke.1181000 oder höher verfügbar.

Pods starten

Wenn die Anfrage des Dynamic Workload Schedulers den Status Provisioned=true erreicht, können Sie Ihren Job ausführen, um die Pods zu starten. Dadurch wird eine Verbreitung nicht planbarer Pods durch ausstehende oder fehlgeschlagene Anfragen vermieden, was sich auf die Leistung von kube-scheduler und Cluster Autoscaler auswirken kann.

Wenn Sie keine nicht planbaren Pods haben möchten, können Sie alternativ Pods parallel zum Dynamic Workload Scheduler erstellen.

Anfrage für den Dynamic Workload Scheduler abbrechen

Wenn Sie die Anfrage abbrechen möchten, bevor sie bereitgestellt wird, können Sie die ProvisioningRequest löschen:

kubectl delete provreq PROVISIONING_REQUEST_NAME -n NAMESPACE

In den meisten Fällen verhindert das Löschen von ProvisioningRequest, dass Knoten erstellt werden. Je nach Zeitplan, z. B. wenn Knoten bereits bereitgestellt werden, werden die Knoten jedoch möglicherweise noch erstellt. In diesen Fällen entfernt Cluster Autoscaler die Knoten nach 10 Minuten, wenn keine Pods erstellt werden.

Funktionsweise des Dynamic Workload Schedulers

Mit dem ProvisioningRequest API führt der Dynamic Workload Scheduler folgende Schritte aus:

  1. Sie teilen GKE mit, dass Ihre Arbeitslast für einen begrenzten Zeitraum warten kann, bis alle erforderlichen Knoten gleichzeitig einsatzbereit sind.
  2. Das Cluster-Autoscaling akzeptiert Ihre Anfrage und berechnet die Anzahl der erforderlichen Knoten als solche, die als eine Einheit behandelt werden.
  3. Die Anfrage wartet, bis alle benötigten Ressourcen in einer einzigen Zone verfügbar sind.
  4. Cluster Autoscaler stellt die erforderlichen Knoten auf einmal bereit, sofern verfügbar.
  5. Alle Pods der Arbeitslast können gemeinsam auf neu bereitgestellten Knoten ausgeführt werden.
  6. Die bereitgestellten Knoten sind auf eine Laufzeit von sieben Tagen oder weniger beschränkt, wenn Sie den Parameter maxRunDurationSeconds so festlegen, dass die Arbeitslasten weniger Zeit für die Ausführung benötigen. Weitere Informationen finden Sie unter Laufzeit einer VM begrenzen (Vorschau). Diese Funktion ist in der GKE-Version 1.28.5-gke.1355000 oder höher verfügbar. Danach werden die Knoten und die darauf ausgeführten Pods vorzeitig beendet. Wenn die Pods früher beendet sind und die Knoten nicht verwendet werden, entfernt Cluster Autoscaler sie gemäß dem Autoscaling-Profil.
  7. Die Knoten werden zwischen dem Dynamic Workload Scheduler nicht wiederverwendet. Mit jeder ProvisioningRequest wird die Erstellung neuer Knoten mit der neuen siebentägigen Laufzeit bestellt.

Kontingent

Die Anzahl der ProvisioningRequests mit dem Status Accepted ist durch ein dediziertes Kontingent begrenzt, das pro Projekt und unabhängig für jede Region konfiguriert wird.

Kontingent in der Google Cloud Console prüfen

So prüfen Sie den Namen des Kontingentlimits und die aktuelle Nutzung in der Google Cloud Console:

  1. Rufen Sie in der Google Cloud Console die Seite Kontingente auf.

    Kontingente aufrufen

  2. Wählen Sie im Feld Filter das Attribut Messwert aus, geben Sie active_resize_requests ein und drücken Sie die Eingabetaste.

Der Standardwert ist 100. Folgen Sie der Anleitung in der Anleitung zum Anfordern eines höheren Kontingentlimits, um das Kontingent zu erhöhen.

Prüfen, ob der Dynamic Workload Scheduler durch das Kontingent begrenzt ist

Wenn die Ausführung Ihrer Dynamic Workload Scheduler-Anfrage länger als erwartet dauert, prüfen Sie, ob die Anfrage nicht durch ein Kontingent begrenzt ist. Möglicherweise müssen Sie ein höheres Kontingent anfordern.

Prüfen Sie bei Clustern mit Version 1.29.2-gke.1181000 oder höher, ob bestimmte Kontingentbeschränkungen verhindern, dass Ihre Anfrage ausgeführt wird:

kubectl describe provreq PROVISIONING_REQUEST_NAME \
    --namespace NAMESPACE

Die Ausgabe sieht in etwa so aus:

…
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 diesem Beispiel kann GKE keine Knoten bereitstellen, da in der Region europe-west4 nicht genügend Kontingent vorhanden ist.

Unterbrechungseinstellungen für Knotenpools mit Arbeitslasten mithilfe des Dynamic Workload Schedulers konfigurieren

Arbeitslasten, die die Verfügbarkeit aller Knoten oder der meisten Knoten in einem Knotenpool erfordern, sind empfindlich auf Bereinigungen. Die automatische Reparatur oder ein Upgrade eines Knotens, der mit ProvisioningRequest API bereitgestellt wird, wird nicht unterstützt, da bei diesen Vorgängen alle auf diesem Knoten ausgeführten Arbeitslasten entfernt werden und die Arbeitslasten nicht planbar werden.

Um Unterbrechungen bei der Ausführung von Arbeitslasten mit dem Dynamic Workload Scheduler zu minimieren, empfehlen wir die folgenden Maßnahmen:

  • Verwenden Sie je nach Release-Kanalregistrierung Ihres Clusters die folgenden Best Practices, um zu verhindern, dass automatische Knotenupgrades Ihre Arbeitslasten beeinträchtigen:
  • Automatische Knotenreparatur deaktivieren
  • Verwenden Sie Wartungsfenster und -ausschlüsse, um Unterbrechungen bei laufenden Arbeitslasten zu minimieren und zu gewährleisten, dass ein Zeitfenster vorhanden ist, in dem GKE den Knotenpool für eine automatische Wartung unterbrechen kann. Wenn Sie diese Wartungstools verwenden, müssen Sie ein bestimmtes Zeitfenster festlegen, in dem GKE den Knotenpool stören kann. Daher empfehlen wir, dieses Zeitfenster festzulegen, wenn keine Arbeitslasten ausgeführt werden.
  • Damit Ihr Knotenpool auf dem neuesten Stand bleibt, empfehlen wir ein manuelles Upgrade Ihres Knotenpools, wenn keine aktiven Dynamic Workload Scheduler-Anfragen vorhanden sind und der Knotenpool leer ist.

Beschränkungen

  • Anti-Affinität zwischen Pods wird nicht unterstützt. Cluster Autoscaler berücksichtigt während der Knotenbereitstellung keine Anti-Affinitätsregeln zwischen Pods, was zu nicht planbaren Arbeitslasten führen kann. Dies kann passieren, wenn Knoten für zwei oder mehr Dynamic Workload Scheduler-Objekte im selben Knotenpool bereitgestellt wurden.
  • Nur GPU-Knoten werden unterstützt.
  • Reservierungen werden mit dem Dynamic Workload Scheduler nicht unterstützt. Beim Erstellen des Knotenpools müssen Sie --reservation-affinity=none angeben. Der Dynamic Workload Scheduler erfordert und unterstützt nur die Standortrichtlinie ANY für Cluster-Autoscaling.
  • Eine einzelne Dynamic Workload Scheduler-Anfrage kann bis zu 1.0000VMs erstellen. Dies ist die maximale Anzahl von Knoten pro Zone für einen einzelnen Knotenpool.
  • GKE verwendet das ACTIVE_RESIZE_REQUESTS-Kontingent von Compute Engine, um die Anzahl der Anfragen für Dynamic Workload Scheduler zu steuern, die in einer Warteschlange ausstehen. Dieses Kontingent ist auf Google Cloud-Projektebene standardmäßig auf 100 beschränkt. Wenn Sie versuchen, eine Dynamic Workload Scheduler-Anfrage zu erstellen, die dieses Kontingent überschreitet, schlägt die neue Anfrage fehl.
  • Knotenpools, die Dynamic Workload Scheduler verwenden, sind störungsanfällig, da die Knoten gemeinsam bereitgestellt werden. Weitere Informationen finden Sie unter Unterbrechungseinstellungen für Knotenpools mit Arbeitslasten mithilfe des Dynamic Workload Schedulers konfigurieren.
  • In der Google Cloud Console werden möglicherweise zusätzliche kurzlebige VMs angezeigt. Dieses Verhalten ist beabsichtigt, da Compute Engine VMs erstellen und sofort entfernen kann, bis die Kapazität zum Bereitstellen aller erforderlichen Maschinen verfügbar ist.
  • Die Integration des Dynamic Workload Schedulers unterstützt nur ein PodSet. Wenn Sie verschiedene Pod-Vorlagen kombinieren möchten, verwenden Sie die Vorlage mit den meisten angeforderten Ressourcen. Die Kombination verschiedener Maschinentypen, z. B. VMs mit verschiedenen GPU-Typen, wird nicht unterstützt.

Nächste Schritte