GKE-Arbeitslasten mit Topology Aware Scheduling (TAS) planen

KI- und ML-Arbeitslasten erfordern eine erhebliche Pod-zu-Pod-Kommunikation. Aufgrund dieser Anforderung wirkt sich die Netzwerkbandbreite zwischen Pods direkt auf die Ausführungszeit und die Kosten von Arbeitslasten 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 KI- oder ML-Arbeitslasten im großen Maßstab in einem Google Kubernetes Engine-Cluster (GKE) sowohl für Leistung als auch für Zuverlässigkeit optimieren. Sie konfigurieren Ihren Cluster so, dass er Topology Aware Scheduling (TAS) für die Kommunikation mit geringer Latenz verwendet. Dieser Ansatz minimiert den Kommunikationsaufwand und trägt dazu bei, die Leistung Ihrer Arbeitslasten zu maximieren.

Was ist die topologiebewusste Planung (Topology Aware Scheduling, TAS)?

TAS kann die Effizienz des Trainings von Large Language Models (LLMs) erheblich verbessern. TAS platziert Worker strategisch in der Netzwerkstruktur, 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 durch Reservierungen erreicht werden kann. Bei Flex-Start-VMs oder Spot-VMs wird die Kapazität weniger wahrscheinlich in unmittelbarer Nähe zugewiesen. Daher funktioniert TAS in diesem Szenario möglicherweise nicht gut.

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.

  • 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 aktivierter 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 aktivierter 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 Kueke müssen Sie es so konfigurieren, dass es die Infrastruktur versteht, die es verwaltet. Das wird im nächsten Abschnitt beschrieben.

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 werden, müssen Sie eine kompakte Platzierung für die 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 Ihrer GKE-Clusternknoten 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 wird durch die folgenden Knotenlabels dargestellt:

  • 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 nebeneinander. Weitere Informationen zu diesen Begriffen finden Sie unter Terminologie.

Kueue konfigurieren

Nach der Installation von Kueue müssen Sie Kueue so konfigurieren, dass die verwaltete Infrastruktur angegeben wird. Normalerweise erfordert Kueue eine ClusterQueue-Ressourcenkontingentdefinition für statische Infrastruktur oder dynamische Infrastruktur mit aktivierter Cluster-Autoskalierung. In die ClusterQueue wird eine Arbeitslast nur aufgenommen, 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 dem 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 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 ein ClusterQueue-Ressourcenkontingent für Kueue definieren:

  • Sehr hohes Kontingent: Kueue verhindert die Aufnahme einer Arbeitslast aufgrund der angeforderten Ressourcen praktisch nie. Basierend auf den TAS-Definitionen kann Kueue Arbeitslasten je nach 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. Anhand der TAS-Definitionen prüft Kueue dann die Infrastrukturtopologie, bevor die Arbeitslast zugelassen wird. Weitere Informationen finden Sie unter Realistic resource quota.

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 beendet. Stattdessen verwendet Kueue die Topologieinformationen der verfügbaren Knoten, um die Topologie mit den Anforderungen des Arbeitslast zu vergleichen.

Führen Sie die folgenden Schritte aus, um die folgende Definition für das Ressourcenkontingent 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, das CPU, Arbeitsspeicher und GPU umfasst. Das gilt für 100 a3-ultragpu-8g-Maschinen. Eine einzelne Maschine hat 224 vCPUs, 2.944 GB Arbeitsspeicher und 8 GPUs.

Führen Sie die folgenden Schritte aus, um die folgende Definition für das Ressourcenkontingent 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 und wenden Sie eine Ressourcenkontingentkonfiguration für das Kueue-Jobwarteschlangensystem 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 und Kueue planen

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

  • Die folgenden Typen für Topologieanfragen 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 auf diese Topologieebene passt. Für eine Arbeitslast, die möglicherweise 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

Wenn Sie Arbeitslasten mit diesen Werten planen möchten, verwenden Sie die folgende Job-YAML-Datei:

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 ‑grad Beschreibung ANNOTATIONS_STRING
    Bevorzugt innerhalb eines Hostnamens ausführen (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 in einem Host

    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 es mehrere VMs pro Host (z. B. kleinere Maschinentypen) gibt 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 in einem Host ausgeführt werden 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 in einem Unterblock Diese Konfiguration lässt Ihre Arbeitslast nur zu, 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 in einem Unterblock ausführen 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 untergeordneten Block mit mehr verfügbarer Kapazität höher ein, auch wenn er fragmentiert ist, als einen untergeordneten Block 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 in einem Block Diese Konfiguration lässt Ihre Arbeitslast nur zu, wenn die in einem Block verfügbaren Ressourcen die Ressourcenanforderungen Ihrer Arbeitslast erfüllen. Wenn die Arbeitslast zugelassen wird, minimiert Kueue die Anzahl der untergeordneten Blö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 innerhalb eines Blocks ausgeführt werden 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 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 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 anders behandelt werden. Die folgenden Beispiele zeigen, wie Sie eine PodGroup mit drei Pods erstellen, einem Leader und zwei Workern.

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

Wenn der Leader einer der Worker ist und auch eine GPU benötigt, kann er eine beliebige Anzahl 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: Der 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 und der erste Worker nicht den ersten Index verwendet, wendet Kueue keine Ranganweisungen 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