Oracle Cloud Infrastructure - Dokumentation

AMD GPU-Plug-in

Wenn Sie das AMD GPU-Plug-in-Cluster-Add-on aktivieren, können Sie die folgenden Schlüssel/Wert-Paare als Argumente übergeben.

Um sicherzustellen, dass Workloads, die auf AMD-GPU-Worker-Knoten ausgeführt werden, nicht unerwartet unterbrochen werden, wird empfohlen, die Version des AMD-GPU-Plug-in-Add-ons zu wählen, anstatt anzugeben, dass Oracle das Add-on automatisch aktualisieren soll.

Allgemeine Konfigurationsargumente für die meisten Cluster-Add-ons
Schlüssel (API und CLI) Anzeigename des Schlüssels (Konsole) Beschreibung Erforderlich/Optional Standardwert Beispielwert
affinity Affinität

Eine Gruppe von Affinitätsplanungsregeln.

JSON-Format im Klartext oder Base64-codiert.

Nicht verwendet von:
  • Nvidia-GPU-Operator
Mögliche Äquivalente:
  • Knotenfeature Discovery, verwenden Sie master.affinity
  • NVIDIA Network Operator, verwenden Sie operator.affinity
  • CSI-Treiber SMB, verwenden Sie contoller.affinity
  • AMD-GPU-Operator, controllerManager.affinity verwenden
 Optional Null Null
nodeSelectors Knotenselektoren

Mit Knotenselektoren und Knotenlabels können Sie die Worker-Knoten steuern, auf denen Add-on-Pods ausgeführt werden.

Damit ein Pod auf einem Knoten ausgeführt werden kann, muss der Knotenselektor des Pods denselben Schlüssel/Wert wie das Label des Knotens aufweisen.

Setzen Sie nodeSelectors auf ein Schlüssel/Wert-Paar, das sowohl dem Knotenselektor des Pods als auch dem Label des Worker-Knotens entspricht.

JSON-Format im Klartext oder Base64-codiert.

Nicht verwendet von:
  • NVIDIA-GPU-Operator
  • CSI-Treiber SMB
Mögliche Äquivalente:
  • Knotenfeature Discovery, verwenden Sie worker.nodeSelector
  • NVIDIA Network Operator, verwenden Sie operator.nodeSelectors
  • AMD GPU-Operator, verwenden Sie selector oder controllerManager.nodeSelector
 Optional Null {"foo":"bar", "foo2": "bar2"}

Der Pod wird nur auf Knoten ausgeführt, die das Label foo=bar oder foo2=bar2 aufweisen.
numOfReplicas numOfReplicas Die Anzahl der Replikate der Add-on-Bereitstellung.
Nicht verwendet von:
  • AMD-GPU-Plug-in
  • NVIDIA-GPU-Operator
  • NVIDIA-Netzwerkbetreiber
  • CSI-Treiber SMB
Mögliche Äquivalente:
  • CoreDNS, verwenden Sie nodesPerReplica
  • Knotenfeature Discovery, verwenden Sie master.replicaCount
  • AMD-GPU-Operator, controllerManager.replicas verwenden
 Erforderlich 1

Erstellt ein Replikat des Add-on-Deployments pro Cluster.

 2

Erstellt zwei Replikate des Add-on-Deployments pro Cluster.
rollingUpdate rollingUpdate

Steuert das gewünschte Verhalten der rollierenden Aktualisierung durch maxSurge und maxUnavailable.

JSON-Format im Klartext oder Base64-codiert.

Nicht verwendet von:
  • Knotenfeature-Discovery
  • NVIDIA-Netzwerkbetreiber
  • CSI-Treiber SMB
Mögliche Äquivalente:
  • NVIDIA-GPU-Operator, daemonsets.rollingUpdate.maxUnavailable verwenden
  • AMD-GPU-Operator, verwenden upgradePolicy in devicePlugin, metricsExporter, testRunner, configManager oder draDriver
 Optional Null Null
tolerations Toleranzen

Mit Taints und Toleranzen können Sie die Worker-Knoten steuern, auf denen Add-on-Pods ausgeführt werden.

Damit ein Pod auf einem Knoten mit einem Taint ausgeführt werden kann, muss der Pod eine entsprechende Toleranz aufweisen.

Setzen Sie tolerations auf ein Schlüssel/Wert-Paar, das sowohl der Podtoleranz als auch dem Taint des Worker-Knotens entspricht.

JSON-Format im Klartext oder Base64-codiert.

Mögliche Äquivalente:
  • Knotenfeature Discovery, verwenden Sie master.tolerations und/oder worker.tolerations
  • NVIDIA-GPU-Operator, daemonsets.tolerations verwenden
  • NVIDIA Network Operator, verwenden Sie operator.tolerations
  • CSI-Treiber SMB, verwenden Sie controller.tolerations
  • AMD GPU-Operator, Toleranzen in devicePlugin, metricsExporter, testRunner, configManager, draDriver oder controllerManager verwenden
 Optional Null [{"key":"tolerationKeyFoo", "value":"tolerationValBar", "effect":"noSchedule", "operator":"exists"}]

Nur Pods mit dieser Toleranz können auf Worker-Knoten ausgeführt werden, die den Taint tolerationKeyFoo=tolerationValBar:noSchedule aufweisen.
topologySpreadConstraints topologySpreadConstraints

So verteilen Sie passende Pods auf die angegebene Topologie.

JSON-Format im Klartext oder Base64-codiert.

Nicht verwendet von:
  • Knotenfeature-Discovery
  • NVIDIA-GPU-Operator
  • NVIDIA-Netzwerkbetreiber
  • CSI-Treiber SMB
  • AMD-GPU-Operator
 Optional Null Null
Für dieses Cluster-Add-on spezifische Konfigurationsargumente
Schlüssel (API und CLI) Anzeigename des Schlüssels (Konsole) Beschreibung Erforderlich/Optional Standardwert Beispielwert
amd-gpu-device-plugin.ContainerResources amd-gpu-device-plugin-Containerressourcen

Sie können die Ressourcenmengen angeben, die von den Add-on-Containern angefordert werden, und Grenzwerte für die Ressourcennutzung festlegen, die von den Add-on-Containern nicht überschritten werden dürfen.

JSON-Format im Klartext oder Base64-codiert.

 Optional Null {"limits": {"cpu": "500m", "memory": "200Mi" }, "requests": {"cpu": "100m", "memory": "100Mi"}}

Erstellen Sie Add-on-Container, die 100 Millicores CPU und 100 Mebibyte Speicher anfordern. Begrenzen Sie Add-on-Container auf 500 Millicores CPU und 200 Mebibyte Arbeitsspeicher.
pulse Health Checks aktivieren

Zeitintervall in Sekunden, nach dem das Plug-in das Kubelet mit dem Gerätestatus aktualisiert.

Setzen Sie diesen Wert auf 0, um den Health Check zu deaktivieren.

 Optional 0
Große Cluster – Überlegungen

In der folgenden Tabelle werden die Aspekte beim Konfigurieren dieses Cluster-Add-ons in großen Clustern beschrieben.

Argumentname Rollen, Anzahl Knoten Beschreibung Bei zunehmender Clustergröße Risiken Empfehlung
amd-gpu-device-plugin.ContainerResources J

Definiert CPU- und Speicheranforderungen und -limits für die AMD GPU-Plug-in-Container.

Das Plugin wird auf jedem GPU-Knoten ausgeführt.

Die gesamte Ressourcennutzung wächst linear mit der Anzahl der GPU-Knoten.

Die folgenden Aktivitäten nehmen zu:

  • GPU-Zustandsüberwachung
  • Gerätestatusbericht an das Kubelet
  • Interaktionen mit der Containerlaufzeit

Wenn die Ressourcen zu klein sind:

  • Das Plug-in kann auf Knoten instabil werden.
  • GPUs werden möglicherweise nicht korrekt als amd.com/gpu -Ressourcen angegeben.
  • Pods, die GPUs anfordern, können den Status Pending aufweisen.
  • Ressourcen werden möglicherweise falsch an den Scheduler gemeldet.

Erhöhen Sie den auf jedem Knoten zugewiesenen Speicher und die CPU auf der Grundlage der folgenden Faktoren:

  • Die Anzahl der GPUs auf dem Knoten
  • Workload-Intensität

Überwachen Sie Kubelet-Logs und die CPU- und Speicherauslastung des Plug-ins.

nodeSelectors/affinity J

Steuert mithilfe von Labels, auf welchen Knoten das Plug-in ausgeführt wird.

Stellt sicher, dass das Plugin nur auf AMD-GPU-Knoten ausgeführt wird.

Verhindert unnötige Planung auf reinen CPU-Knoten.

Wenn kein Selektor angegeben ist, wird das Plug-in auf allen Knoten ausgeführt und verschwendet Ressourcen.

Wenn der falsche Selektor angegeben ist, wird das Plug-in nicht auf GPU-Knoten ausgeführt, und die GPUs sind für Kubernetes nicht sichtbar.

Selbst eine kleine Fehlkonfiguration, die sich auf 1–2% der Knoten auswirkt, kann zu Hunderten falsch konfigurierter Knoten, inkonsistenter GPU-Verfügbarkeit und unvorhersehbaren Planungsfehlern führen.

Strenge Knotenbeschriftung verwenden

tolerations J

Steuert, ob das Plug-in auf verfälschten GPU-Knoten ausgeführt werden kann.

Wenn die Konfiguration nicht korrekt ist, kann das AMD GPU Plugin DaemonSet möglicherweise nicht auf GPU-Knoten mit Taints geplant werden, wodurch verhindert wird, dass GPU-Ressourcen erkannt werden und GPUs für die Workload-Planung nicht verfügbar sind.

Wenn Toleranzen falsch konfiguriert sind, kann das Plug-in nicht auf GPU-Knoten ausgeführt werden, und die GPUs können nicht mehr verwendet werden.

Stellen Sie sicher, dass die Toleranzen mit den Taints übereinstimmen, die auf GPU-Knoten angewendet werden.

pulse J

Steuert, wie oft das Plug-in GPU-Zustandsinformationen an das Kubelet meldet.

Eine höhere Reportinghäufigkeit bietet bessere GPU-Zustandstransparenz, generiert jedoch mehr Kubelet- und API-Traffic.

Eine geringere Reportinghäufigkeit reduziert den Overhead, verzögert jedoch die Ausfallerkennung.

Wenn Updates zu häufig sind, erhöht sich der CPU-Overhead auf jedem Knoten und die Kubelet-Last.

Wenn Updates zu selten oder deaktiviert sind, können GPU-Zustandsinformationen veraltet werden, und der Scheduler kann fehlerhaften GPUs Workloads zuweisen.

Verwenden Sie ein moderates Intervall, das Gesundheitstransparenz gegen Gemeinkosten ausgleicht.

Vermeiden Sie übermäßig aggressives Polling.

rollingUpdate N

Steuert das Aktualisierungsverhalten.

In großen Clustern können viele Knoten gleichzeitig aktualisiert werden, was sich auf die GPU-Verfügbarkeit während Upgrades auswirkt.

  • GPU-Workloads werden möglicherweise unterbrochen.
  • GPUs sind möglicherweise vorübergehend nicht verfügbar.

Verwenden Sie kontrollierte Rolling-Updates, um weit verbreitete Störungen zu vermeiden.

numOfReplicas N

Dieses Argument wird vom AMD-GPU-Plug-in nicht verwendet.

Nicht anwendbar Nicht anwendbar Nicht anwendbar