Oracle Cloud Infrastructure - Dokumentation

Oracle Database Operator für Kubernetes

Wenn Sie das Cluster-Add-on für Oracle Database Operator for Kubernetes aktivieren, können Sie die folgenden Schlüssel/Wert-Paare als Argumente übergeben.

Um Oracle Database Operator als Cluster-Add-on zu verwenden, müssen Sie auch cert-manager bereitstellen (entweder als Standalone-Produkt oder als Cluster-Add-on). Wenn Sie cert-manager als Standalone-Produkt bereitstellen, setzen Sie das Konfigurationsargument skipAddonDependenciesCheck auf true.

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
manager.ContainerResources Managercontainerressourcen

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.
skipAddonDependenciesCheck skipAddonDependenciesCheck Gibt an, ob andere erforderliche Add-ons bereitgestellt wurden (z. B. das Add-on "cert-manager"). Optional Null true
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
manager.ContainerResources J

Definiert die CPU- und Speicheranforderungen und Grenzwerte für die Operatorpods.

Wenn die Clustergröße steigt, erlebt der Operator Folgendes:

  • Deutliches Wachstum im Informer Cache
  • Weitere Streams ansehen
  • Ein größerer Speicherbedarf
  • Weitere Abstimmungsaktivitäten

Wenn die Ressourcen zu klein sind:

  • Operatorpods werden möglicherweise beendet, weil sie ihre Speicherlimits überschreiten.
  • Die Abstimmungslatenz kann zunehmen.
  • Ein Rückstand in der Ereigniswarteschlange kann die Verarbeitung verzögern.

Weisen Sie ausreichend Arbeitsspeicher und CPU zu, um die zusätzliche Belastung in großen Clustern zu bewältigen. Achten Sie besonders auf die Speichergröße, da der Informer-Cache mit zunehmender Clustergröße wächst.

numOfReplicas N

Steuert die Anzahl der bereitgestellten Operatorpods.

Zusätzliche Replikate verbessern Fehlertoleranz und Failover durch Leaderwahl.

Nur ein Pod fungiert als aktiver Leader für einen Controller. Andere Replikate bleiben im Standby und übernehmen nur, wenn der Leader ausfällt.

Wenn Sie die Anzahl der Replikate erhöhen, wird der Reconciliation-Durchsatz nicht linear skaliert, da die Standby-Replikate keine Reconciliation-Schleifen für denselben Controller verarbeiten.

Eine geringe Anzahl von Replikaten erhöht das Risiko von Ausfallzeiten des Operators und verlangsamt das Recovery nach Ausfällen.

Verwenden Sie eine moderate Anzahl von Replikaten, z. B. drei bis fünf, um High Availability bereitzustellen. Erhöhen Sie nicht die Anzahl der Replikate, um die Abstimmungsperformance zu verbessern.

affinity / nodeSelectors / tolerations N

Steuern Sie, wo die Operatorpods im Cluster geplant werden.

Geeignete Pod-Platzierung:

  • Reduziert Störungen durch ressourcenintensive Workloads.
  • Hält den Bediener auf stabilen Knoten mit weniger Abwanderung und weniger Unterbrechungen.
  • Ermöglicht dem Bediener die Ausführung auf dedizierten oder High-Memory-Knoten, die für Control-Plane-Add-ons geeignet sind.
Wenn der Oracle Database-Operator nicht korrekt eingestellt ist, kann er auf den falschen Knoten landen oder gar nicht planen. Dies kann zu einer verzögerten Abstimmung und einer instabilen Performance führen.

Verwenden Sie diese Argumente, um Operatorpods auf dedizierten Infrastrukturknoten zu planen. Wenden Sie gegebenenfalls Pod-Anti-Affinitätsregeln an, um die Resilienz zu verbessern.

rollingUpdate N

Steuert die Deployment-Aktualisierungsstrategie für den Operator.

Bei Upgrades in großen Clustern gilt die Rolling Update-Strategie:

  • Verhindert Ausfallzeiten des Operators.
  • Behält die Verfügbarkeit von mindestens einigen Replikaten bei.
  • Verhindert, dass alle Replikate gleichzeitig beendet werden.

Wenn ein Upgrade nicht ordnungsgemäß konfiguriert ist, können zu viele Oracle Database Operator-Pods kurzzeitig heruntergefahren werden. Dies führt zu Verzögerungen bei der Abstimmung und dem Verlust der Failover-Sicherheit.

Konfigurieren Sie Einstellungen für Rolling-Updates, wie maxUnavailable und maxSurge , damit Upgrades abgeschlossen werden können, ohne Clustervorgänge zu unterbrechen.

topologySpreadConstraints N

Steuert, wie Operatorreplikate auf Knoten und Availability-Domains verteilt werden.

Durch die Verteilung von Replikaten wird verhindert, dass alle Operator-Pods auf demselben Knoten oder in derselben Availability-Domain ausgeführt werden, und die Auswirkungen von Knoten- oder Availability-Domainausfällen werden reduziert.

Wenn sie nicht korrekt konfiguriert sind, können Operator-Pods auf demselben Knoten oder in derselben Verfügbarkeitszone geplant werden, was das Risiko erhöht, dass mehrere Replikate bei einem Knoten- oder Zonenfehler verloren gehen.

Verwenden Sie Topologie-Verteilungs-Constraints, um High Availability in großen Clustern bereitzustellen.