NVIDIA-Netzwerkbetreiber

Wenn Sie das NVIDIA Network Operator-Cluster-Add-on aktivieren, können Sie die folgenden Schlüssel/Wert-Paare als Argumente übergeben.

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`	numOfReplikate	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`	rollierende Aktualisierung	Steuert das gewünschte Verhalten der Rolling-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`	TopologieSpreadConstraints	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
`operator.nodeSelectors`	nvidia-network-operator nodeSelektoren	Knotenselektoren auf den NVIDIA Network Operator-Pods.	Optional	`null`
`operator.tolerations`	Toleranz nvidia-network-operator	Toleranzen auf den NVIDIA Network Operator-Pods.	Optional	`null`
`nicClusterPolicy.tolerations`	nicClusterPolicy-Toleranzen	Von NicClusterPolicy verwaltete Toleranzen für DaemonSets.	Optional	`null`
`nicClusterPolicy.deploymentTolerations`	nicClusterPolicy-DeploymentToleranzen	Von NicClusterPolicy verwaltete Toleranzen für Deployments.	Optional	`null`
`operator.affinity`	nvidia-network-operator-affinität	Affinitätsplanungsregeln für NVIDIA Network Operator. JSON-Format im Klartext.	Optional	`null`
`operator.resources`	nvidia-network-operator Containerressourcen	NVIDIA Network Operator-Ressourcen steuern die Ressourcenlimits und Anforderungen für den Container `nvidia-network-operator`. JSON-Format im Klartext.	Optional	`{"limits": {"cpu": "500m", "memory": "128Mi"}, "requests": {"cpu": "5m", "memory": "64Mi"}}`
`operator.cniBinDirectory`	cniBinVerzeichnis	CNI-Binärverzeichnis für NVIDIA Network Operator.	Optional	`/opt/cni/bin`
`operator.cniNetworkDirectory`	cniNetworkDirectory	CNI-Netzwerkverzeichnis für NVIDIA Network Operator.	Optional	`/etc/cni/net.d`
`operator.admissionControllers.enabled`	operator.admissionControllers.enabled	Zulassungscontroller für NVIDIA Network Operator aktivieren.	Optional	`false`
`sriovNetworkOperator.enabled`	sriovNetworkOperator.enabled	Aktivieren Sie den NVIDIA-Netzwerkoperator SR-IOV.	Optional	`false`
`sriov-network-operator.operator.resourcePrefix`	sriov-network-operator.operator.resourcePrefix	Ressourcenpräfix für Ressourcen, die vom SR-IOV-Netzwerkoperator erstellt wurden.	Optional	`nvidia.com`
`sriov-network-operator.operator.admissionControllers.enabled`	sriov-network-operator.operator.admissionControllers.enabled	Zulassungscontroller für SR-IOV-Netzwerkbetreiber aktivieren	Optional	`false`
`sriov-network-operator.operator.sriovOperatorConfig.configDaemonNodeSelectors`	sriov-network-operator.operator.sriovOperatorConfig.configDaemonNodeSelectors	Konfigurieren Sie `configDaemonNodeSelector` für `sriovOperatorConfig`.	Optional	`{"beta.kubernetes.io/os": "linux", "network.nvidia.com/operator.mofed.wait": "false"}`
`vfCreationMode`	vfCreationModus	Modus für die VF-Erstellung. Gültige Werte sind `sriovNetworkOperator` und `custom`.	Optional	`custom`
`customizeVfCreationConfigMap`	anpassenVfCreationConfigMap	Geben Sie an, ob das Erstellen des `vf-shape-config`-ConfigMap übersprungen werden soll.	Optional	`false`
`skipNodeFeatureDiscoveryDependencyCheck`	skipNFDDependencyCheck	Überspringen Sie die Abhängigkeitsprüfung für die Knotenfeature-Discovery.	Optional	`false`

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
`operator.nodeSelectors`	J	Steuert, wo die NVIDIA-Netzwerkoperator-Pods geplant sind.	Verfügt über eine stabile Infrastruktur oder Control-Plane-Knoten. Verhindert, dass der Operator mit Workloads auf ausgelasteten Worker-Knoten konkurriert. Hilft, die Netzwerkregelschleife vorhersagbar zu halten, wenn das Cluster viele Knoten und häufige Knotenstatusänderungen aufweist.	Wenn dieses Argument falsch konfiguriert ist: Der Operator kann auf überladenen Worker-Knoten ausgeführt werden. Der Operatorpod bleibt möglicherweise im Status `Pending` , wenn der Selektor zu restriktiv oder falsch ist. Die netzwerkbezogene Abstimmung kann langsam oder inkonsistent werden, wenn der Operator instabil ist.	Planen Sie den Operator auf dedizierten Infrastrukturknoten. Nutzung eines einfachen und zuverlässigen Selektors. Vermeiden Sie Worker-Pools mit häufigen Workload-Änderungen.
`operator.tolerations`	J	Steuert Toleranzen für die NVIDIA-Netzwerkoperator-Pods und zugehörigen DaemonSets.	Ermöglicht dem Operator und seinen DaemonSets die Ausführung auf verfälschten Infrastrukturknoten. Verhindert Platzierungsfehler auf Control-Plane- oder dedizierten Netzwerkknoten. Unterstützt Isolation, wenn GPU- oder Netzwerkknoten verfälscht sind.	Wenn dieses Argument falsch konfiguriert ist: Der Operator oder seine DaemonSets können auf befleckten Knoten im Status `Pending` verbleiben. SR-IOV-, Treiber- oder CNI-Komponenten werden möglicherweise nicht auf den erforderlichen Knoten ausgeführt. Einige Knoten erhalten möglicherweise nie die erforderlichen Netzwerkfunktionen.	Toleranzen mit den in den Knotenpools verwendeten Taints abgleichen. Verwenden Sie konsistente Toleranzen für vom Operator verwaltete DaemonSets. Testen Sie die Konfiguration erneut, nachdem Sie die Policys für die Knotenbeibehaltung geändert haben.
`operator.affinity`	J	Steuert Knotenaffinitätsregeln für die NVIDIA-Netzwerkoperator-Pods.	Behält den Operator auf der entsprechenden Knotenklasse bei. Reduziert die Wahrscheinlichkeit, dass der Operator von einer Abwanderung auf dem Worker-Knoten betroffen ist. Ermöglicht dem Betreiber, nahe an einer stabilen Netzwerkinfrastruktur zu arbeiten.	Wenn dieses Argument falsch konfiguriert ist: Der Operator kann auf unangemessenen Knoten geplant werden. Wenn die Regel zu restriktiv ist, bleibt der Operator möglicherweise im Status `Pending` . Wenn die Regel zu breit ist, bietet die Platzierung möglicherweise nicht die beabsichtigte Resilienz.	Verwenden Sie Affinitätsregeln, um stabile Knoten zu bevorzugen. Halten Sie die Regeln einfach, es sei denn, Einschränkungen mit mehreren Zonen oder Pools sind erforderlich. Kombinieren Sie bei Bedarf Affinitätsregeln mit Toleranzen.
`operator.resources`	J	Definiert CPU- und Speicheranforderungen und Grenzwerte für den NVIDIA Network Operator-Container.	Der Operator koordiniert Netzwerkressourcen im gesamten Cluster. Je mehr Knoten vorhanden sind, desto mehr Objekte, Knotenstatusänderungen und Reconciliation-Vorgänge müssen verarbeitet werden. Der Operator hängt auch von Knotenfeature-Discovery-Labels ab, um zu bestimmen, welche Knoten Netzwerkkomponenten erfordern.	Wenn die Ressourcen zu klein sind: Die Abstimmung kann langsam sein. Rollouts der Netzwerksoftware können verzögert werden. Der Operator kann bei häufigen Knotenänderungen oder Konfigurationsupdates instabil werden.	Erhöhen Sie CPU- und Speicherressourcen für Cluster mit häufigen Knotenänderungen oder vielen benutzerdefinierten Netzwerkressourcen. Überwachen Sie die CPU-Auslastung des Operators, die Speicherauslastung und die Reconciliation-Latenz. Behandeln Sie dieses Argument als Einstellung für die Skalierung auf Steuerebene.
`operator.cniBinDirectory`	N	Steuert das Verzeichnis auf Knoten, auf denen CNI-Binärdateien bereitgestellt werden.	Die CNI-Binärdateien müssen in dem Verzeichnis bereitgestellt werden, das von der Containerlaufzeit verwendet wird. Ein falscher Pfad kann viele Knoten gleichzeitig beeinflussen.	Wenn dieses Argument falsch konfiguriert ist: Pods werden möglicherweise erstellt, Networking ist jedoch möglicherweise nicht verfügbar. CNI-Binärdateien können im falschen Hostpfad bereitgestellt werden. Das Cluster wird möglicherweise konfiguriert, obwohl das Networking nicht funktioniert.	Halten Sie den Wert an der Standardeinstellung der Knotenlaufzeit ausgerichtet. Ändern Sie den Wert nur, wenn die Containerlaufzeit ein anderes CNI-Binärverzeichnis verwendet. Überprüfen Sie den Pfad in einem einzelnen Knotenpool, bevor Sie ihn weitgehend anwenden.
`operator.cniNetworkDirectory`	N	Steuert das Hostverzeichnis, in dem CNI-Konfigurationsdateien bereitgestellt werden.	Die CNI-Konfigurationsdateien müssen im Verzeichnis abgelegt werden, das vom Kubelet oder der Containerlaufzeit gelesen wird. Ein falsches Verzeichnis kann sich auf jeden Knoten auswirken, der die Konfiguration verwendet.	Wenn dieses Argument falsch konfiguriert ist: CNI-Konfigurationsdateien können in einem Verzeichnis bereitgestellt werden, das vom Kubelet oder der Containerlaufzeit nicht gelesen wird. Knoten werden möglicherweise konfiguriert, auch wenn sekundäres Netzwerk nicht funktioniert. Die Fehlerbehebung kann schwierig sein, da der Operator trotz nicht übereinstimmender Pfade fehlerhaft angezeigt werden kann.	Richten Sie den Wert an dem CNI-Konfigurationsverzeichnis aus, das von der Knotenlaufzeit verwendet wird. Behandeln Sie das Argument als Host-Laufzeiteinstellung und nicht als Cluster-Policy-Einstellung. Validieren Sie die Dateiplatzierung auf einem einzelnen GPU- oder Netzwerkknoten, bevor Sie sie weitgehend anwenden.
`operator.admissionControllers.enabled`	N	Steuert, ob der NVIDIA-Netzwerkoperator seinen Zulassungscontroller bereitstellt.	Der Zulassungscontroller verhindert, dass eine ungültige Konfiguration in das Cluster eintritt. Dies wird wichtiger, wenn viele Benutzer oder Automatisierungssysteme benutzerdefinierte Netzwerkressourcen erstellen.	Wenn der Zulassungscontroller deaktiviert ist: Ungültige SR-IOV-, Netzwerk-Policy- oder NIC-Konfiguration werden möglicherweise akzeptiert. Ungültige Einstellungen können auf viele Knoten angewendet werden, bevor das Problem erkannt wird. Das operative Risiko steigt in großen Clustern.	Aktivieren Sie den Zulassungscontroller in Produktionsumgebungen. Stellen Sie sicher, dass der Zertifikatsmanager fehlerfrei bleibt, wenn der Webhook generierte Zertifikate verwendet.
`sriovNetworkOperator.enabled`	N	Steuert, ob der SR-IOV-Netzwerkoperator bereitgestellt wird.	Der SR-IOV-Netzwerkoperator stellt die SR-IOV-Komponenten bereit, die für virtuelle funktionsbasierte, leistungsstarke Netzwerke erforderlich sind, einschließlich einiger RDMA- und GPUDirect RDMA-Konfigurationen.	Wenn der SR-IOV-Netzwerkoperator bei Bedarf deaktiviert ist: SR-IOV-Funktionen werden nicht bereitgestellt. Knoten stellen möglicherweise nicht die Netzwerkressourcen bereit, die für Workloads erforderlich sind. GPU- und RDMA-Netzwerkpfade bleiben möglicherweise unvollständig.	Aktivieren Sie den SR-IOV-Netzwerkoperator nur, wenn für das Cluster SR-IOV erforderlich ist. Lassen Sie es in Clustern deaktiviert, die kein virtuelles funktionsbasiertes Networking verwenden. Wenn diese Option aktiviert ist, behandeln Sie sie als grundlegende Netzwerkkomponente.
`sriov-network-operator.operator.resourcePrefix`	N	Legt das Präfix für Ressourcen fest, die vom SR-IOV-Netzwerkoperator erstellt wurden.	Das Präfix bestimmt die erweiterten Ressourcennamen, die Kubernetes und Workloads verwenden. Wenn Sie das Präfix ändern, müssen alle Workload-Manifeste die neuen Ressourcennamen verwenden.	Wenn dieses Argument falsch konfiguriert ist: Workloads können einen falschen erweiterten Ressourcennamen anfordern. Pods können im Status `Pending` verbleiben, da der Scheduler nicht mit der angeforderten Ressource übereinstimmen kann. Alte und neue Ressourcennamenskonventionen können inkonsistent verwendet werden.	Behalten Sie den Standardwert bei, es sei denn, eine alternative Benennungs-Policy ist erforderlich. Ändern Sie das Präfix nicht beiläufig in einem laufenden Cluster. Stellen Sie sicher, dass Workload-Manifeste dasselbe Präfix verwenden.
`sriov-network-operator.operator.admissionControllers.enabled`	J	Steuert die SR-IOV-Netzwerkoperator-Zulassungscontroller.	Die Zulassungscontroller erkennen eine ungültige SR-IOV-Konfiguration, bevor sie Knoten erreicht, und helfen dabei, die virtuellen Funktions- und NIC-Einstellungen konsistent zu halten, wenn die Anzahl der Knotengruppen und Policys steigt.	Wenn die Zulassungscontroller deaktiviert sind: Möglicherweise wurde eine ungültige SR-IOV-Konfiguration angewendet. Fehlkonfigurationen können auf viele Knoten verteilt sein. Die Wiederherstellung nach Konfigurationsfehlern kann schwieriger sein.	Aktivieren Sie Zulassungscontroller in Produktionsumgebungen. Stellen Sie sicher, dass der Zertifikatsmanager und die Verarbeitung von Webhook-Zertifikaten fehlerfrei bleiben. Deaktivieren Sie die Zulassungscontroller nur, wenn es einen bestimmten Grund gibt, Aufnahme-Webhooks zu vermeiden.
`sriov-network-operator.operator.sriovOperatorConfig.configDaemonNodeSelectors`	J	Wählt die Knoten, die vom SR-IOV-Konfigurations-Daemon konfiguriert werden.	Der Selektor bestimmt, welche Knoten eine SR-IOV-Konfiguration erhalten. In einem großen Cluster kann sich ein falscher Selektor auf Hunderte oder Tausende von Knoten auswirken.	Wenn dieses Argument falsch konfiguriert ist: Die SR-IOV-Konfiguration kann auf die falschen Knoten angewendet werden. Beabsichtigte Knoten erhalten die Konfiguration möglicherweise nicht. Netzwerkfunktionen können über Knotenpools hinweg inkonsistent werden.	Richten Sie den Selektor eng an den Knotenlabels aus, die von Node Feature Discovery erstellt werden. Testen Sie den Selektor auf einer kleinen Knotengruppe, bevor Sie ihn weitgehend anwenden.
`vfCreationMode`	N	Legt fest, ob die Erstellung virtueller Funktionen automatisch vom Operator oder durch benutzerdefinierte Logik verwaltet wird.	Ein automatisierter und konsistenter Erstellungsprozess für virtuelle Funktionen reduziert Konfigurationsunterschiede zwischen Knoten. Die benutzerdefinierte Erstellungslogik bietet mehr Flexibilität, erhöht jedoch die Wahrscheinlichkeit einer inkonsistenten Knotenkonfiguration.	Wenn dieses Argument falsch konfiguriert ist: Virtuelle Funktionen werden möglicherweise nicht auf den erwarteten Knoten erstellt. Knotenpools verhalten sich möglicherweise anders. Die Netzwerkkonfiguration kann im Laufe der Zeit abweichen.	Erstellen Sie vom Operator verwaltete virtuelle Funktionen, es sei denn, benutzerdefinierte Logik ist erforderlich. Vermeiden Sie das Mischen von Erstellungsmodi innerhalb derselben Betriebsdomäne. Validieren Sie die Erstellung virtueller Funktionen in einem einzelnen Knotenpool, bevor Sie sie weitgehend anwenden.
`skipNodeFeatureDiscoveryDependencyCheck`	J	Legt fest, ob der Operator die Abhängigkeitsprüfung für die Knotenfeature-Discovery überspringt.	Durch das Überspringen der Prüfung wird die Validierung redundanter Abhängigkeiten vermieden, wenn die Knotenfeature Discovery separat verwaltet wird. Der Clusteradministrator ist jedoch dafür verantwortlich, sicherzustellen, dass die erforderlichen Knotenlabels verfügbar sind und korrekt bleiben.	Wenn dieses Argument falsch konfiguriert ist: Der Operator hängt möglicherweise von der Knotenfeature-Discovery ab, auch wenn er nicht installiert oder fehlerfrei ist. Erforderliche Labels fehlen möglicherweise. Falsche Knoten-Targeting für SR-IOV und zugehörige Komponenten können viele Knoten betreffen.	Überspringen Sie die Abhängigkeitsprüfung nur, wenn das Knotenfeature Discovery bereits bereitgestellt und verifiziert ist. Vergewissern Sie sich, dass die erforderlichen Labels auf den gewünschten Knoten vorhanden sind, bevor Sie den NVIDIA-Netzwerkoperator aktivieren.

Oracle Cloud Infrastructure - Dokumentation

NVIDIA-Netzwerkbetreiber