NGINX Plus als externen Load Balancer für Red Hat OCP und Kubernetes konfigurieren

NGINX | 24. Juli 2020

In der Welt der Container-Orchestrierung begegnen uns immer wieder zwei Namen: Red Hat OpenShift Container Platform (OCP) und Kubernetes. Wie Sie wahrscheinlich wissen, basiert OpenShift auf Kubernetes, ebenso wie viele andere Plattformen zur Container-Orchestrierung. Die Weiterleitung von externem Datenverkehr in eine Kubernetes- oder OpenShift-Umgebung war schon immer in zweierlei Hinsicht eine gewisse Herausforderung:

In Kubernetes bereitgestellte Dienste für die Außenwelt zugänglich machen. Die Lösung ist ein Ingress-Controller wie der NGINX Plus Ingress Controller. Weitere Informationen dazu finden Sie in unserem Blogbeitrag „Erste Schritte mit dem NGINX Ingress Operator auf Red Hat OpenShift“.
Lastverteilung des Datenverkehrs auf Ihre Kubernetes-Knoten. Zur Lösung dieses Problems entscheiden sich Unternehmen in der Regel für einen externen hardwarebasierten oder virtuellen Load Balancer oder eine cloudnative Lösung. NGINX Plus kann jedoch auch als externer Load Balancer eingesetzt werden, um die Leistung zu verbessern und Ihre Technologieinvestitionen zu vereinfachen.

In diesem Blog konzentriere ich mich darauf, wie sich das zweite Problem mit NGINX Plus auf einfache und effiziente Weise lösen lässt, sodass Ihre Anwendungsentwicklungsteams sowohl die Ingress-Konfiguration innerhalb von Kubernetes als auch die Konfiguration des externen Load Balancers außerhalb davon verwalten können. Als Referenzarchitektur für den Einstieg habe ich das Projekt nginx-lb-operator auf GitHub erstellt. Der NGINX Load Balancer Operator (NGINX-LB-Operator) ist ein Ansible-basierter Operator für NGINX Controller, der mit dem Red Hat Operator Framework und SDK erstellt wurde. NGINX-LB-Operator steuert die deklarative API von NGINX Controller, um die Konfiguration des externen NGINX Plus Load Balancers zu aktualisieren, wenn neue Services hinzugefügt werden, sich Pods ändern oder Bereitstellungen innerhalb des Kubernetes-Clusters skaliert werden.

Bitte beachten Sie, dass der NGINX-LB-Operator nicht durch Ihren Supportvertrag für NGINX Plus oder NGINX Controller abgedeckt ist. Auf GitHub können Sie Fehler melden oder Unterstützung bei der Fehlerbehebung anfordern.

Kubernetes und NGINX-Technologien – ein Überblick

Der NGINX-LB-Operator basiert auf verschiedenen Kubernetes- und NGINX-Technologien. Daher gebe ich einen kurzen Überblick, damit wir alle auf demselben Stand sind. Wenn Sie bereits damit vertraut sind, können Sie direkt zu „Der NGINX Load Balancer Operator“ springen.

Kubernetes-Controller und -Operatoren

Kubernetes ist eine Orchestrierungsplattform, die auf einer lose gekoppelten zentralen API basiert. Die API stellt eine Sammlung von Ressourcendefinitionen sowie Controller bereit, die diese Ressourcen überwachen und verwalten und üblicherweise als Pods innerhalb der Plattform ausgeführt werden. Die Kubernetes-API ist erweiterbar, und Operatoren (eine Art von Controller) können verwendet werden, um den Funktionsumfang von Kubernetes zu erweitern.

Controller – Ein zentraler Bestandteil des Kubernetes-Systems. Sie richten „Watches“ für bestimmte Kubernetes-Ressourcen ein und führen die erforderlichen Schritte aus, um bei Änderungen den gewünschten Zustand der jeweiligen Ressource zu erreichen. In Kundengesprächen ist der am häufigsten thematisierte Kubernetes-Controller der „Ingress-Controller“.
Operatoren – Benutzerdefinierte Controller, die benutzerdefinierte Ressourcendefinitionen (Custom Resource Definitions, CRDs) definieren und verwenden, um Anwendungen und deren Komponenten zu verwalten.

NGINX-Ingress-Controller für Kubernetes

Für NGINX gibt es zwei wesentliche Optionen für Ingress-Controller. Da ihre Namen auf GitHub sehr ähnlich sind, kann es etwas schwierig sein, sie auseinanderzuhalten. Wir haben dieses Thema bereits ausführlich in einem früheren Blogbeitrag behandelt, aber hier noch einmal ein kurzer Überblick:

kubernetes/ingress-nginx – Der von der Kubernetes-Open-Source-Community unterstützte und gepflegte Ingress-Controller. Der Einfachheit halber nennen wir ihn den „Ingress-Controller der Community“. Wenig überraschend basiert er auf NGINX Open Source. Er bietet zusätzliche Funktionen, die durch Lua-Module von Drittanbietern aktiviert werden, welche sich leider häufig negativ auf die Leistung auswirken.
nginxinc/kubernetes-ingress – Der vom NGINX-Team bei F5 betreute Ingress-Controller. Es gibt zwei Versionen: eine für NGINX Open Source (auf Geschwindigkeit ausgelegt) und eine weitere für NGINX Plus (ebenfalls auf Geschwindigkeit ausgelegt, jedoch mit kommerziellem Support und zusätzlichen Funktionen für den Unternehmenseinsatz). Wir bezeichnen diese als „NGINX Ingress-Controller“ (oder „unsere Ingress-Controller“). Sie können beide unserer Ingress-Controller mithilfe von standardmäßigen Kubernetes-Ingress-Ressourcen verwalten. Wir unterstützen außerdem Annotationen und ConfigMaps, um den begrenzten Funktionsumfang der Ingress-Spezifikation zu erweitern. Ressourcen auf diese Weise zu erweitern, ist jedoch nicht ideal.Version 1.6.0 und spätere Versionen unserer Ingress-Controller bieten eine bessere Lösung: benutzerdefinierte NGINX-Ingress-Ressourcen namens VirtualServer und VirtualServerRoute, die die Kubernetes-API erweitern und zusätzliche Funktionen auf Kubernetes-native Weise bereitstellen. NGINX-Ingress-Ressourcen stellen mehr NGINX-Funktionen bereit und ermöglichen es Ihnen, erweiterte Lastverteilungsfunktionen mit Ingress zu nutzen, Blue-Green- und Canary-Releases sowie Circuit-Breaker-Muster zu implementieren und vieles mehr.

Eine Zusammenfassung der wichtigsten Unterschiede zwischen diesen drei Ingress-Controller-Optionen finden Sie in unserem GitHub-Repository.

NGINX-Controller

NGINX Controller ist unsere cloudunabhängige Steuerungsebene zur Verwaltung Ihrer NGINX Plus-Instanzen in mehreren Umgebungen und zur Nutzung wichtiger Erkenntnisse über Leistungs- und Fehlerzustände. Die Module ermöglichen eine zentrale Konfigurationsverwaltung für die Anwendungsbereitstellung (Lastverteilung) und das API-Management. NGINX Controller kann die Konfiguration von NGINX Plus-Instanzen in einer Vielzahl von Umgebungen verwalten: physisch, virtuell und in der Cloud. Die Lösung basiert auf einer deklarativen API mit letztendlicher Konsistenz und bietet eine anwendungszentrierte Ansicht Ihrer Anwendungen und deren Komponenten. Sie lässt sich problemlos in Ihre CI/CD-Pipelines integrieren, abstrahiert die Infrastruktur vom Code und ermöglicht es Entwicklern, sich auf ihre eigentlichen Aufgaben zu konzentrieren.

Im Zusammenhang mit Kubernetes kann NGINX Controller vorgelagerte NGINX Plus-Instanzen verwalten, die als Reverse-Proxy oder API-Gateway bereitgestellt werden. Es ist jedoch nicht sinnvoll, den NGINX Plus Ingress Controller selbst mit NGINX Controller zu verwalten. Da der Ingress Controller die Regelschleifenfunktion für eine zentrale Kubernetes-Ressource (den Ingress) übernimmt, muss er mit Tools der Kubernetes-Plattform verwaltet werden – entweder mit standardmäßigen Ingress-Ressourcen oder mit NGINX Ingress-Ressourcen.

Externe Load Balancer

Der NGINX Plus Ingress Controller für Kubernetes eignet sich hervorragend, um Dienste innerhalb von Kubernetes für die Außenwelt zugänglich zu machen. Häufig benötigen Sie jedoch eine externe Load-Balancing-Schicht, um den Datenverkehr zu den Kubernetes-Knoten oder -Clustern zu steuern. Wenn Sie eine Public Cloud nutzen, kann als externer Load Balancer NGINX Plus, F5 BIG-IP LTM Virtual Edition oder eine cloudnative Lösung zum Einsatz kommen. Bei einer Bereitstellung im eigenen Rechenzentrum oder in einer Private Cloud können Sie NGINX Plus oder eine physische bzw. virtuelle BIG-IP LTM-Appliance verwenden. Mir wurde gesagt, dass es noch andere Load Balancer gibt, aber das glaube ich nicht 😉 .

Für die Verwaltung Ihrer externen Load Balancer können Sie externe NGINX Plus-Instanzen direkt mit dem NGINX Controller verwalten. Seine deklarative API wurde speziell für die Anbindung an Ihre CI/CD-Pipeline entwickelt und ermöglicht Ihnen die Bereitstellung der einzelnen Komponenten Ihrer Anwendung. Doch was ist, wenn Ihre Ingress-Schicht skalierbar ist, Sie dynamisch zugewiesene Kubernetes-NodePorts verwenden oder sich Ihre OpenShift Routes ändern könnten?

In solchen Fällen empfiehlt es sich, die Konfiguration des externen Load Balancers mit dem Kubernetes-Status zusammenzuführen und die NGINX Controller API über einen Kubernetes Operator anzusteuern. Das Diagramm zeigt eine Beispielbereitstellung, die einen solchen Operator (NGINX-LB-Operator) zur Verwaltung des externen Load Balancers umfasst, und verdeutlicht die Unterschiede zwischen dem NGINX Plus Ingress Controller und NGINX Controller.

wobei:

Ingress-Ressourcen (blauer Kasten) – Im Projekt-Namespace sind eine standardmäßige Ingress-Ressource und eine NGINX-VirtualServer-Ressource definiert.
Blaue Pfeile – Ingress-Ressourcen werden in der Kubernetes-API erstellt und vom NGINX Plus Ingress Controller erfasst, der in einem anderen Namespace ausgeführt wird.
Benutzerdefinierte Ressourcen (grüner Kasten) – Benutzerdefinierte Ressourcen, bei denen es sich um Instanzen der mit NGINX-LB-Operator installierten CRDs handelt, werden im Namespace Ihres Projekts definiert und von NGINX-LB-Operator verwendet, der im selben Namespace ausgeführt wird.
Grüne Pfeile – Ressourcen werden in der API erstellt und anschließend vom NGINX-LB-Operator übernommen. Im Gegensatz zum Ingress Controller, der eine lokale, im selben Pod ausgeführte NGINX Plus-Instanz konfiguriert, sendet der NGINX-LB-Operator einen API-Aufruf an den NGINX Controller.
Orangefarbene Pfeile – NGINX Controller konfiguriert die externe NGINX Plus-Instanz so, dass sie den Datenverkehr auf den NGINX Plus Ingress Controller verteilt.

In dieser Topologie enthalten die benutzerdefinierten Ressourcen den gewünschten Zustand des externen Load Balancers und legen den NGINX Plus Ingress Controller als Upstream (Workload-Gruppe) fest. Der NGINX-LB-Operator erfasst Informationen zu den Ingress-Pods und führt diese mit dem gewünschten Zustand zusammen, bevor er sie an die NGINX Controller API sendet.

Der NGINX Load Balancer Operator

Die Entwicklung eines Operators für Kubernetes mag zunächst wie eine gewaltige Aufgabe erscheinen, doch Red Hat und die Kubernetes-Open-Source-Community pflegen das Operator Framework, das diese Aufgabe relativ einfach macht. Mit dem Operator SDK kann jeder einen Kubernetes-Operator mit Go, Ansible oder Helm erstellen. Bei F5 veröffentlichen wir bereits Ansible Collections für viele unserer Produkte, darunter die zertifizierte Collection für NGINX Controller. Daher ist es recht unkompliziert, einen Operator zu entwickeln, der externe NGINX Plus-Instanzen verwaltet und mit NGINX Controller kommuniziert.

Ich habe das Operator SDK verwendet, um den NGINX Load Balancer Operator NGINX-LB-Operator zu erstellen, der auf Namespace- oder Cluster-Ebene bereitgestellt werden kann und eine Reihe benutzerdefinierter Ressourcen überwacht. Die benutzerdefinierten Ressourcen sind direkt NGINX Controller-Objekten (Certificate, Gateway, Application und Component) zugeordnet und bilden somit das anwendungszentrierte Modell von NGINX Controller direkt in Kubernetes ab. Die in Kubernetes konfigurierten benutzerdefinierten Ressourcen werden von NGINX-LB-Operator erfasst, der anschließend entsprechende Ressourcen in NGINX Controller erstellt.

Mit dem NGINX-LB-Operator können Sie die Konfiguration einer externen NGINX Plus-Instanz über die deklarative API von NGINX Controller verwalten. Da NGINX Controller die externe Instanz verwaltet, profitieren Sie zusätzlich von Überwachung und Warnmeldungen sowie von den detaillierten Anwendungseinblicken, die NGINX Controller bietet.

Dieses Diagramm veranschaulicht Folgendes:

Sie erstellen benutzerdefinierte Ressourcen im Projekt-Namespace, die an die Kubernetes-API gesendet werden.
Der NGINX-LB-Operator erkennt die neu konfigurierten Ressourcen und ruft den gewünschten Zustand der Komponente sowie die Bereitstellungsinformationen vom Ingress-Controller im Ingress-Namespace ab.
Eine zusammengeführte Konfiguration aus Ihrer Definition und dem aktuellen Status des Ingress-Controllers wird an NGINX Controller gesendet.
Die Konfiguration wird an die angeforderten NGINX Plus-Instanzen übermittelt, und NGINX Controller beginnt mit der Erfassung von Metriken für die neue Anwendung.

Ausführliche Bereitstellungsanweisungen und eine Beispielanwendung finden Sie auf GitHub. Wenn Sie keine Rollenspiele mögen oder nur an der Kurzfassung interessiert sind, schauen Sie dort gleich vorbei.

Eine Beispielbereitstellung

Machen wir also ein Rollenspiel. Ich bin Susan und du bist Dave.

In der Rolle von Dave leiten Sie einen Geschäftsbereich Ihres bevorzugten fiktiven Mischkonzerns. Sie sind am Puls der Zeit und wissen, was gerade angesagt ist. Daher stellen Sie alle Ihre Anwendungen und Microservices auf OpenShift bereit und verwenden für den Ingress den NGINX Plus Ingress Controller für Kubernetes. Alle Ihre Anwendungen werden als OpenShift-Projekte (Namespaces) bereitgestellt, und der NGINX Plus Ingress Controller wird in einem eigenen Ingress-Namespace ausgeführt.

Sie waren mit den Funktionen der standardmäßigen Ingress-Spezifikation nie zufrieden und fanden ConfigMaps und Annotations immer etwas umständlich. Daher waren Sie überglücklich, als NGINX ankündigte, dass der NGINX Plus Ingress Controller künftig eigene CRDs unterstützen würde. Heute verwenden Ihre Anwendungsentwickler die VirtualServer- und VirtualServerRoutes-Ressourcen zur Verwaltung der Bereitstellung von Anwendungen auf dem NGINX Plus Ingress Controller sowie zur Konfiguration des internen Routings und der Fehlerbehandlung in OpenShift.

Manchmal stellen Sie sogar Nicht-HTTP-Dienste bereit – dank der benutzerdefinierten TransportServer-Ressourcen, die ebenfalls mit dem NGINX Plus Ingress Controller verfügbar sind. Entwickler können die benutzerdefinierten Ressourcen in ihren eigenen Projekt-Namespaces definieren. Diese werden dann vom NGINX Plus Ingress Controller erkannt und sofort angewendet. Das ist großartig, aber Sie wünschten, der externe Netzwerk-Load-Balancer am Rand Ihres OpenShift-Clusters ließe sich genauso einfach verwalten. Jedes Mal, wenn Sie die Ingress-Schicht skalieren müssen, macht sich Ihr Hexenschuss wieder bemerkbar.

Es ist Samstagabend und du solltest eigentlich in der Disco sein, aber gestern musstest du schon wieder die Ingress-Schicht skalieren, und jetzt hast du Schmerzen im unteren Rücken. Pling! In einer Rauchwolke erscheint deine gute Fee Susan.

„Hallo, Dave“, sagt sie.

„Wer sind Sie? Sehen Sie nur, was Sie mit meinem Perserteppich gemacht haben“ antworten Sie.

Susan ignoriert Ihre Haltung und erzählt Ihnen weiter vom NGINX-LB-Operator, der jetzt auf GitHub verfügbar ist. Sie erklärt, dass Sie mit einem NGINX Plus-Cluster am Rand von OpenShift und NGINX Controller, über den er aus anwendungszentrierter Perspektive verwaltet wird, benutzerdefinierte Ressourcen erstellen können, die festlegen, wie der NGINX Plus-Load-Balancer konfiguriert werden soll.

Der NGINX-LB-Operator überwacht diese Ressourcen und verwendet sie, um die anwendungszentrierte Konfiguration an NGINX Controller zu senden. NGINX Controller wiederum generiert die erforderliche NGINX Plus-Konfiguration und überträgt sie an den externen NGINX Plus-Load-Balancer.

Ihre Endbenutzer erhalten sofortigen Zugriff auf Ihre Anwendungen, und Sie behalten die Kontrolle über Änderungen, die eine Anpassung des externen NGINX Plus-Load-Balancers erfordern!

NGINX Controller erfasst Metriken vom externen NGINX Plus-Load-Balancer und stellt sie Ihnen aus derselben anwendungszentrierten Perspektive dar, die Sie bereits schätzen. Wenn Sie das nächste Mal die NGINX Plus-Ingress-Schicht skalieren, aktualisiert NGINX-LB-Operator automatisch den NGINX Controller und den externen NGINX Plus-Load-Balancer für Sie. Schluss mit den Rückenschmerzen!

Fazit

Kubernetes ist eine Plattform zur Verwaltung containerisierter Anwendungen. NGINX Controller bietet ein anwendungszentriertes Modell für die Konzeption und Verwaltung des Anwendungslastenausgleichs. NGINX-LB-Operator kombiniert beides und ermöglicht Ihnen, den gesamten Stack End-to-End zu verwalten, ohne sich um die zugrunde liegende Infrastruktur kümmern zu müssen. Weitere technische Informationen über NGINX-LB-Operator sowie eine vollständige exemplarische Anleitung finden Sie auf GitHub.

Erfahren Sie mehr über unsere Lösungen: