Oracle Cloud Infrastructure - Dokumentation

Knotenfeature-Discovery

Wenn Sie das Cluster-Add-on "Node Feature Discovery" 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 Beispielwert
master.tolerations Toleranzen für nfd master Benutzerdefinierte Toleranzen für NFD-Masterpods. Optional 
[{"key":"node-role.kubernetes.io/master","operator":"Equal","effect":"NoSchedule"},{"key":"node-role.kubernetes.io/control-plane","operator":"Equal","effect":"NoSchedule"}]
master.affinity Affinität für nfd master Knotenaffinitätsregeln für die Planung von NFD-Pods. Optional 
{"nodeAffinity":{"preferredDuringSchedulingIgnoredDuringExecution":[{"weight":1,"preference":{"matchExpressions":[{"key":"node-role.kubernetes.io/master","operator":"In","values":[""]}]}},{"weight":1,"preference":{"matchExpressions":[{"key":"node-role.kubernetes.io/control-plane","operator":"In","values":[""]}]}}]}}
master.config Konfiguration für nfd-Master

Zusätzliche Masterkonfiguration zum Zusammenführen in nfd-master.conf.

YAML- oder JSON-Format im Klartext.

 Optional null
master.resources Ressourcen für nfd-Master Ressourcenanforderungen und -limits für den NFD-Mastercontainer. JSON-Format im Klartext. Optional null
master.replicaCount replicaCount für nfd-Master Anzahl der Replikate für das NFD-Master-Deployment. Optional null
master.extraArgs extraArgs für nfd-Master

Zusätzliche Befehlszeilenargumente für den NFD-Mastercontainer.

JSON-Arrayformat im Klartext.

 Optional null
master.annotations Anmerkungen für nfd-Master-Pods Anmerkungen zum Zusammenführen in die NFD-Master-Pod-Vorlage. Optional null
priorityClassName priorClassName für nfd-Deployments PriorityClassName für die NFD-Master- und GC-Deployments. Optional null
worker.config Konfiguration für nfd Worker

Zusätzliche Worker-Konfiguration zum Zusammenführen in nfd-worker.conf.

YAML- oder JSON-Format im Klartext.

 Optional null
worker.resources Ressourcen für nfd-Worker Ressourcenanforderungen und -limits für den NFD-Worker-Container. JSON-Format im Klartext. Optional null
worker.tolerations Toleranzen für nfd-Arbeitnehmer Zusätzliche Toleranzen zum Anhängen an die NFD-Worker-Pods. Optional null
worker.nodeSelector nodeSelector für nfd-Worker Knotenselektorlabels zum Zusammenführen in das NFD-Worker-DaemonSet. Optional null
worker.priorityClassName priorClassName für nfd-Worker PriorityClassName für das DaemonSet des NFD-Workers. Optional null
worker.extraArgs extraArgs für nfd-Mitarbeiter

Zusätzliche Befehlszeilenargumente für den NFD Worker Container.

JSON-Arrayformat im Klartext.

 Optional null
worker.annotations Anmerkungen für nfd-Worker-Pods Anmerkungen zum Zusammenführen in die NFD-Worker-Podvorlage. Optional null
master.customConfigData Benutzerdefinierte NFD-Masterkonfigurationsdaten

Geben Sie Inhalt für das ConfigMap-Objekt node-feature-discovery-master-custom-conf an.

Falls vorhanden, wird es automatisch montiert.

 Optional ""
worker.customConfigData Benutzerdefinierte NFD-Worker-Konfigurationsdaten

Geben Sie Inhalt für das ConfigMap-Objekt node-feature-discovery-worker-custom-conf an.

Falls vorhanden, wird es automatisch montiert.

 Optional ""
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
master.tolerations J

Steuert, ob Master-Pods für Knotenfeature Discovery auf verfälschten Control-Plane- oder Infrastrukturknoten ausgeführt werden können.

  • Stellt sicher, dass der Node Feature Discovery-Master auf stabilen Control-Plane- oder Infrastructure-Knoten ausgeführt wird.
  • Verhindert, dass der Master auf Worker-Knoten mit hoher Arbeitslastaktivität ausgeführt wird.
  • Verbessert die Zuverlässigkeit der Knotenbeschriftung im gesamten Cluster.

Wenn dieses Argument falsch konfiguriert ist:

  • Der Master-Pod bleibt möglicherweise im Status Pending , da er die Knoten-Taints nicht tolerieren kann.
  • Der Master-Pod kann auf Worker-Knoten ausgeführt werden und instabil werden.
  • Labelupdates im gesamten Cluster können verzögert oder inkonsistent sein.
  • Nehmen Sie immer Tolerierungen für Control-Plane-Taints auf.
  • Stellen Sie sicher, dass der Master auf stabilen Knoten ausgeführt wird.
  • Kombinieren Sie Toleranzen mit Affinitätsregeln, um die Podplatzierung zu kontrollieren.
master.affinity J

Definiert die bevorzugte Knotenplatzierung für Node Feature Discovery-Masterpods.

  • Behält den Master auf dedizierten Control-Plane- oder Infrastructure-Knoten.
  • Reduziert Störungen durch Anwendungs-Workloads.
  • Verbessert die Konsistenz von Node Labeling-Vorgängen.

Wenn dieses Argument falsch konfiguriert ist:

  • Der Master kann auf Worker-Knoten ausgeführt werden.
  • Es können mehrere Replikate auf demselben Knoten ausgeführt werden, wodurch die High Availability reduziert wird.
  • Die Knotenbeschriftung kann langsamer oder inkonsistent sein.
  • Verwenden Sie Affinitätsregeln, um Control-Plane- oder Infrastructure-Knoten zu bevorzugen.
  • Fügen Sie Anti-Affinitätsregeln hinzu, wenn Sie mehrere Replikate verwenden.
  • Behandeln Sie die Masterplatzierung als Teil des Cluster Control Plane Designs.
master.customConfigData N

Aktiviert die benutzerdefinierte Konfiguration für den Node Feature Discovery-Master.

Die Konfiguration steuert, wie Knotenfunktionen verarbeitet und beschriftet werden. Es wirkt sich auf:

  • Die Anzahl der generierten Labels
  • Häufigkeit von Labelupdates

Wenn dieses Argument falsch konfiguriert ist:

  • Möglicherweise werden übermäßige oder falsche Labels generiert.
  • Häufige Labeländerungen können die Last auf dem Kubernetes-API-Server erhöhen.
  • Die Featureerkennung ist möglicherweise inkonsistent über Knoten hinweg.
  • Halten Sie die Konfiguration minimal.
  • Konfigurieren Sie nur die erforderlichen Funktionen.
  • Validieren Sie die Konfiguration auf einer kleinen Teilmenge von Knoten, bevor Sie sie im gesamten Cluster anwenden.
worker.customConfigData N

Steuert die benutzerdefinierte Funktionserkennungslogik auf jedem Knoten.

Der Node Feature Discovery Worker wird auf jedem Knoten als DaemonSet ausgeführt. Jede zusätzliche Erkennungslogik wird daher auf jedem Knoten ausgeführt.

Benutzerdefinierte Erkennungslogik kann sich auf Folgendes auswirken:

  • Knoten-CPU-Auslastung
  • Labelinghäufigkeit
  • Clusterweite Labelingkonsistenz

Wenn dieses Argument falsch konfiguriert ist:

  • Die CPU-Auslastung kann sich auf Knoten erhöhen.
  • Labels sind möglicherweise falsch oder inkonsistent.
  • Häufige Labelupdates können den Druck auf den Kubernetes-API-Server erhöhen.
  • Die Workload-Planung kann betroffen sein.
  • Leichte Worker-Konfiguration beibehalten.
  • Vermeiden Sie eine ressourcenintensive Erkennungslogik.
  • Validieren Sie Labels, bevor Sie die Konfiguration im gesamten Cluster aktivieren.
  • Überwachen Sie die Knotenressourcenverwendung.