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

Auf dieser Seite erfahren Sie, wie Sie die GPU-Erreichbarkeit für umfangreiche Batch- und KI-Arbeitslasten mit GPUs mithilfe von Flex-Start mit in die Warteschlange gestellter Bereitstellung optimieren, 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 Entwickler von maschinellem Lernen (ML), Plattformadministratoren und ‑operatoren sowie an Daten- und KI-Spezialisten, die daran interessiert sind, Kubernetes-Container-Orchestrierungsfunktionen zum Ausführen von Batcharbeitslasten zu nutzen. 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.

Funktionsweise von Flex-Start mit Bereitstellung per Warteschlange

Bei Flex-Start mit Bereitstellung per Warteschlange werden alle angeforderten Ressourcen gleichzeitig von GKE zugewiesen. Beim Flex-Start mit Bereitstellung per Warteschlange werden die folgenden Tools verwendet:

Wenn Sie Flex-Start mit der Bereitstellung in der 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 in der 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.

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 diesen Task 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. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

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 in der Warteschlange mit bestimmten Knotenpools in Ihrem Cluster arbeiten kann:

Knotenpool erstellen

Erstellen Sie mit der gcloud CLI einen Knotenpool, für den der flexible Start mit 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  \
    --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.

    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 Netzwerktraffic-Geschwindigkeit zu erhöhen.

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 aktiviertem Flex-Start mit Warteschlangenbereitstellung zu erstellen und dem Knotenpool die Markierung cloud.google.com/gke-queued hinzuzufügen.
  • GKE aktiviert die Warteschlangenbereitstellung und das Cluster-Autoscaling.
  • Der Knotenpool hat anfangs null Knoten.
  • Das Flag --no-enable-autorepair deaktiviert automatische Reparaturen, 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 in der Warteschlange zu erstellen

Sie können die automatische Knotenbereitstellung verwenden, um Knotenpools für Flex-Start mit in die Warteschlange gestellter Bereitstellung 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.

Wenn Sie die automatische Knotenbereitstellung aktivieren möchten, berücksichtigen Sie die folgenden Einstellungen und führen Sie die Schritte unter GPU-Limits konfigurieren aus:

  • Geben Sie die erforderlichen Ressourcen für „Flex-Start“ mit Bereitstellung in der 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.
  • GPU-Treiber automatisch in automatisch bereitgestellten GPU-Knoten installieren lassen. 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 in der 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 und Bereitstellung in der Warteschlange auszuführen.

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

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

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

In diesem Abschnitt werden die Beispiele im Verzeichnis dws-examples aus dem Repository 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. Dazu benötigen Sie die IAM-Rolle roles/container.admin. 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 detailliertere Erklärung und Standard-Gate-Werte finden Sie unter Kueues Feature-Gates. Weitere Informationen zur Kueue-Installation finden Sie unter Installation.

Kueue-Ressourcen für die Einrichtung des Knotenpools für Dynamic Workload Scheduler 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 in der 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 Flex-Start-Integration mit der Warteschlangenbereitstellung 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 in die Warteschlange gestellter Bereitstellung 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 in der 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 flexiblen Starts mit in die Warteschlange gestellter Bereitstellung relevant sind:

  • Das Label kueue.x-k8s.io/queue-name: dws-local-queue weist GKE darauf hin, 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 Ausführung des Jobs 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 Ihres 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

Der flexible Start mit in die Warteschlange gestellter Bereitstellung 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 von 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 Beispiele. Ä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 Flex-Start-Integration mit der Warteschlangenbereitstellung 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 freien Kapazität in 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, welche ResourceFlavor Ihr Job verwendet.

Fehlerbehebung

Weitere Informationen zur Fehlerbehebung in 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 Provisioning Request. 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, v1 zu verwenden, da es stabiler ist und Sie so Zugriff auf die neuesten Funktionen haben.
    • 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 in die Warteschlange gestellter Bereitstellung. 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 Option, 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 Ressourcenanforderungen von Knoten für Ihre Pods berechnen kann. Die Integration für den flexiblen Start mit in die Warteschlange gestellter Bereitstellung unterstützt nur eine PodSet-Spezifikation. Wenn Sie verschiedene Pod-Vorlagen kombinieren möchten, verwenden Sie die Vorlage, für die die meisten Ressourcen erforderlich sind. Die Kombination verschiedener Maschinentypen, z. B. VMs mit verschiedenen GPU-Typen, wird nicht unterstützt.

    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, v1 zu verwenden, da es stabiler ist und Sie so Zugriff auf die neuesten Funktionen haben.
    • 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 in die Warteschlange gestellter Bereitstellung. 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 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 Ressourcenanforderungen von Knoten 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 von Flex-Start mit Bereitstellung per Warteschlange bereitgestellten Knoten zu planen.
  • Vermeiden Sie eine doppelte Zählung von Ressourcenanfragen zwischen Pods und Flex-Start mit in die Warteschlange gestellter Bereitstellung 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.
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 vorübergehender 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 erstellen.

ProvisioningRequest-Anfrage 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, werden Kontingente 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 -Konsole 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 beantragen.

Prüfen, ob die ProvisioningRequest-Anfrage 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. Knotenpool auf Flex-Start-VMs aktualisieren:

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

Bei diesem Vorgang wird Folgendes ausgeführt:

  • Aktualisieren Sie den Knotenpool auf einen 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