GKE-Arbeitslasten mit TAS planen

KI- und ML-Arbeitslasten erfordern eine umfangreiche Kommunikation zwischen Pods. Aufgrund dieser Anforderung wirkt sich die Netzwerkbandbreite zwischen Pods direkt auf die Ausführungszeit und die Kosten der Arbeitslast aus. Diese Bandbreite hängt von der Platzierung der VM-Instanzen im Cluster ab.

In diesem Dokument wird erläutert, wie Sie die Planung Ihrer umfangreichen KI- oder ML-Arbeitslasten in einem GKE-Cluster (Google Kubernetes Engine) sowohl im Hinblick auf die Leistung als auch auf die Zuverlässigkeit optimieren können. Konfigurieren Sie Ihren Cluster so, dass er Topology-Aware Scheduling (TAS) für die Kommunikation mit niedriger Latenz verwendet. Dieser Ansatz minimiert den Kommunikationsaufwand und trägt dazu bei, die Leistung Ihrer Arbeitslasten zu maximieren.

Was ist Topology-Aware Scheduling (TAS)?

TAS kann die Effizienz des Trainings von Large Language Models (LLMs) erheblich verbessern. TAS platziert Worker strategisch in der Netzwerktopologie, um den Kommunikationsaufwand während der Gradientenaggregation zu minimieren. Dazu müssen Worker in einer bestimmten Rangfolge kommunizieren. Durch die Minimierung von Netzwerk-Hops zwischen sequenziell kommunizierenden Workern reduziert TAS Netzwerkkonflikte und optimiert die Bandbreitennutzung, was zu einer schnelleren Konvergenz und kürzeren Trainingszeiten führt. Bei immer größeren LLM-Modellen ist TAS unerlässlich, um die Leistung und Skalierbarkeit des verteilten Trainings zu maximieren.

TAS funktioniert am besten mit dicht platzierter Kapazität, die über reservierungsgebundene Kapazität erreicht werden kann. Bei Spot-VMs und anderen Verbrauchsoptionen ist es weniger wahrscheinlich, dass Ihre Kapazität nahe beieinander zugewiesen wird. Daher funktioniert TAS in diesem Szenario möglicherweise nicht gut.

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.

  • Führen Sie den folgenden Befehl aus, um eine Verbindung zu Ihrem Cluster herzustellen:

    gcloud container clusters get-credentials CLUSTER_NAME

    Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

GKE-Cluster vorbereiten

Führen Sie die folgenden Schritte aus, um Ihren GKE-Cluster für die Ausführung von Arbeitslasten mit TAS vorzubereiten:

  1. Kueue mit aktiviertem TAS installieren

  2. Topologie des GKE-Clusters ansehen

  3. Kueue konfigurieren

Kueue mit aktiviertem TAS installieren

Wir empfehlen, TAS mit Kueue zu verwenden, einem Kubernetes-nativen System, das Kontingente verwaltet und festlegt, wie Jobs diese nutzen sollen. TAS erfordert Kueue-Version 0.10.0 oder höher und muss explizit aktiviert werden.

Wählen Sie eine der folgenden Optionen aus, um Kueue zu installieren und TAS zu aktivieren:

Kueue-Manifest

  1. Installieren Sie Kueue:

    kubectl apply --server-side -f https://github.com/kubernetes-sigs/kueue/releases/download/v0.10.0/manifests.yaml

  2. TAS in Kueue aktivieren:

    kubectl -n kueue-system patch deployment kueue-controller-manager \
    --type json -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--feature-gates=TopologyAwareScheduling=true"}]'

Helm-Diagramm

Installieren Sie Kueue mit aktiviertem TAS mithilfe eines Helm-Diagramms:

helm install kueue oci://us-central1-docker.pkg.dev/k8s-staging-images/charts/kueue \
    --version="v0.10.0" \
    --create-namespace \
    --namespace=kueue-system \
    --set="controllerManager.featureGates[0].name=TopologyAwareScheduling,controllerManager.featureGates[0].enabled=true"

Nachdem Sie Kueue installiert haben, müssen Sie es so konfigurieren, dass es die von ihm verwaltete Infrastruktur versteht, wie im nächsten Abschnitt erläutert.

Topologie Ihres GKE-Cluster ansehen

Bevor Sie die Topologie von A4X-, A4-, A3 Ultra-, A3 Mega- und A3 High-Knoten (8 GPUs) ansehen können, die als Spot-VMs bereitgestellt wurden, müssen Sie die kompakte Platzierung auf den GKE-Knoten definieren, um ihre physische Topologie für TAS verfügbar zu machen. Andernfalls treten Fehler auf.

Führen Sie den folgenden Befehl aus, um die Topologie der GKE-Clusterknoten in einem bestimmten Knotenpool aufzurufen:

kubectl get nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME \
    -ocustom-columns='NAME:.metadata.name,BLOCK:.metadata.labels.cloud\.google\.com/gce-topology-block,SUBBLOCK:.metadata.labels.cloud\.google\.com/gce-topology-subblock,HOST:.metadata.labels.cloud\.google\.com/gce-topology-host' | sort -k2,4

Ersetzen Sie NODE_POOL_NAME durch den Namen des Knotenpools.

Die physische Topologie von GKE-Knoten auf Ihren VMs in der Ausgabe können Sie anhand der folgenden Knotenlabels nachvollziehen:

  • cloud.google.com/gce-topology-block: die organisationsspezifische ID des reservierten Blocks, in dem sich die VM befindet.

  • cloud.google.com/gce-topology-subblock: die organisationsspezifische ID des Unterblocks, in dem sich die VM befindet.

  • cloud.google.com/gce-topology-host: die ID des Hosts, auf dem sich die VM befindet.

  • kubernetes.io/hostname: der Hostname des Kubernetes-Knotens. Dieser Hostname ist in der Regel auch der GKE-Knotenname.

Je mehr Labelwerte zwei VMs gemeinsam haben, desto näher befinden sich die VMs physisch beieinander. Weitere Informationen zu diesen Begriffen finden Sie unter Terminologie.

Kueue konfigurieren

Nach der Installation von Kueue müssen Sie Kueue konfigurieren, um die zu verwaltende Infrastruktur anzugeben. In der Regel erfordert Kueue eine ClusterQueue-Ressourcenkontingentdefinition entweder für eine statische Infrastruktur oder für eine dynamische Infrastruktur mit aktiviertem Cluster-Autoscaling. Die ClusterQueue lässt eine Arbeitslast nur zu, wenn die von der Arbeitslast angeforderten Ressourcen kleiner oder gleich dem in der ClusterQueue definierten Ressourcenpool sind. Nachdem Sie Kueue wie in diesem Abschnitt beschrieben konfiguriert haben, lässt Kueue Arbeitslasten mit TAS so zu:

  • TAS-Arbeitslasten: Kueue prüft sowohl die Topologie der physischen Infrastruktur als auch ihre aktuelle Nutzung.

  • Nicht-TAS-Arbeitslasten: Kueue prüft die Topologie der physischen Infrastruktur nicht. Kueue verwaltet das gesamte in der Konfiguration definierte Kontingent und überlässt die Knotenzuweisung kube-scheduler.

In den folgenden Beispielen wird gezeigt, wie Sie eine ClusterQueue-Ressourcenkontingentdefinition für Kueue bereitstellen:

  • Sehr hohes Kontingent: Kueue beendet die Zulassung einer Arbeitslast praktisch nie aufgrund der angeforderten Ressourcen. Je nach TAS-Definitionen kann Kueue Arbeitslasten basierend auf der Infrastrukturtopologie zulassen oder nicht. Weitere Informationen finden Sie unter Sehr hohes Ressourcenkontingent.

  • Realistisches Kontingent: Kueue lässt die Arbeitslast nur zu, wenn die von der Arbeitslast angeforderten Ressourcen innerhalb dieser Ressourcenkontingentlimits liegen. Basierend auf den TAS-Definitionen prüft Kueue dann die Infrastrukturtopologie, bevor die Arbeitslast zugelassen wird. Weitere Informationen finden Sie unter Realistisches Ressourcenkontingent.

Alle Verweise auf Ressourcenkontingente in den folgenden Abschnitten beziehen sich auf ClusterQueue-Ressourcenkontingente.

Sehr hohes Ressourcenkontingent

Im folgenden Beispiel wird ein sehr hohes Ressourcenkontingent verwendet, sodass Kueue eine Arbeitslast nie aufgrund des verfügbaren Ressourcenkontingents stoppt. Stattdessen verwendet Kueue die Topologieinformationen der verfügbaren Knoten, um die Topologie mit den Anforderungen der Arbeitslast abzugleichen.

Führen Sie die folgenden Schritte aus, um die folgende Ressourcenkontingentdefinition zu verwenden:

  1. Öffnen Sie einen Dateieditor Ihrer Wahl. Fügen Sie dann die folgende Kontingentdefinition in eine YAML-Datei mit dem Namen kueue-tas-config-very-high-quota.yaml ein:

      apiVersion: kueue.x-k8s.io/v1alpha1
  kind: Topology
  metadata:
    name: "gke-default"
  spec:
    levels:
    - nodeLabel: "cloud.google.com/gce-topology-block"
    - nodeLabel: "cloud.google.com/gce-topology-subblock"
    - nodeLabel: "cloud.google.com/gce-topology-host"
    - nodeLabel: "kubernetes.io/hostname"
---
  kind: ResourceFlavor
  apiVersion: kueue.x-k8s.io/v1beta1
  metadata:
    name: "tas-flavor"
  spec:
    nodeLabels:
      cloud.google.com/gke-nodepool: "NODE_POOL_NAME"
    topologyName: "gke-default"
    tolerations:
    - key: "nvidia.com/gpu"
      operator: "Exists"
      effect: NoSchedule
---
  apiVersion: kueue.x-k8s.io/v1beta1
  kind: ClusterQueue
  metadata:
    name: "tas-cluster-queue"
  spec:
    namespaceSelector: {}
    resourceGroups:
    - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "tas-flavor"
        resources:
        - name: "nvidia.com/gpu"
          nominalQuota: 10000000
---
  apiVersion: kueue.x-k8s.io/v1beta1
  kind: LocalQueue
  metadata:
    namespace: "default"
    name: "tas-user-queue"
  spec:
    clusterQueue: "tas-cluster-queue"

    Ersetzen Sie NODE_POOL_NAME durch den Namen des Knotenpools.

  2. Erstellen Sie die Ressourcenkontingentkonfiguration für das Kueue-Jobwarteschlangensystem und wenden Sie sie an:

    kubectl create -f kueue-tas-config-very-high-quota.yaml

Realistisches Ressourcenkontingent

Im vorherigen Beispiel wurden nur GPU-Ressourcen konfiguriert. Kueue kann jedoch alle Kubernetes-kompatiblen Ressourcen verwalten.

Im folgenden Beispiel wird ein realistischeres Ressourcenkontingent definiert, einschließlich CPU, Arbeitsspeicher und GPU. Dies gilt für 100 a3-ultragpu-8g-Maschinen. Eine einzelne Maschine hat 224 vCPUs, 2.944 GB Arbeitsspeicher und 8 GPUs. Dasselbe Prinzip gilt für allgemeine GPU-Maschinentypen (A2, A3 Edge, G2, G4 und N1) mit ihren jeweiligen CPU- und Arbeitsspeicherspezifikationen.

Führen Sie die folgenden Schritte aus, um die folgende Ressourcenkontingentdefinition zu verwenden:

  1. Öffnen Sie einen Dateieditor Ihrer Wahl. Fügen Sie dann die folgende Kontingentdefinition in eine YAML-Datei mit dem Namen kueue-tas-config-real-quota.yaml ein:

      apiVersion: kueue.x-k8s.io/v1alpha1
  kind: Topology
  metadata:
    name: "gke-default"
  spec:
    levels:
    - nodeLabel: "cloud.google.com/gce-topology-block"
    - nodeLabel: "cloud.google.com/gce-topology-subblock"
    - nodeLabel: "cloud.google.com/gce-topology-host"
    - nodeLabel: "kubernetes.io/hostname"
---
  kind: ResourceFlavor
  apiVersion: kueue.x-k8s.io/v1beta1
  metadata:
    name: "tas-flavor"
  spec:
    nodeLabels:
      cloud.google.com/gke-nodepool: "NODE_POOL_NAME"
    topologyName: "gke-default"
    tolerations:
    - key: "nvidia.com/gpu"
      operator: "Exists"
      effect: NoSchedule
---
  apiVersion: kueue.x-k8s.io/v1beta1
  kind: ClusterQueue
  metadata:
    name: "tas-cluster-queue"
  spec:
    namespaceSelector: {} # match all
    resourceGroups:
    - coveredResources: ["cpu", "memory", "nvidia.com/gpu"]
      flavors:
      - name: "tas-flavor"
        resources:
        # numbers below represent quota of 100 a3-ultragpu-8g machines
        - name: "cpu"
          nominalQuota: 22400
        - name: "memory"
          nominalQuota: 294400Gi
        - name: "nvidia.com/gpu"
          nominalQuota: 800
---
  apiVersion: kueue.x-k8s.io/v1beta1
  kind: LocalQueue
  metadata:
    namespace: "default"
    name: "tas-user-queue"
  spec:
    clusterQueue: "tas-cluster-queue"

    Ersetzen Sie NODE_POOL_NAME durch den Namen des Knotenpools.

  2. Erstellen Sie eine Ressourcenkontingentkonfiguration für das Kueue-Jobwarteschlangensystem und wenden Sie sie an:

    kubectl create -f kueue-tas-config-real-quota.yaml

    Die Ausgabe sieht etwa so aus:

    topology.kueue.x-k8s.io/gke-default created
resourceflavor.kueue.x-k8s.io/tas-flavor created
clusterqueue.kueue.x-k8s.io/tas-cluster-queue created
localqueue.kueue.x-k8s.io/tas-user-queue created

Arbeitslasten mit TAS über Kueue planen

In den folgenden Szenarien wird gezeigt, wie Sie Kueue und TAS anweisen können, gängige Kombinationen aus Arbeitslasten und Infrastruktur mithilfe von Topologieanfragetypen und Topologieanfrageebenen zu verwalten:

  • Folgende Topologieanfragetypen sind verfügbar (bevorzugt oder erforderlich):

    • kueue.x-k8s.io/podset-preferred-topology: Kueue priorisiert die Planung der gesamten Arbeitslast innerhalb einer bestimmten Topologieebene, lässt aber auch eine Arbeitslast zu, die nicht in diese Topologieebene passt. Für eine Arbeitslast, die in eine einzelne Topologieebene gepasst hätte, kann Kueue diese Arbeitslast über mehrere Instanzen dieser Topologieebene hinweg planen.

    • kueue.x-k8s.io/podset-required-topology: Kueue versucht weiterhin, diese Arbeitslast zuzulassen, bis die gesamte Arbeitslast in die ausgewählte Topologieebene passt.

  • Die folgenden Ebenen für Topologieanfragen sind verfügbar. Damit können Sie mehr oder weniger genau angeben, auf welcher physischen Infrastruktur Ihr Job ausgeführt werden soll:

    • cloud.google.com/gce-topology-block

    • cloud.google.com/gce-topology-subblock

    • cloud.google.com/gce-topology-host

    • kubernetes.io/hostname

Verwenden Sie die folgende Job-YAML-Datei, um Arbeitslasten mit diesen Werten zu planen:

apiVersion: batch/v1
kind: Job
metadata:
  generateName: JOB_NAME
  labels:
    kueue.x-k8s.io/queue-name: tas-user-queue
spec:
  parallelism: NUMBER_OF_REPLICAS
  completions: NUMBER_OF_REPLICAS
  completionMode: Indexed
  template:
    metadata:
      annotations:
        ANNOTATIONS_STRING
    spec:
      containers:
      - name: dummy-job
        image: gcr.io/k8s-staging-perf-tests/sleep:v0.1.0
        args: ["60s"]
        resources:
          requests:
            nvidia.com/gpu: "1"
          limits:
            nvidia.com/gpu: "1"
      restartPolicy: Never

Ersetzen Sie die folgenden Variablen:

  • JOB_NAME: Ein Name für den Job.

  • NUMBER_OF_REPLICAS: die Anzahl der Pods, die parallel ausgeführt werden.

  • ANNOTATIONS_STRING: siehe folgende Tabelle:

    Angeforderter Topologietyp und ‑ebene Beschreibung ANNOTATIONS_STRING
    Bevorzugt für die Ausführung innerhalb eines Hostnamens (empfohlen) Bei dieser Konfiguration wird Ihre Arbeitslast zugelassen, solange genügend Ressourcen verfügbar sind, um die Ressourcenanforderungen Ihrer Arbeitslast zu erfüllen, auch wenn die Kapazität fragmentiert ist. Kueue plant Ihre Pods so kompakt wie möglich. kueue.x-k8s.io/podset-preferred-topology: "kubernetes.io/hostname"
    Erforderlich für die Ausführung in einem Host

    Mit dieser Konfiguration wird Ihre Arbeitslast nur dann zugelassen, wenn ein Host mit genügend Ressourcen verfügbar ist, um die Ressourcenanforderungen Ihrer Arbeitslast zu erfüllen.

    Das ist nützlich, wenn mehrere VMs pro Host vorhanden sind (z. B. kleinere Maschinentypen) oder mehrere Pods auf einem einzelnen Knoten ausgeführt werden können. In solchen Fällen wird die Arbeitslast, wenn sie zugelassen wird, auf einem einzelnen Host ausgeführt.

    		 kueue.x-k8s.io/podset-required-topology: "cloud.google.com/gce-topology-host"
    Bevorzugt für die Ausführung in einem Host Mit dieser Konfiguration wird Ihre Arbeitslast zugelassen, solange genügend Ressourcen verfügbar sind, um die Ressourcenanforderungen Ihrer Arbeitslast zu erfüllen, auch wenn die Kapazität fragmentiert ist. Kueue versucht, Ihre Pods innerhalb eines Hosts zu planen, und verwendet bei Bedarf zusätzliche Hosts. kueue.x-k8s.io/podset-preferred-topology: "cloud.google.com/gce-topology-host"
    Erforderlich für die Ausführung in einem Unterblock Bei dieser Konfiguration wird Ihre Arbeitslast nur dann zugelassen, wenn ein Unterblock mit genügend Ressourcen verfügbar ist, um die Ressourcenanforderungen Ihrer Arbeitslast zu erfüllen. kueue.x-k8s.io/podset-required-topology: "cloud.google.com/gce-topology-subblock"
    Bevorzugt für die Ausführung in einem Unterblock Bei dieser Konfiguration wird Ihre Arbeitslast zugelassen, solange genügend Ressourcen verfügbar sind, um die Ressourcenanforderungen Ihrer Arbeitslast zu erfüllen, auch wenn die Kapazität fragmentiert ist. Kueue versucht, Ihre Pods innerhalb eines Unterblocks zu planen, und verwendet bei Bedarf zusätzliche Unterblöcke. In diesem Fall wird ein Unterblock mit mehr verfügbarer Kapazität höher eingestuft, auch wenn er fragmentiert ist, im Vergleich zu einem Unterblock mit gerade genug Kapazität, um die Anforderungen zu erfüllen. kueue.x-k8s.io/podset-preferred-topology: "cloud.google.com/gce-topology-subblock"
    Erforderlich für die Ausführung innerhalb eines Blocks Bei dieser Konfiguration wird Ihre Arbeitslast nur dann zugelassen, wenn die in einem Block verfügbaren Ressourcen die Ressourcenanforderungen Ihrer Arbeitslast erfüllen. Wenn die Arbeitslast zugelassen wird, minimiert Kueue die Anzahl der Unterblöcke und Hosts, um die Arbeitslast zu planen. Dies kann zu einer Fragmentierung der verfügbaren Kapazität führen. kueue.x-k8s.io/podset-required-topology: "cloud.google.com/gce-topology-block"
    Bevorzugt für die Ausführung innerhalb eines Blocks Bei dieser Konfiguration wird Ihre Arbeitslast zugelassen, solange genügend Ressourcen verfügbar sind, um die Ressourcenanforderungen Ihrer Arbeitslast zu erfüllen, auch wenn die Kapazität fragmentiert ist. Kueue versucht, Ihre Pods innerhalb eines Blocks zu planen, und verwendet bei Bedarf zusätzliche Blöcke. kueue.x-k8s.io/podset-preferred-topology: "cloud.google.com/gce-topology-block"

Arbeitslasten mit PodGroup mit TAS mithilfe von Kueue planen

Wenn Sie PodGroups verwenden, müssen Sie für jeden Pod in einer PodGroup drei zusätzliche Felder angeben:

Je nach verwendetem ML-Framework kann ein Leader einer PodGroup eine GPU erfordern oder nicht. Aufgrund einer Einschränkung von Kueue müssen diese Fälle anders behandelt werden. In den folgenden Beispielen wird gezeigt, wie Sie eine PodGroup mit drei Pods erstellen, die aus einem Leader und zwei Workern besteht.

Fall 1: Leader ist auch ein Worker und benötigt eine GPU

Wenn der Leader einer der Worker ist und ebenfalls eine GPU benötigt, kann er eine beliebige Nummer innerhalb der PodGroup haben. Der Einfachheit halber ist der Index des Leaders im folgenden Beispiel 0:

apiVersion: v1
kind: Pod
metadata:
  generateName: tas-podgroup-leader-
  labels:
    kueue.x-k8s.io/queue-name: tas-user-queue
    kueue.x-k8s.io/pod-group-name: "tas-podgroup-example-group"
    kueue.x-k8s.io/pod-group-pod-index: "0"
  annotations:
    kueue.x-k8s.io/pod-group-total-count: "3"
    kueue.x-k8s.io/podset-required-topology: "cloud.google.com/gce-topology-block"
spec:
  containers:
  - name: leader
    image: gcr.io/k8s-staging-perf-tests/sleep:v0.1.0
    args: ["600s"]
    resources:
      requests:
        nvidia.com/gpu: "1"
      limits:
        nvidia.com/gpu: "1"
  restartPolicy: Never
---
apiVersion: v1
kind: Pod
metadata:
  generateName: tas-podgroup-worker-1-
  labels:
    kueue.x-k8s.io/queue-name: tas-user-queue
    kueue.x-k8s.io/pod-group-name: "tas-podgroup-example-group"
    kueue.x-k8s.io/pod-group-pod-index: "1"
  annotations:
    kueue.x-k8s.io/pod-group-total-count: "3"
    kueue.x-k8s.io/podset-required-topology: "cloud.google.com/gce-topology-block"
spec:
  restartPolicy: Never
  containers:
  - name: worker
    image: gcr.io/k8s-staging-perf-tests/sleep:v0.1.0
    args: ["600s"]
    resources:
      requests:
        nvidia.com/gpu: "1"
      limits:
        nvidia.com/gpu: "1"
---
apiVersion: v1
kind: Pod
metadata:
  generateName: tas-podgroup-worker-2-
  labels:
    kueue.x-k8s.io/queue-name: tas-user-queue
    kueue.x-k8s.io/pod-group-name: "tas-podgroup-example-group"
    kueue.x-k8s.io/pod-group-pod-index: "2"
  annotations:
    kueue.x-k8s.io/pod-group-total-count: "3"
    kueue.x-k8s.io/podset-required-topology: "cloud.google.com/gce-topology-block"
spec:
  restartPolicy: Never
  containers:
  - name: worker
    image: gcr.io/k8s-staging-perf-tests/sleep:v0.1.0
    args: ["600s"]
    resources:
      requests:
        nvidia.com/gpu: "1"
      limits:
        nvidia.com/gpu: "1"

Fall 2: Leader ist kein Worker und benötigt keine GPU

Wenn der Leader aufgrund der Kueue-Einschränkung nicht einer der Worker ist, muss er den letzten Index in der PodGroup haben, da Kueue PodSets so erstellt. Wenn der Leader nicht den letzten Index hat und der erste Worker nicht den ersten Index verwendet, wendet Kueue keine Rangzuweisungen an.

Sehen Sie sich folgendes Beispiel an:

---
apiVersion: v1
kind: Pod
metadata:
  generateName: tas-podgroup-leader-
  labels:
    kueue.x-k8s.io/queue-name: tas-user-queue
    kueue.x-k8s.io/pod-group-name: "tas-podgroup-example-group2"
    kueue.x-k8s.io/pod-group-pod-index: "2"
  annotations:
    kueue.x-k8s.io/pod-group-total-count: "3"
    kueue.x-k8s.io/podset-required-topology: "cloud.google.com/gce-topology-block"
spec:
  containers:
  - name: leader
    image: gcr.io/k8s-staging-perf-tests/sleep:v0.1.0
    args: ["600s"]
    resources:
      requests:
        cpu: "1"
      limits:
        cpu: "1"
  restartPolicy: Never
---
apiVersion: v1
kind: Pod
metadata:
  generateName: tas-podgroup-worker-0-
  labels:
    kueue.x-k8s.io/queue-name: tas-user-queue
    kueue.x-k8s.io/pod-group-name: "tas-podgroup-example-group2"
    kueue.x-k8s.io/pod-group-pod-index: "0"
  annotations:
    kueue.x-k8s.io/pod-group-total-count: "3"
    kueue.x-k8s.io/podset-required-topology: "cloud.google.com/gce-topology-block"
spec:
  restartPolicy: Never
  containers:
  - name: worker
    image: gcr.io/k8s-staging-perf-tests/sleep:v0.1.0
    args: ["600s"]
    resources:
      requests:
        nvidia.com/gpu: "1"
      limits:
        nvidia.com/gpu: "1"
---
apiVersion: v1
kind: Pod
metadata:
  generateName: tas-podgroup-worker-1-
  labels:
    kueue.x-k8s.io/queue-name: tas-user-queue
    kueue.x-k8s.io/pod-group-name: "tas-podgroup-example-group2"
    kueue.x-k8s.io/pod-group-pod-index: "1"
  annotations:
    kueue.x-k8s.io/pod-group-total-count: "3"
    kueue.x-k8s.io/podset-required-topology: "cloud.google.com/gce-topology-block"
spec:
  restartPolicy: Never
  containers:
  - name: worker
    image: gcr.io/k8s-staging-perf-tests/sleep:v0.1.0
    args: ["600s"]
    resources:
      requests:
        nvidia.com/gpu: "1"
      limits:
        nvidia.com/gpu: "1"

Nächste Schritte