Große Arbeitslast mit „Flex-Start“ und Bereitstellung per Warteschlange ausführen

Auf dieser Seite erfahren Sie, wie Sie die GPU-Flexibilität, -Effizienz und -Verfügbarkeit von Rechenkapazität für umfangreiche Batch- und KI-Arbeitslasten mit GPUs optimieren können. Dazu verwenden Sie Flex-Start mit der Bereitstellung per Warteschlange, die vom Dynamic Workload Scheduler unterstützt wird.

Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Themen vertraut:

Dieser Leitfaden richtet sich an ML-Entwickler, Plattformadministratoren und -operatoren sowie Daten- und KI-Spezialisten, die daran interessiert sind, Kubernetes-Containerorchestrierungsfunktionen zum Ausführen von Batcharbeitslasten zu verwenden. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

So funktioniert Flex-Start mit Bereitstellung per Warteschlange

Bei Flex-Start mit Bereitstellung per Warteschlange weist die GKE alle angeforderten Ressourcen gleichzeitig zu. Für Flex-Start mit Bereitstellung per Warteschlange werden die folgenden Tools verwendet:

  • Flex-Start mit Bereitstellung per Warteschlange basiert auf Dynamic Workload Scheduler in Kombination mit der benutzerdefinierten Ressourcendefinition (CRD) für Bereitstellungsanfragen. Diese Tools verwalten die zugewiesene Kapazität basierend auf den verfügbaren Ressourcen und Ihren Arbeitslastanforderungen.
  • Optional: Kueue automatisiert den Lebenszyklus von Flex-Start mit Bereitstellung per Warteschlange-Anfragen. Kueue implementiert die Jobwarteschlange und verarbeitet automatisch den Lebenszyklus der Bereitstellungsanfrage.

Wenn Sie Flex-Start mit der Bereitstellung per Warteschlange verwenden möchten, müssen Sie beim Erstellen des Knotenpools die Flags --flex-start und --enable-queued-provisioning hinzufügen.

Best Practice:

Verwenden Sie Flex-Start mit Bereitstellung per Warteschlange für umfangreiche Batch- und KI-Arbeitslasten, wenn Ihre Arbeitslasten die folgenden Kriterien erfüllen:

  • Ihre Arbeitslasten haben flexible Startzeiten.
  • Ihre Arbeitslasten müssen gleichzeitig auf mehreren Knoten ausgeführt werden.

Verwenden Sie für kleinere Arbeitslasten, die auf einem einzelnen Knoten ausgeführt werden können, Flex-Start-VMs. Weitere Informationen zur GPU-Bereitstellung in GKE finden Sie unter Beschleuniger für KI-Arbeitslasten erhalten.

Hinweis

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 dem Befehl gcloud components update ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

Knotenpools mit Flex-Start mit Bereitstellung per Warteschlange verwenden

Dieser Abschnitt gilt nur für Standardcluster.

Mit einer der folgenden Methoden können Sie festlegen, dass Flex-Start mit der Bereitstellung per Warteschlange mit bestimmten Knotenpools in Ihrem Cluster verwendet werden kann:

Knotenpool erstellen

Erstellen Sie mit der gcloud CLI einen Knotenpool, für den Flex-Start mit der Bereitstellung per Warteschlange aktiviert ist:

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

    Best Practice:

    Verwenden Sie einen beschleunigungsoptimierten Maschinentyp, um die Leistung und Effizienz von KI-/ML-Arbeitslasten zu verbessern.

Optional können Sie die folgenden Flags verwenden:

  • --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 Geschwindigkeit des Netzwerkverkehrs zu erhöhen.
  • --request-valid-for-duration: Dieses Flag weist GKE an, unbegrenzt auf die Erfüllung der GPU-Anfrage zu warten. Wenn dieses Flag nicht angegeben ist, beträgt die Standardwartezeit für GPUs maximal 14 Tage. TPU-Arbeitslasten können dagegen unbegrenzt lange warten.

Dieser Befehl erstellt einen Knotenpool mit der folgenden Konfiguration:

  • Das Flag --flex-start in Kombination mit dem Flag --enable-queued-provisioning weist GKE an, einen Knotenpool mit Flex-Start und aktivierter Bereitstellung per Warteschlange zu erstellen und die Markierung cloud.google.com/gke-queued dem Knotenpool hinzuzufügen.
  • GKE ermöglicht die Bereitstellung per Warteschlange und das Cluster-Autoscaling.
  • Der Knotenpool hat anfangs null Knoten.
  • Mit dem Flag --no-enable-autorepair werden automatische Reparaturen deaktiviert, was zu Unterbrechungen von Arbeitslasten führen kann, die auf reparierten Knoten ausgeführt werden.

Automatische Knotenbereitstellung aktivieren, um Knotenpools für Flex-Start mit Bereitstellung per Warteschlange zu erstellen

Sie können die automatische Knotenbereitstellung verwenden, um Knotenpools für den Flex-Start mit der Bereitstellung per Warteschlange 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, erstellt GKE Knotenpools mit den erforderlichen Ressourcen für die zugehörige Arbeitslast.

Berücksichtigen Sie die folgenden Einstellungen und führen Sie die Schritte unter GPU-Limits konfigurieren aus, um die automatische Knotenbereitstellung zu aktivieren:

  • Geben Sie die erforderlichen Ressourcen für „Flex-Start“ mit Bereitstellung per Warteschlange an, wenn Sie das Feature aktivieren. Führen Sie den Befehl gcloud compute accelerator-types list aus, um die verfügbaren resourceTypes aufzulisten.
  • Verwenden Sie das Flag --no-enable-autoprovisioning-autorepair, um die automatische Knotenreparatur zu deaktivieren.
  • Lassen Sie GKE GPU-Treiber automatisch in automatisch bereitgestellten GPU-Knoten installieren. Weitere Informationen finden Sie unter Treiber mithilfe der automatischen Knotenbereitstellung mit GPUs installieren.

Batch- und KI-Arbeitslasten mit Flex-Start mit Bereitstellung per Warteschlange ausführen

Wenn Sie Batcharbeitslasten mit Flex-Start und der Bereitstellung per Warteschlange ausführen möchten, verwenden Sie eine der folgenden Konfigurationen:

Best Practice:

Verwenden Sie Kueue, um Ihre Batch- und KI-Arbeitslasten mit Flex-Start mit der Bereitstellung per Warteschlange auszuführen.

Flex-Start mit Bereitstellung per Warteschlange für Jobs mit Kueue

In den folgenden Abschnitten wird beschrieben, wie Sie den Flex-Start mit der Bereitstellung per Warteschlange für Jobs mit Kueue konfigurieren:

  • Einrichtung von Knotenpools mit Flex-Start und Bereitstellung per Warteschlange.
  • Einrichtung von Knotenpools mit Reservierung und Flex-Start mit Bereitstellung per Warteschlange.

In diesem Abschnitt werden die Beispiele im Verzeichnis dws-examples des Repositorys ai-on-gke verwendet. Wir haben die Beispiele im Verzeichnis dws-examples unter der Apache2-Lizenz veröffentlicht.

Sie benötigen Administratorberechtigungen, um Kueue zu installieren. Prüfen Sie, ob Ihnen die IAM-Rolle roles/container.admin zugewiesen wurde. Weitere Informationen zu GKE-IAM-Rollen finden Sie im Leitfaden zum Erstellen von IAM-Zulassungsrichtlinien.

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 die neueste Kueue-Version in Ihrem Cluster:

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

    Ersetzen Sie KUEUE_VERSION durch die neueste Kueue-Version.

Wenn Sie Kueue in einer Version vor 0.7.0 verwenden, ändern Sie die Konfiguration des Kueue-Feature-Gates, indem Sie das Feature-Gate ProvisioningACC auf true setzen. Eine ausführlichere Erläuterung und die Standardwerte für die Gates finden Sie unter Feature-Gates von Kueue. Weitere Informationen zur Installation von Kueue finden Sie unter Installation.

Fehlerbehebung bei der Kueue-Installation: Wenn während der Installation Berechtigungsfehler auftreten, prüfen Sie, ob Ihr Nutzer die Rolle cluster-admin hat. Wenn beim Erstellen von Warteschlangen später in dieser Anleitung Fehler vom Typ „Webhook-Verbindung abgelehnt“ auftreten, prüfen Sie Folgendes:

  • Die kueue-controller-manager-Pods werden im Namespace kueue-system vollständig ausgeführt.
  • Die Firewallregeln Ihres Clusters lassen die Kommunikation zwischen Steuerungsebene und Knoten über Port 8443 zu.

Kueue-Ressourcen für die Einrichtung des Dynamic Workload Scheduler-Knotenpools erstellen

Mit dem folgenden Manifest erstellen Sie eine Warteschlange auf Clusterebene mit dem Namen dws-cluster-queue und den LocalQueue-Namespace mit dem Namen dws-local-queue. Jobs, die auf die Warteschlange dws-cluster-queue in diesem Namespace verweisen, verwenden Flex-Start mit der Bereitstellung per Warteschlange, 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", "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
---

Für die Warteschlange dieses Clusters gelten hohe Kontingentlimits und nur die Integration von Flex-Start mit der Bereitstellung per Warteschlange ist aktiviert. Weitere Informationen zu Kueue-APIs und zum Einrichten von Limits finden Sie unter Kueue-Konzepte.

LocalQueue bereitstellen:

kubectl create -f ./dws-queues.yaml

Die Ausgabe sieht 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 Flex-Start mit der Bereitstellung per Warteschlange in anderen Namespaces verwenden, können Sie mithilfe der vorherigen Vorlage zusätzliche LocalQueues erstellen.

Job ausführen

Im folgenden Manifest verwendet der Beispieljob „Flex-Start“ mit der Bereitstellung per Warteschlange:

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 die folgenden Felder, die für die Konfiguration des Flex-Starts mit der Bereitstellung per Warteschlange 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. Dieses Label definiert auch die Warteschlange, in der der Job eingereiht wird.
  • Das Flag suspend: true weist GKE an, die Job-Ressource zu erstellen, die Pods aber noch nicht zu planen. Kueue ändert dieses 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, für den die Warteschlangenbereitstellung aktiviert ist.

  1. Job ausführen:

    kubectl create -f ./job.yaml

    Die Ausgabe sieht in etwa so aus:

    job.batch/sample-job created

  2. Prüfen Sie den Status des Jobs:

    kubectl describe job sample-job

    Die Ausgabe sieht 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

Flex-Start mit Bereitstellung per Warteschlange mit Kueue-Integration unterstützt auch andere Arbeitslasttypen, die in der Open-Source-Umgebung verfügbar sind, z. B.:

  • RayJob
  • JobSet v0.5.2 oder höher
  • Kubeflow MPIJob, TFJob, PyTorchJob.
  • Kubernetes-Pods, die häufig von Workflow-Orchestratoren verwendet werden
  • Flux-Mini-Cluster

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

Kueue-Ressourcen für die Einrichtung des Knotenpools für Reservierungen und Dynamic Workload Scheduler erstellen

Mit dem folgenden Manifest erstellen Sie zwei ResourceFlavors, die an zwei verschiedene Knotenpools gebunden sind: reservation-nodepool und dws-nodepool. Die Namen dieser Knotenpools sind nur Beispielnamen. Ändern Sie diese Namen entsprechend Ihrer Knotenpoolkonfiguration. Außerdem versuchen eingehende Jobs mit der Konfiguration ClusterQueue, reservation-nodepool zu verwenden. Wenn keine Kapazität vorhanden ist, verwenden diese Jobs Dynamic Workload Scheduler, um die GPU-Ressourcen abzurufen.

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

Für die Warteschlange dieses Clusters gelten hohe Kontingentlimits und nur die Integration von Flex-Start mit Bereitstellung per Warteschlange ist aktiviert. Weitere Informationen zu Kueue-APIs und zum Einrichten von Limits finden Sie unter Kueue-Konzepte.

Stellen Sie das Manifest mit dem folgenden Befehl bereit:

kubectl create -f ./dws_and_reservation.yaml

Die Ausgabe sieht etwa so aus:

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

Job ausführen

Im Gegensatz zur vorherigen Einrichtung enthält dieses Manifest nicht das Feld nodeSelector, da es von Kueue in Abhängigkeit von der verfügbaren Kapazität in der ClusterQueue ausgefüllt wird.

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. Job ausführen:

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

    Die Ausgabe sieht etwa so aus:

    job.batch/sample-job-v8xwm created

Um herauszufinden, welchen Knotenpool Ihr Job verwendet, müssen Sie herausfinden, welches ResourceFlavor Ihr Job verwendet.

Fehlerbehebung

Weitere Informationen zur Fehlerbehebung bei Kueue finden Sie unter Fehlerbehebung bei Bereitstellungsanfragen in Kueue.

Flex-Start mit Bereitstellung per Warteschlange für Jobs ohne Kueue

ProvisioningRequest-Objekt definieren

Erstellen Sie für jeden Job eine Anfrage über die Bereitstellungsanfrage. Bei Flex-Start mit Bereitstellung per Warteschlange werden die Pods nicht gestartet, sondern nur die Knoten bereitgestellt.

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

    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

    Ersetzen Sie Folgendes:

    • API_VERSION: Die Version der API, entweder v1 oder v1beta1. Wir empfehlen die Verwendung von v1, um die Stabilität zu gewährleisten und Zugriff auf die neuesten Funktionen zu erhalten.
    • NAMESPACE_NAME: Der Name Ihres Kubernetes-Namespace. Der Namespace muss mit dem Namespace der Pods übereinstimmen.
    • PROVISIONING_REQUEST_NAMEDer Name des ProvisioningRequest. Sie verweisen auf diesen Namen in der Pod-Annotation.
    • MAX_RUN_DURATION_SECONDS: Optional die maximale Laufzeit eines Knotens in Sekunden, bis zum Standardwert von sieben Tagen. Weitere Informationen finden Sie unter Funktionsweise von Flex-Start mit Bereitstellung per Warteschlange. Sie können diesen Wert nach dem Erstellen der Anfrage nicht mehr ändern. Dieses Feld ist 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_NAMEDer Name des PodTemplate.
    • NODEPOOL_NAME: Der Name, den Sie für den Knotenpool auswählen. Entfernen Sie diese, wenn Sie einen automatisch bereitgestellten Knotenpool verwenden möchten.

    GKE kann während der Erstellung Validierungen und Mutationen auf Pods anwenden. Mit dem Label cloud.google.com/apply-warden-policies kann GKE dieselben Validierungen und Mutationen auf PodTemplate-Objekte anwenden. Dieses Label ist erforderlich, damit GKE die Knotenressourcenanforderungen für Ihre Pods berechnen kann.

    Automatische Knotenbereitstellung 

    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

    Ersetzen Sie Folgendes:

    • API_VERSION: Die Version der API, entweder v1 oder v1beta1. Wir empfehlen die Verwendung von v1, um die Stabilität zu gewährleisten und Zugriff auf die neuesten Funktionen zu erhalten.
    • NAMESPACE_NAME: Der Name Ihres Kubernetes-Namespace. Der Namespace muss mit dem Namespace der Pods übereinstimmen.
    • PROVISIONING_REQUEST_NAMEDer Name des ProvisioningRequest. Sie verweisen auf diesen Namen in der Pod-Annotation.
    • MAX_RUN_DURATION_SECONDS: Optional die maximale Laufzeit eines Knotens in Sekunden, bis zum Standardwert von sieben Tagen. Weitere Informationen finden Sie unter Funktionsweise von Flex-Start mit Bereitstellung per Warteschlange. Sie können diesen Wert nach dem Erstellen der Anfrage nicht mehr ändern. Dieses Feld ist 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_NAMEDer Name des PodTemplate.
    • GPU_TYPE: der Typ der GPU-Hardware.

    GKE kann bei der Erstellung von Pods Validierungen und Mutationen anwenden. Mit dem Label cloud.google.com/apply-warden-policies kann GKE dieselben Validierungen und Mutationen auf PodTemplate-Objekte anwenden. Dieses Label ist erforderlich, damit GKE die Knotenressourcenanforderungen für Ihre Pods berechnen kann.

  2. Wenden Sie das Manifest an:

    kubectl apply -f provisioning-request.yaml

Pods konfigurieren

In diesem Abschnitt werden die Pods mit Kubernetes-Jobs konfiguriert. Sie können aber auch ein Kubernetes-JobSet oder ein anderes Framework wie Kubeflow, Ray oder benutzerdefinierte Controller verwenden. Verknüpfen Sie in der Jobspezifikation die Pods mithilfe der folgenden Annotationen mit dem ProvisioningRequest:

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

Der Pod-Annotationsschlüssel 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 Knoten zu planen, die mit Flex-Start mit Bereitstellung per Warteschlange bereitgestellt werden.
  • Vermeiden Sie eine doppelte Zählung von Ressourcenanfragen zwischen Pods und Flex-Start mit der Bereitstellung per Warteschlange im Cluster Autoscaler.
  • 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 einer Bereitstellungsanfrage beobachten

Der Status einer ProvisioningRequest 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 einer ProvisioningRequest und die möglichen Ergebnisse beschrieben:

Status der Bereitstellungsanfrage 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.

Standardmäßig wartet GKE bis zu 14 Tage auf GPU-Anfragen und unbestimmte Zeit auf TPU-Anfragen. Wenn die Anfrage nicht innerhalb dieses Zeitraums erfüllt wird, wechselt sie in den Status Failed.
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 ProvisioningRequest-Anfrage und wiederholen Sie sie.
Provisioned=false Die Knoten wurden noch nicht bereitgestellt.

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

Wenn Reason=QuotaExceeded, beheben Sie Probleme mit 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 die Bereitstellungsanfrage durch das Kontingent begrenzt ist. Dieser Reason ist nur mit der GKE-Version 1.29.2-gke.1181000 oder höher verfügbar.

Wenn Reason=ResourcePoolExhausted und Message Expected time is indefinite enthält, wählen Sie entweder eine andere Zone oder Region aus oder passen Sie die angeforderten Ressourcen an.

Pods starten

Wenn die ProvisioningRequest 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 zur ProvisioningRequest-Anfrage erstellen.

Anfrage für Bereitstellungsanfrage 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.

Kontingentprobleme beheben

Für alle VMs, die durch Provisioning Request-Anfragen bereitgestellt werden, wird Kontingent auf Abruf verwendet.

Die Anzahl der ProvisioningRequests im Status Accepted ist durch ein spezielles Kontingent begrenzt. Sie konfigurieren das Kontingent für jedes Projekt. Pro Region ist eine Kontingentkonfiguration möglich.

Kontingent in der Google Cloud Console prüfen

So prüfen Sie den Namen des Kontingentlimits und die aktuelle Nutzung in derGoogle 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. Wenn Sie das Kontingent erhöhen möchten, folgen Sie der Anleitung unter Kontingentanpassung anfordern.

Prüfen, ob die Bereitstellungsanfrage durch das Kontingent begrenzt ist

Wenn die Ausführung Ihrer Provisioning Request-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.

Knotenpools von der Bereitstellung per Warteschlange auf Flex-Start migrieren

Mit der Verbrauchsoption flex-start werden Flex-Start-VMs erstellt. So migrieren Sie vorhandene Knotenpools, die mit dem Flag --enable-queued-provisioning erstellt wurden, zur Verwendung von Flex-Start:

  1. Prüfen Sie, ob der Knotenpool leer ist:

    kubectl get nodes -l cloud.google.com/gke-nodepool=NODEPOOL_NAME

  2. Aktualisieren Sie den Knotenpool auf Flex-Start-VMs:

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

Dieser Vorgang bewirkt Folgendes:

  • Aktualisieren Sie den Knotenpool zu einem Knotenpool mit Flex-Start-VMs.
  • Wenden Sie die Preise für Knoten an, die Flex-Start-VMs verwenden.

Alle Knoten in Clustern, die auf Version 1.32.2-gke.1652000 oder höher ausgeführt werden, der Mindestversion für Knoten, die Flex-Start-VMs verwenden, verwenden kurzlebige Upgrades.

Nächste Schritte