Oracle Cloud Infrastructure - Dokumentation

Nativer OCI-Ingress-Controller

Wenn Sie das native OCI-Ingress-Controller-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 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
authSecretName authSecretName Der Name des Kubernetes-Secrets, das für die Benutzerauthentifizierung verwendet werden soll, wenn authType auf user gesetzt ist. Optional "" oci-config
authType authType Der Authentifizierungstyp, den der native OCI-Ingress-Controller beim Erstellen von Anforderungen verwendet, als einer der folgenden:
  • instance gibt Instanz-Principal an (nur verwaltete Knoten)
  • user gibt den Benutzer-Principal an (verwaltete und virtuelle Knoten)
  • workloadIdentity gibt Workload-Identität an (verwaltete und virtuelle Knoten)
 Optional instance workloadIdentity
certDeletionGracePeriodInDays certDeletionGracePeriodInDays

Die Anzahl der Tage, die der native OCI-Ingress-Controller wartet, bevor nicht verwendete OCI Certificates-Serviceressourcen gelöscht werden. Gilt, wenn der native OCI-Ingress-Controller ein Zertifikat mit einem Kubernetes-Secret vom Certificates-Service abruft.

Muss ein Ganzzahlwert sein. Wenn der Wert kleiner oder gleich Null ist, löscht der native OCI-Ingress-Controller keine nicht verwendeten OCI Certificates-Serviceressourcen.

 Optional 0 1
compartmentId compartmentId Die OCID des Compartments, in dem der native OCI-Ingress-Controller den OCI-Load Balancer erstellen soll (und das Zertifikat, wenn das Add-on-Argument useLbCompartmentForCertificates auf false gesetzt ist). Erforderlich "" ocid1.compartment.oc1..aaaaaaaa______ddq
controllerClass controllerClass Der Name des Controllers, der in Ihrer ingressClass angegeben ist und vom OCI-native-ingress-controller verwaltet werden soll. Optional oci.oraclecloud.com/native-ingress-controller oci.oraclecloud.com/native-ingress-controller
emitEvents emitEvents

Gibt an, ob Kubernetes-Ereignisse für Ingress- und IngressClass-Fehler ausgegeben werden sollen, die während der Abstimmung beobachtet wurden.

Wenn dieser Wert auf true gesetzt ist, werden Ereignisse ausgegeben.

 Optional false false
leaseLockName leaseLockName Der Name des Leasingverhältnisses, das für die Leaderwahl verwendet werden soll. Optional oci-native-ingress-controller oci-native-ingress-controller
leaseLockNamespace leaseLockNamespace Der Namespace des Leasingverhältnisses. Optional native-ingress-controller-system native-ingress-controller-system
loadBalancerSubnetId loadBalancerSubnetId Die OCID des Subnetzes des Load Balancers. Erforderlich "" ocid1.subnet.oc1.iad.aaaaaaaa______dba
logVerbosity logVerbosity Die Zahl für den Ausführlichkeitsgrad des Protokolls. Optional 4 2
metricsBackend metricsBackend Der Name des Metrik-Backends. Optional prometheus prometheus
metricsPort metricsPort Der Metrikport. Optional 2223 2223
oci-native-ingress-controller.ContainerResources native Containerressourcen für Ingress-Controller

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.
useLbCompartmentForCertificates useLbCompartmentForCertificates

Gibt an, ob das für den OCI-Load Balancer angegebene Compartment (in der zugehörigen IngressClassParameters-Ressource) zum Verwalten von OCI Certificates-Serviceressourcen verwendet werden soll, wenn ein Kubernetes-Secret zum Abrufen eines Zertifikats und eines CA-Bundles verwendet wird. Siehe Option 1: OCI Native Ingress Controller ruft das Zertifikat mit einem Kubernetes-Secret vom Certificates-Service ab.

Wenn dieser Wert auf false gesetzt ist, wird das durch das Add-on-Argument compartmentId angegebene Compartment verwendet.

 Optional false 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
affinity N

Steuert die Platzierung von Native Ingress Controller-Pods basierend auf Podaffinitäts- und Pod-Antiaffinitätsregeln.

Nicht anwendbar Nicht anwendbar Nicht anwendbar
nodeSelectors N

Steuert die Platzierung nativer Ingress-Controller-Pods basierend auf Knotenlabels.

Nicht anwendbar Nicht anwendbar Nicht anwendbar
numOfReplicas N

Steuert die Anzahl der Replikate im Deployment des nativen Ingress-Controllers.

Nicht anwendbar Nicht anwendbar Nicht anwendbar
rollingUpdate N

Steuert die Deployment-Aktualisierungsstrategie, einschließlich Einstellungen wie maxSurge und maxUnavailable .

Nicht anwendbar Nicht anwendbar Nicht anwendbar
tolerations N

Steuert, ob native Ingress-Controller-Pods auf befleckten Knoten ausgeführt werden können.

Nicht anwendbar Nicht anwendbar Nicht anwendbar
topologySpreadConstraints N

Steuert, wie übereinstimmende native Ingress-Controller-Pods über die Clustertopologie verteilt werden, indem Einstellungen wie maxSkew und minDomains verwendet werden.

Nicht anwendbar Nicht anwendbar Nicht anwendbar
oci-native-ingress-controller.ContainerResources J

Definiert CPU- und Speicheranforderungen und Grenzwerte für den nativen Ingress-Controller-Pod.

Der Controller prüft Knoten, um verfügbare Load-Balancer-Backends zu identifizieren. Die CPU- und Speicherauslastung steigt daher mit zunehmender Anzahl von Knoten.

Wenn externalTrafficPolicy auf Cluster gesetzt ist, kann der Knoteninformercache Backend-Informationen für jeden Knoten enthalten. In einem Cluster mit ca. 20.000 Knoten kann die Verarbeitung von Backend-Informationen während jedes Synchronisierungszyklus zu einem Ressourcenengpass werden.

Wenn externalTrafficPolicy auf Local gesetzt ist, ist das Backend-Synchronisierungs-Volume wesentlich niedriger, da nur Knoten mit lokalen Backends enthalten sind.

  • Backend-Reconciliation kann zu erheblichem CPU- und Speicherdruck führen.
  • Die Synchronisierungszyklen können langsam werden, wenn der Controller Backend-Informationen über Tausende von Knoten verarbeitet.
  • Wenn eine Backend-Anforderung das Load-Balancer-Limit von 512 Backends überschreitet, lehnt die Load-Balancer-Control Plane das Update ab.
  • Wiederholt abgelehnte Updates können veraltete Backends auf dem Load Balancer konfigurieren lassen.

Hohe CPU und Grenzwert werden erwartet, wenn externalTrafficPolicy auf Cluster gesetzt ist. Moderat erforderlich, wenn externalTrafficPolicy auf Local gesetzt ist. Mit Local werden Health Checks für externe Traffic-Policys auf Knoten oder Pods mit lokalen Backends bis zum Load-Balancer-Backend-Limit eingeschränkt.
routingStrategies.hostBasedRouting N

Leitet Anforderungen basierend auf dem Domainnamen in der Anforderung an einen Service weiter.

Nicht anwendbar Nicht anwendbar Nicht anwendbar
routingStrategies.pathBasedRouting N

Leitet Anforderungen basierend auf dem Anforderungspfad oder API-Endpunkt an einen Service weiter.

Nicht anwendbar Nicht anwendbar Nicht anwendbar
routingStrategies.defaultRouting N

Leitet Anforderungen, die nicht mit einer anderen Regel übereinstimmen, an den Standard-Backend-Service weiter.

Nicht anwendbar Nicht anwendbar Nicht anwendbar
NIC annotations J

Konfigurieren Sie den nativen Ingress-Controller und das Load-Balancer-Verhalten, einschließlich Einstellungen für die Backend-Integritätsprüfung.

Die Routing-Performance des Load Balancers bleibt durch die maximale Anzahl von 512 Backends und nicht durch die Gesamtanzahl von Clusterknoten eingeschränkt.

Die ausgewählte externe Traffic-Policy wirkt sich jedoch auf die Ressourcennutzung des Controllers aus:

  • Mit externalTrafficPolicy: Cluster können Health Checks über alle Clusterknoten verteilt werden, wodurch ein erheblicher Overhead in einem Cluster mit etwa 20.000 Knoten entsteht.
  • Mit externalTrafficPolicy: Local werden Health Checks auf Knoten oder Pods mit lokalen Backends bis zum Load-Balancer-Backend-Limit eingeschränkt.
  • Clusterweites Health Check Fan-out kann die CPU- und Speicherauslastung erheblich erhöhen.
  • Wenn Sie die Health-Check-Konfiguration aktualisieren, kann der Controller Backend-Pods im gesamten Cluster neu bewerten.
  • CPU- und Speicherkonflikte können auch auftreten, wenn externalTrafficPolicy auf Local gesetzt ist.

Weitere Informationen finden Sie in den Best Practices für Load Balancer und Backend Health Check.