GKE-Arbeitslasten mit TAS planen

KI- und ML-Arbeitslasten erfordern eine erhebliche Pod-zu-Pod-Kommunikation. Aus diesem Grund 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 (virtuelle Maschinen) im Cluster ab.

In diesem Dokument wird erläutert, wie Sie die Planung Ihrer umfangreichen KI- oder ML-Arbeitslasten in einem Google Kubernetes Engine-Cluster (GKE) sowohl für die Leistung als auch für die Zuverlässigkeit optimieren. Insbesondere 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 bei der Gradientenaggregation zu minimieren. Dazu müssen Worker in einer bestimmten Rangfolge kommunizieren. Durch die Minimierung der Netzwerk-Hops zwischen sequenziell kommunizierenden Workern reduziert TAS die Netzwerküberlastung 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 nah 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, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl 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 Ihres GKE-Clusters ansehen

  3. Kueue konfigurieren

Kueue mit aktiviertem TAS installieren

Wir empfehlen, TAS mit Kueue zu verwenden, einem nativen Kubernetes-System , das Kontingente verwaltet und festlegt, wie Jobs diese nutzen sollen. Für TAS ist Kueue-Version 0.10.0 oder höher erforderlich und Sie müssen es explizit aktivieren.

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

Kueue-Manifest

  1. Kueue installieren:

    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"

Nach der Installation von Kueue müssen Sie es so konfigurieren, dass es die Infrastruktur versteht, die es verwaltet, 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, 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 anzusehen:

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.

Anhand der folgenden Knotenlabels können Sie die physische Topologie der GKE-Knoten auf Ihren VMs in der Ausgabe 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 liegen die VMs physisch nebeneinander. Weitere Informationen zu diesen Begriffen finden Sie unter Terminologie.

Kueue konfigurieren

Nach der Installation von Kueue müssen Sie es so konfigurieren, dass die Infrastruktur angegeben wird, die es verwaltet. In der Regel erfordert Kueue eine ClusterQueue Ressourcen kontingentdefinition entweder für statische Infrastruktur oder für dynamische Infrastruktur mit aktivierter Cluster-Autoskalierung. 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 wie folgt zu:

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

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

In den folgenden Beispielen erfahren Sie, wie Sie eine Definition des Ressourcenkontingents für die ClusterQueue für Kueue bereitstellen:

  • Sehr hohes Kontingent: Kueue stoppt die Zulassung einer Arbeitslast aufgrund der angeforderten Ressourcen praktisch nie. Basierend auf den TAS-Definitionen lässt Kueue Arbeitslasten je nach Infrastrukturtopologie zu 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 das Ressourcenkontingent der ClusterQueue.

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 Definition des Ressourcenkontingents zu verwenden:

  1. Öffnen Sie einen Texteditor 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 und übernehmen Sie die Konfiguration des Ressourcenkontingents für das Kueue-Jobwarteschlangensystem:

    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 (A2, A3 Edge, G2, G4 und N1) Maschinentypen mit ihren jeweiligen CPU- und Arbeitsspeicherspezifikationen.

Führen Sie die folgenden Schritte aus, um die folgende Definition des Ressourcenkontingents zu verwenden:

  1. Öffnen Sie einen Texteditor 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 und übernehmen Sie eine Konfiguration des Ressourcenkontingents für das Kueue-Jobwarteschlangensystem:

    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 und Kueue planen

In den folgenden Szenarien wird gezeigt, wie Sie Kueue und TAS anweisen können, gängige Arbeitslast- und Infrastrukturkombinationen mithilfe von Topologieanfragetypen und Topologieanfrageebenen zu verwalten:

  • Die folgenden Topologieanfrage-typen sind verfügbar (bevorzugt oder erforderlich):

    • kueue.x-k8s.io/podset-preferred-topology: Kueue priorisiert die Planung der gesamten Arbeitslast auf einer bestimmten Topologieebene, lässt aber auch eine Arbeitslast zu, die nicht in diese Topologieebene passt. Für eine Arbeitslast, die möglicherweise in eine einzelne Topologieebene gepasst hätte, plant Kueue diese Arbeitslast möglicherweise auf mehreren Instanzen dieser Topologieebene.

    • 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 Topologieanfrage-ebenen ermöglichen es Ihnen, mehr oder weniger genau anzugeben, in welcher physischen Infrastruktur Ihr Job bevorzugt oder zwingend 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 die Ausführung innerhalb eines Hostnamens (empfohlen) 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 plant Ihre Pods so kompakt wie möglich. kueue.x-k8s.io/podset-preferred-topology: "kubernetes.io/hostname"
    Erforderlich für die Ausführung innerhalb eines Hosts

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

    Dies 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. Wenn die Arbeitslast in solchen Fällen zugelassen wird, wird sie auf einem einzelnen Host ausgeführt.

    		 kueue.x-k8s.io/podset-required-topology: "cloud.google.com/gce-topology-host"
    Bevorzugt die Ausführung innerhalb eines Hosts 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 auf einem Host 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 innerhalb eines Unterblocks Mit dieser Konfiguration wird Ihre Arbeitslast nur 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 die Ausführung innerhalb eines Unterblocks 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 in einem Unterblock zu planen, und verwendet bei Bedarf zusätzliche Unterblöcke. In diesem Fall stuft Kueue einen Unterblock mit mehr verfügbarer Kapazität höher ein, auch wenn er fragmentiert ist, als einen 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 Mit dieser Konfiguration wird Ihre Arbeitslast nur 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 Ihrer verfügbaren Kapazität führen. kueue.x-k8s.io/podset-required-topology: "cloud.google.com/gce-topology-block"
    Bevorzugt die Ausführung innerhalb eines Blocks 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 in einem Block 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 und TAS mit 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 für einen Leader einer PodGroup eine GPU erforderlich sein oder nicht. Aufgrund einer Einschränkung von Kueue müssen diese Fälle unterschiedlich behandelt werden. In den folgenden Beispielen wird gezeigt, wie Sie eine PodGroup mit drei Pods erstellen, darunter ein Leader und zwei Worker.

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

Wenn der Leader einer der Worker ist und auch eine GPU benötigt, kann der Leader eine beliebige Nummer innerhalb der PodGroup haben. Der Einfachheit halber ist im folgenden Beispiel der Index des Leaders 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 keiner der Worker ist, muss der Leader den letzten Index in der PodGroup haben, da Kueue PodSets 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