Bereitstellen von BIG-IP und NGINX Ingress Controller in derselben Architektur

In unserer vorherigen Blogserie „Bereitstellen von Anwendungsdiensten in Kubernetes“ haben wir ein Muster besprochen, das wir bei vielen Kunden auf ihrem Weg zur digitalen Transformation beobachten. Die meisten Entwicklungen beginnen mit dem traditionellen Modell zur Erstellung und Bereitstellung von Apps (normalerweise Monolithen), wobei die Verantwortung für diese beiden Funktionen zwischen isolierten Entwicklungs- und Betriebsteams aufgeteilt wird. Wenn Unternehmen zu einem moderneren Modell wechseln, erstellen sie Apps auf Basis von Mikrodiensten und stellen sie mithilfe von DevOps-Methoden bereit, die die Trennung zwischen traditionellen Silos aufheben.

Während DevOps-Teams und Anwendungseigentümer eine stärkere direkte Kontrolle über die Bereitstellung, Verwaltung und Auslieferung ihrer Anwendungen übernehmen, ist es oft nicht praktikabel, die Silomauern auf einmal einzureißen – und wir halten es auch nicht für notwendig. Stattdessen stellen wir fest, dass weiterhin eine logische Aufgabenteilung gilt:

• Netzwerk- und Sicherheitsteams konzentrieren sich weiterhin auf die allgemeine Sicherheit, Leistung und Verfügbarkeit der Unternehmensinfrastruktur. Für sie sind globale Dienste am wichtigsten, die im Allgemeinen an der „Vordertür“ dieser Infrastruktur bereitgestellt werden.

  Diese Teams verlassen sich auf F5 BIG-IP für Anwendungsfälle wie globales Server-Load-Balancing (GSLB), DNS- Auflösung und Load-Balancing sowie anspruchsvolles Traffic-Shaping. BIG-IQ und NGINX Controller [jetzt F5 NGINX Management Suite ] bieten Messgrößen und Warnmeldungen in einer Form, die optimal zu NetOps-Teams passt, und bieten SecOps-Teams die Transparenz und Kontrolle über die Sicherheit, die SecOps haben müssen, um die Vermögenswerte des Unternehmens zu schützen und Branchenvorschriften einzuhalten.

• Betriebsteams (DevOps mit Schwerpunkt auf Ops) erstellen und verwalten einzelne Anwendungen entsprechend den Anforderungen der jeweiligen Geschäftsbereiche. Für sie sind Dienste wie Automatisierung und CI/CD-Pipelines am wichtigsten, mit denen sie aktualisierte Funktionen schneller iterieren können. Solche Dienste werden im Allgemeinen „näher“ an der App bereitgestellt, beispielsweise in einer Kubernetes-Umgebung.

  Diese Teams verlassen sich auf NGINX-Produkte wie NGINX Plus , NGINX App Protect , NGINX Ingress Controller und NGINX Service Mesh für den Lastenausgleich und die Verkehrsgestaltung verteilter, auf Mikroservices basierender Anwendungen, die in mehreren Umgebungen, einschließlich Kubernetes-Clustern, gehostet werden. Zu den Anwendungsfällen gehören TLS-Terminierung, hostbasiertes Routing, URI-Umschreiben, JWT-Authentifizierung, Sitzungspersistenz, Ratenbegrenzung, Integritätsprüfung, Sicherheit (mit NGINX App Protect als integriertem WAF) und vieles mehr.

NetOps und DevOps in Kubernetes-Umgebungen

Die unterschiedlichen Anliegen von NetOps- und DevOps-Teams spiegeln sich in den Rollen wider, die sie in Kubernetes-Umgebungen spielen, und in den Tools, die sie zur Erfüllung dieser Rollen verwenden. Auf die Gefahr hin, es zu vereinfachen, können wir sagen, dass sich NetOps-Teams in erster Linie um die Infrastruktur- und Netzwerkfunktionen außerhalb des Kubernetes-Clusters kümmern und DevOps-Teams sich um diese Funktionen innerhalb des Clusters kümmern.

Um den Datenverkehr in Kubernetes-Cluster zu leiten, können NetOps-Teams BIG-IP als externen Load Balancer verwenden, der die Funktionen und die Palette der Overlay-Netzwerktechnologien unterstützt, mit denen sie bereits vertraut sind. BIG-IP verfügt allerdings nicht über die Möglichkeit, allein Änderungen an der Gruppe der Pods im Kubernetes-Cluster zu verfolgen (beispielsweise Änderungen an der Anzahl der Pods oder an ihren IP-Adressen). Um diese Einschränkung zu umgehen, werden F5 Container Ingress Services (CIS) als Operator innerhalb des Clusters eingesetzt. CIS überwacht Änderungen am Pod-Satz und ändert die Adressen im Lastausgleichspool des BIG-IP-Systems automatisch entsprechend. Es sucht außerdem nach der Erstellung neuer Ingress-, Route- und benutzerdefinierter Ressourcen und aktualisiert die BIG-IP-Konfiguration entsprechend.

Obwohl Sie die Kombination aus BIG-IP und CIS verwenden können, um den Datenverkehr direkt auf Anwendungs-Pods auszurichten , ist NGINX Ingress Controller in der Praxis die ideale Lösung, um dynamische Anwendungsänderungen an Pods und Workloads, die eine große Anzahl von Diensten darstellen, zu erkennen und mit ihnen Schritt zu halten – beispielsweise bei der horizontalen Skalierung Ihrer Anwendungs-Pods, um sich ändernden Nachfrageniveaus gerecht zu werden.

Ein weiterer Vorteil der Bereitstellung von NGINX Ingress Controller besteht darin, dass die Kontrolle über den Anwendungslastausgleich auf die DevOps-Teams verlagert wird, die für die Anwendungen selbst verantwortlich sind. Dank seiner leistungsstarken Steuerebene und seines DevOps-zentrierten Designs eignet es sich besonders gut für die Unterstützung sich schnell ändernder DevOps-Anwendungsfälle – wie etwa direkte Neukonfigurationen und fortlaufende Updates – über Kubernetes-Dienste in mehreren Namespaces hinweg. NGINX Ingress Controller verwendet die native Kubernetes-API, um Pods während ihrer Skalierung zu erkennen.

So arbeiten BIG-IP und NGINX Ingress Controller zusammen

Wie Sie vielleicht wissen, wurden BIG-IP und NGINX Ingress Controller ursprünglich von zwei verschiedenen Unternehmen (F5 bzw. NGINX) entwickelt. Seit F5 NGINX übernommen hat, haben uns Kunden mitgeteilt, dass eine verbesserte Interoperabilität zwischen den beiden Tools die Verwaltung ihrer Infrastruktur vereinfachen würde. Als Reaktion darauf haben wir eine neue Kubernetes-Ressource entwickelt, die wir IngressLink nennen.

Die IngressLink-Ressource ist eine einfache Erweiterung, die eine Kubernetes CustomResourceDefinition (CRD) verwendet, um NGINX Ingress Controller und BIG-IP zu „verknüpfen“. Einfach ausgedrückt ermöglicht es CIS, BIG-IP zu „informieren“, wenn sich der Satz der NGINX Ingress Controller-Pods geändert hat. Mit diesen Informationen kann BIG-IP seine entsprechenden Lastausgleichsrichtlinien flexibel anpassen.

Wenn BIG‑IP für den Lastenausgleich der Kubernetes‑Cluster bereitgestellt wird und der NGINX Ingress Controller den ein- und ausgehenden Datenverkehr verarbeitet, sieht der Datenverkehrsfluss folgendermaßen aus:

1. BIG-IP leitet externen Datenverkehr an die NGINX Ingress Controller-Instanzen weiter.
2. NGINX Ingress Controller verteilt den Datenverkehr an die entsprechenden Dienste innerhalb des Clusters.
3. Da der NGINX Ingress Controller außergewöhnlich effizient ist, kann ein stabiler Satz von Instanzen häufige und große Änderungen am Satz der Anwendungs-Pods verarbeiten. Wenn Ihr NGINX Ingress Controller jedoch horizontal nach oben oder unten skaliert werden muss (um Verkehrsspitzen und -rückgänge zu bewältigen), informiert CIS BIG-IP über die Änderungen (über die IngressLink-Ressource), sodass BIG-IP sich schnell an die Änderungen anpassen kann.

Erste Schritte

Weitere Einzelheiten zur Funktionsweise der IngressLink-Ressource, einschließlich einer Bereitstellungsanleitung, finden Sie in den F5 CloudDocs .

Beginnen Sie, indem Sie Ihre kostenlose 30-Tage-Testversion von NGINX Ingress Controller mit NGINX App Protect WAF und DoS anfordern. Wenn Sie noch kein BIG-IP-Benutzer sind, wählen Sie auf F5.com die Testversion aus , die für Ihr Team am besten geeignet ist.