Konfigurieren von NGINX Plus als externer Load Balancer für Red Hat OCP und Kubernetes

In der Welt der Container-Orchestrierung stoßen wir immer wieder auf zwei Namen: RedHat OpenShift Container Platform (OCP) und Kubernetes. Wie Sie wahrscheinlich wissen, verwendet OpenShift, wie viele andere Container-Orchestrierungsplattformen, Kubernetes. Das Weiterleiten externen Datenverkehrs in eine Kubernetes- oder OpenShift-Umgebung war schon immer eine kleine Herausforderung, und zwar in zweierlei Hinsicht:

• Bereitstellung von in Kubernetes bereitgestellten Diensten für die Außenwelt. Die Lösung ist ein Ingress-Controller wie NGINX Plus Ingress Controller . Weitere Informationen hierzu finden Sie in unserem Blog „Erste Schritte mit dem NGINX Ingress Operator unter Red Hat OpenShift“ .
• Lastenausgleich des Datenverkehrs über Ihre Kubernetes-Knoten. Um dieses Problem zu lösen, entscheiden sich Unternehmen normalerweise für einen externen Hardware- oder virtuellen Load Balancer oder eine Cloud-native Lösung. NGINX Plus kann jedoch auch als externer Lastenausgleich verwendet werden, was die Leistung verbessert und Ihre Technologieinvestition vereinfacht.

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

Bitte beachten Sie, dass NGINX-LB-Operator nicht durch Ihren NGINX Plus- oder NGINX Controller-Supportvertrag abgedeckt ist. Sie können auf GitHub Fehler melden oder Hilfe bei der Fehlerbehebung anfordern.

Kubernetes- und NGINX-Technologien – Ein Überblick

NGINX-LB-Operator basiert auf einer Reihe von Kubernetes- und NGINX-Technologien. Daher stelle ich hier einen kurzen Überblick bereit, damit wir alle auf dem gleichen 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 um eine lose gekoppelte zentrale API herum aufgebaut ist. Die API bietet eine Sammlung von Ressourcendefinitionen sowie Controller (die normalerweise als Pods innerhalb der Plattform ausgeführt werden), um diese Ressourcen zu überwachen und zu verwalten. Die Kubernetes-API ist erweiterbar und Operatoren (eine Art Controller) können verwendet werden, um die Funktionalität von Kubernetes zu erweitern.

• Controller – Ein zentraler Bestandteil des Kubernetes-Systems. Sie erstellen „Überwachungsfunktionen“ für bestimmte Kubernetes-Ressourcen und führen die erforderlichen Schritte aus, um den gewünschten Zustand jeder Ressource bei Änderung zu erreichen. Der in Kundengesprächen am häufigsten besprochene Kubernetes-Controller ist der „Ingress Controller“.
• Operatoren – Benutzerdefinierte Controller, die benutzerdefinierte Ressourcendefinitionen (CRDs) definieren und verwenden, um Anwendungen und ihre Komponenten zu verwalten.

NGINX Ingress Controller für Kubernetes

Es gibt zwei Hauptoptionen für den Ingress-Controller für NGINX und es kann etwas verwirrend sein, sie auseinanderzuhalten, weil die Namen in GitHub so ähnlich sind. Wir haben dieses Thema in einem früheren Blog ausführlich besprochen, aber hier ist ein kurzer Rückblick:

• kubernetes/ingress-nginx – Der Ingress-Controller, der von der Kubernetes Open Source-Community unterstützt und gepflegt wird. Der Einfachheit halber nennen wir dies den „Ingress-Controller der Community“. Wenig überraschend basiert es auf NGINX Open Source. Es bietet zusätzliche Funktionen, die durch Lua-Module von Drittanbietern aktiviert werden, was leider tendenziell die Leistung beeinträchtigt.

• nginxinc/kubernetes-ingress – Der Ingress-Controller, der vom NGINX-Team bei F5 verwaltet wird. Es gibt zwei Versionen: eine für NGINX Open Source (auf Geschwindigkeit ausgelegt) und eine andere für NGINX Plus (ebenfalls auf Geschwindigkeit ausgelegt, aber kommerziell unterstützt und mit zusätzlichen Funktionen der Unternehmensklasse). Wir nennen diese „NGINX (oder unsere) Ingress-Controller“.

  Sie können unsere beiden Ingress-Controller mit standardmäßigen Kubernetes-Ingress-Ressourcen verwalten. Wir unterstützen auch Annotationen und ConfigMaps, um die eingeschränkte Funktionalität der Ingress-Spezifikation zu erweitern, aber die Erweiterung der Ressourcen auf diese Weise ist nicht ideal.

  Die Versionen 1.6.0 und höher unserer Ingress-Controller enthalten 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-Funktionalität bereit und ermöglichen Ihnen die Verwendung erweiterter Lastausgleichsfunktionen mit Ingress, die Implementierung von Blue-Green- und Canary-Releases, Circuit-Breaker-Mustern und mehr.

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

NGINX-Controller

NGINX Controller ist unsere Cloud-agnostische Steuerungsebene für die Verwaltung Ihrer NGINX Plus-Instanzen in mehreren Umgebungen und die Nutzung wichtiger Erkenntnisse zu Leistungs- und Fehlerzuständen. Seine Module bieten ein zentrales Konfigurationsmanagement für die Anwendungsbereitstellung (Lastausgleich) und API-Verwaltung . NGINX Controller kann die Konfiguration von NGINX Plus-Instanzen in einer Vielzahl von Umgebungen verwalten: physisch, virtuell und in der Cloud. Es basiert auf einer letztendlich konsistenten, deklarativen API und bietet eine app-zentrierte Ansicht Ihrer Apps und deren Komponenten. Es ist für eine einfache Schnittstelle zu Ihren CI/CD-Pipelines konzipiert, abstrahiert die Infrastruktur vom Code und ermöglicht es den Entwicklern, sich auf ihre Arbeit zu konzentrieren.

Wenn es um Kubernetes geht, kann der NGINX Controller NGINX Plus-Instanzen verwalten, die im Frontend als Reverse-Proxy oder API-Gateway bereitgestellt werden. Es ist allerdings nicht sinnvoll, wenn der NGINX Controller den NGINX Plus Ingress Controller selbst verwaltet. Da der Ingress Controller die Kontrollschleifenfunktion für eine zentrale Kubernetes-Ressource (den Ingress) ausführt, muss er mit Tools der Kubernetes-Plattform verwaltet werden – entweder mit Standard-Ingress-Ressourcen oder mit NGINX-Ingress-Ressourcen.

Externe Load Balancer

Der NGINX Plus Ingress Controller für Kubernetes ist eine großartige Möglichkeit, Dienste innerhalb von Kubernetes der Außenwelt zugänglich zu machen, aber Sie benötigen häufig eine externe Lastausgleichsschicht, um den Datenverkehr in Kubernetes-Knoten oder -Clustern zu verwalten. Wenn Sie in einer öffentlichen Cloud arbeiten, kann der externe Load Balancer NGINX Plus, F5 BIG-IP LTM Virtual Edition oder eine Cloud-native Lösung sein. Wenn Sie vor Ort oder in einer privaten Cloud bereitstellen, können Sie NGINX Plus oder ein BIG-IP LTM- Gerät (physisch oder virtuell) verwenden. Mir wurde gesagt, dass es andere Load Balancer gibt, aber ich glaube es nicht 😉.

Wenn es um die Verwaltung Ihrer externen Lastenausgleichsmodule geht, können Sie externe NGINX Plus-Instanzen direkt mit dem NGINX-Controller verwalten. Die deklarative API wurde für die Schnittstelle zu Ihrer CI/CD-Pipeline entwickelt und Sie können jede Ihrer Anwendungskomponenten damit bereitstellen. Aber was ist, wenn Ihre Ingress-Schicht skalierbar ist, Sie dynamisch zugewiesene Kubernetes NodePorts verwenden oder sich Ihre OpenShift-Routen ändern könnten?

In solchen Fällen möchten Sie wahrscheinlich die Konfiguration des externen Load Balancers mit dem Kubernetes-Status zusammenführen und die NGINX Controller-API über einen Kubernetes-Operator steuern. Das Diagramm zeigt eine Beispielbereitstellung, die genau einen solchen Operator ( NGINX-LB-Operator ) zur Verwaltung des externen Lastenausgleichs enthält, und hebt die Unterschiede zwischen dem NGINX Plus Ingress Controller und dem NGINX Controller hervor.

Wo:

• Ingress-Ressourcen (blaues Kästchen) – Im Projektnamespace sind eine Standard-Ingress-Ressource und eine NGINX VirtualServer-Ressource definiert.
• Blaue Pfeile – Ingress-Ressourcen werden in der Kubernetes-API erstellt und vom NGINX Plus Ingress Controller abgerufen, der in einem anderen Namespace ausgeführt wird.
• Benutzerdefinierte Ressourcen (grünes Kästchen) – Benutzerdefinierte Ressourcen, bei denen es sich um Instanziierungen von CRDs handelt, die mit NGINX-LB-Operator installiert wurden, 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 dann vom NGINX-LB-Operator abgerufen. Anders als der Ingress Controller, der eine lokale NGINX Plus-Instanz konfiguriert, die im selben Pod ausgeführt wird, führt der NGINX-LB-Operator einen API-Aufruf an den NGINX Controller durch.
• Orange Pfeile – Der NGINX-Controller konfiguriert die externe NGINX-Plus-Instanz für den Lastenausgleich auf dem NGINX-Plus-Ingress-Controller.

In dieser Topologie enthalten die benutzerdefinierten Ressourcen den gewünschten Status des externen Lastenausgleichs und legen den Upstream (Arbeitslastgruppe) als NGINX Plus Ingress Controller fest. NGINX-LB-Operator sammelt Informationen zu den Ingress-Pods und führt diese Informationen mit dem gewünschten Status zusammen, bevor sie an die NGINX-Controller-API gesendet werden.

Der NGINX Load Balancer Operator

Das Schreiben eines Operators für Kubernetes scheint zunächst eine gewaltige Aufgabe zu sein, aber Red Hat und die Kubernetes Open Source-Community pflegen das Operator Framework , wodurch die Aufgabe relativ einfach wird. Mit dem Operator SDK kann jeder mit Go, Ansible oder Helm einen Kubernetes Operator erstellen. Bei F5 veröffentlichen wir bereits Ansible-Sammlungen für viele unserer Produkte, einschließlich der zertifizierten Sammlung für NGINX Controller . Daher ist das Erstellen eines Operators zum Verwalten externer NGINX Plus-Instanzen und zur Schnittstelle mit NGINX Controller ziemlich unkompliziert.

Ich habe das Operator SDK verwendet, um den NGINX Load Balancer Operator ( NGINX-LB-Operator) zu erstellen, der mit einem Namespace- oder Cluster-Scope bereitgestellt werden kann und nach einer Handvoll benutzerdefinierter Ressourcen Ausschau hält. Die benutzerdefinierten Ressourcen werden direkt auf NGINX Controller-Objekte (Zertifikat, Gateway, Anwendung und Komponente) abgebildet und stellen so das anwendungszentrierte Modell des NGINX Controllers direkt in Kubernetes dar. Die in Kubernetes konfigurierten benutzerdefinierten Ressourcen werden vom NGINX-LB-Operator abgerufen, der dann entsprechende Ressourcen im NGINX Controller erstellt.

Mit NGINX-LB-Operator können Sie die Konfiguration einer externen NGINX Plus-Instanz mithilfe der deklarativen API des NGINX Controllers verwalten. Da der NGINX Controller die externe Instanz verwaltet, profitieren Sie von den zusätzlichen Vorteilen der Überwachung und Warnmeldung sowie den umfassenden Anwendungseinblicken, die der NGINX Controller bietet.

Dieses Diagramm veranschaulicht Folgendes:

1. Sie erstellen benutzerdefinierte Ressourcen im Projektnamespace, die an die Kubernetes-API gesendet werden.
2. NGINX-LB-Operator sieht die neu konfigurierten Ressourcen und sammelt den gewünschten Status der Komponente und die Bereitstellungsinformationen vom Ingress-Controller im Ingress-Namespace.
3. Eine zusammengeführte Konfiguration aus Ihrer Definition und dem aktuellen Status des Ingress-Controllers wird an den NGINX-Controller gesendet.
4. Die Konfiguration wird an die angeforderten NGINX Plus-Instanzen übermittelt und der NGINX Controller beginnt mit dem Sammeln von Messdaten für die neue Anwendung.

Detaillierte Bereitstellungsanweisungen und eine Beispielanwendung finden Sie auf GitHub . Wenn Sie Rollenspiele nicht mögen oder wegen der TL;DR-Version hierhergekommen sind, gehen Sie jetzt dorthin.

Eine Beispielbereitstellung

Also lasst uns Rollenspiele spielen. Ich bin Susan und du kannst Dave sein.

Als Dave leiten Sie einen Geschäftszweig bei Ihrem bevorzugten imaginären Konglomerat. Sie sind auf der Höhe der Zeit, haben den Finger am Puls der Zeit usw., also stellen Sie alle Ihre Anwendungen und Microservices auf OpenShift bereit und verwenden für 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 seinem eigenen Ingress-Namespace ausgeführt.

Sie waren nie zufrieden mit den in der Standard-Ingress-Spezifikation verfügbaren Funktionen und fanden ConfigMaps und Annotations immer etwas klobig. Aus diesem Grund waren Sie überglücklich, als NGINX ankündigte, dass der NGINX Plus Ingress Controller nun seine eigenen CRDs unterstützen würde. Heute verwenden Ihre Anwendungsentwickler die Ressourcen VirtualServer und VirtualServerRoutes, um die Bereitstellung von Anwendungen auf dem NGINX Plus Ingress Controller zu verwalten und das interne Routing und die Fehlerbehandlung in OpenShift zu konfigurieren.

Manchmal stellen Sie sogar Nicht-HTTP-Dienste bereit, alles dank der benutzerdefinierten TransportServer- Ressourcen, die auch mit dem NGINX Plus Ingress Controller verfügbar sind. Entwickler können die benutzerdefinierten Ressourcen in ihren eigenen Projektnamespaces definieren, die dann vom NGINX Plus Ingress Controller abgerufen und sofort angewendet werden. Das ist zwar großartig, aber Sie wünschen sich, dass Sie den externen Netzwerk-Load Balancer am Rand Ihres OpenShift-Clusters genauso einfach verwalten könnten. Die Zeiten, in denen Sie die Ingress-Ebene skalieren müssen, führen immer dazu, dass Ihr Hexenschuss verrücktspielt.

Es ist Samstagabend und Sie sollten in der Disco sein, aber gestern mussten Sie bereits wieder die Ingress-Ebene erklimmen und jetzt haben Sie Schmerzen im unteren Rücken. Ping! In einer Rauchwolke erscheint deine gute Fee Susan.

„Hallo, Dave“, sagt sie.

"Wer bist du? „Sehen Sie, was Sie mit meinem Perserteppich gemacht haben“, antworten Sie.

Susan ignoriert Ihre Einstellung und erzählt Ihnen vom NGINX-LB-Operator, der jetzt auf GitHub verfügbar ist. Sie erklärt, dass man mit einem NGINX Plus-Cluster am Rand von OpenShift und einem NGINX Controller zur Verwaltung aus einer anwendungszentrierten Perspektive benutzerdefinierte Ressourcen erstellen kann, die definieren, wie der NGINX Plus-Load Balancer konfiguriert wird.

Der NGINX-LB-Operator überwacht diese Ressourcen und verwendet sie, um die anwendungszentrierte Konfiguration an den NGINX-Controller zu senden. Im Gegenzug generiert der NGINX Controller 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 erhalten Kontrolle über Änderungen, die Modifikationen am externen NGINX Plus-Load Balancer erfordern!

NGINX Controller sammelt Messdaten vom externen NGINX Plus-Load Balancer und präsentiert sie Ihnen aus derselben anwendungszentrierten Perspektive, die Sie bereits genießen. Und 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. Keine Rückenschmerzen mehr!

Abschluss

Kubernetes ist eine Plattform zur Verwaltung containerisierter Anwendungen. NGINX Controller bietet ein anwendungszentriertes Modell zum Überlegen und Verwalten des Anwendungslastausgleichs. NGINX-LB-Operator kombiniert beides und ermöglicht Ihnen die End-to-End -Verwaltung des gesamten Stacks, ohne sich um die zugrunde liegende Infrastruktur kümmern zu müssen. Weitere technische Informationen zu NGINX-LB-Operator und eine vollständige Beispielanleitung finden Sie auf GitHub .

Erfahren Sie mehr über unsere Lösungen:

• Fordern Sie eine kostenlose Testversion von NGINX Controller an
• Kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen
• Holen Sie sich den NGINX Ingress Operator für OpenShift
• Registrieren Sie sich für einen von einem Lehrer geleiteten Kurs