Oracle Cloud Infrastructure - Dokumentation

Nativen OCI-Ingress-Controller in einem Kubernetes-Cluster einrichten

Erfahren Sie, wie Sie den nativen Ingress-Controller von OCI so einrichten, dass die in einer Kubernetes-Ingress-Ressource definierten Regeln und Konfigurationsoptionen implementiert werden, um eingehenden Traffic zu laden und an Service-Pods weiterzuleiten, die auf Worker-Knoten in einem Cluster ausgeführt werden.

Der native OCI-Ingress-Controller implementiert die in einer Kubernetes-Ingress-Ressource definierten Regeln und Konfigurationsoptionen, um eingehenden Traffic zu laden und an Servicepods weiterzuleiten, die auf Worker-Knoten in einem Cluster ausgeführt werden. Der native OCI-Ingress-Controller erstellt einen flexiblen OCI-Load Balancer zur Verarbeitung von Anforderungen und konfiguriert den OCI-Load Balancer so, dass Anforderungen gemäß den in der Ingress-Ressource definierten Regeln weitergeleitet werden. Wenn Änderungen an den Routingregeln oder an anderen unterstützenden Ressourcen vorgenommen werden, aktualisiert der native OCI-Ingress-Controller die Load-Balancer-Konfiguration entsprechend. Der native OCI-Ingress-Controller wird als einzelner Pod auf einem zufällig ausgewählten Worker-Knoten im Cluster ausgeführt.

Der native OCI-Ingress-Controller erstellt OCI-Load-Balancer-Ressourcen wie folgt:

  • Ein Load Balancer für jede IngressClass-Ressource, bei der Sie den nativen OCI-Ingress-Controller als Controller angegeben haben.
  • Ein Load-Balancer-Backend-Set für jede eindeutige Kombination aus Kubernetes-Servicename und Portnummer, die Sie in Routingregeln in Ingress-Ressourcen im Cluster aufnehmen.
  • Ein Load Balancer Listener für jeden eindeutigen Port, den Sie in Routingregeln in Ingress-Ressourcen im Cluster aufnehmen. Der native OCI-Ingress-Controller bestimmt das Protokoll (HTTP, HTTPS, HTTP/2) für jeden Listener basierend auf der Ingress-Backend-Konfiguration.

Der native OCI-Ingress-Controller fügt einem Backend-Set entweder die Pods, die als Endpunkte für den jeweiligen Kubernetes-Servicenamen und -port dienen, oder die Worker-Knoten, auf denen diese Pods ausgeführt werden können, je nach dem CNI-Plug-in, das das das Cluster für das Podnetzwerk verwendet:

  • Wenn das Cluster das CNI-Plug-in für das OCI-VCN-native Podnetzwerk für das Podnetzwerk verwendet, fügt der native OCI-Ingress-Controller die Pods als Backends hinzu.
  • Wenn das Cluster das Flannel-CNI-Plug-in für das Podnetzwerk verwendet, fügt der native OCI-Ingress-Controller die Worker-Knoten als Backends hinzu. In diesem Fall verwendet der native OCI-Ingress-Controller die Einstellung externalTrafficPolicy im Manifest des Service, um wie folgt zu bestimmen, welche Worker-Knoten zum Backend-Set hinzugefügt werden sollen:
    • Wenn Sie externalTrafficPolicy: Cluster verwenden, fügt der native OCI-Ingress-Controller dem Backend-Set alle Worker-Knoten im Cluster hinzu.
    • Wenn Sie externalTrafficPolicy: Local verwenden, fügt der native OCI-Ingress-Controller dem Backend-Set nur die Worker-Knoten hinzu, auf denen die Pods des Service bereitgestellt wurden.

Der native OCI-Ingress-Controller erstellt OCI-Load-Balancer-Ressourcen, die den normalen Load-Balancer-Servicelimits in Bezug auf die Gesamtanzahl der IP-Adressen, Backend-Sets, Listener und Backend-Server unterliegen. Weitere Informationen finden Sie unter Limits für Load Balancing-Ressourcen.

Sie können den nativen OCI-Ingress-Controller auf einem Kubernetes-Cluster auf eine oder andere der folgenden Arten bereitstellen:

Beachten Sie Folgendes, wenn Sie den nativen Ingress-Controller von OCI verwenden, um eingehenden Traffic auszugleichen und weiterzuleiten:

  • Wenn Sie den nativen OCI-Ingress-Controller als Standalone-Programm installieren, muss im Cluster Kubernetes-Version 1.26 oder höher ausgeführt werden. Wenn Sie den nativen OCI-Ingress-Controller als Cluster-Add-on installieren, muss im Cluster Kubernetes-Version 1.28 oder höher ausgeführt werden.
  • Für das Cluster müssen Sicherheitsregeln für Load-Balancer-Subnetze konfiguriert sein.
  • Das Cluster kann entweder das OCI-VCN-native Podnetworking-CNI-Plug-in oder das Flannel-CNI-Plug-in für Podnetworking verwenden. Beachten Sie, dass der native Ingress-Controller von OCI nur Backend-Services von type: NodePort unterstützt, wenn das Cluster das Flannel-CNI-Plug-in für Podnetworking verwendet, wie im Manifest des Service angegeben.
  • Die Verwendung von Instanz-Principals, damit der native OCI-Ingress-Controller auf OCI-Services und -Ressourcen zugreifen kann, wird in Clustern mit virtuellen Knoten nicht unterstützt.
  • Sie können Workload Identity Principals mit erweiterten Clustern angeben, jedoch nicht mit Basisclustern.
  • Wenn der native OCI-Ingress-Controller bereits als Standalone-Programm in einem Cluster bereitgestellt wurde, stellen Sie das OCI-native Ingress-Controllercluster-Add-on nicht auch im Cluster bereit.