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 Datenverkehr in Kubernetes-Clustern zu lenken, können Sie BIG‑IP als externen Load Balancer nutzen, der die Funktionen und das Spektrum der Overlay-Netzwerktechnologien unterstützt, mit denen Sie bereits vertraut sind. BIG‑IP allein kann Änderungen an der Pod-Gruppe im Kubernetes-Cluster nicht verfolgen, etwa Anpassungen bei der Anzahl der Pods oder deren IP-Adressen. Um dieses Limit zu überwinden, setzen wir F5 Container Ingress Services (CIS) als Operator innerhalb des Clusters ein. CIS beobachtet Änderungen bei den Pods und aktualisiert die Adressen im Lastverteilungspool des BIG‑IP-Systems automatisch. Zudem erkennt CIS das Anlegen neuer Ingress-, Route- und benutzerdefinierter Ressourcen und passt die BIG‑IP-Konfiguration entsprechend an.

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 wissen, wurden BIG‑IP und der NGINX Ingress Controller ursprünglich von zwei verschiedenen Unternehmen (F5 beziehungsweise NGINX) entwickelt. Seit F5 NGINX übernommen hat, berichten Kunden uns, dass eine bessere Zusammenarbeit der beiden Tools das Management ihrer Infrastruktur deutlich vereinfacht. Daher haben wir die Kubernetes-Ressource IngressLink entwickelt.

Die IngressLink-Ressource ist eine einfache Erweiterung, die eine Kubernetes CustomResourceDefinition (CRD) nutzt, um den NGINX Ingress Controller und BIG‑IP zu „verbinden“. Kurz gesagt, ermöglicht sie dem CIS, BIG‑IP zu informieren, sobald sich die Gruppe der NGINX Ingress Controller-Pods ändert. Mit diesen Informationen passt BIG‑IP seine entsprechenden Lastausgleichsrichtlinien flexibel an.

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. Weil der NGINX Ingress Controller außergewöhnlich effizient arbeitet, verwaltet ein stabiler Instanzensatz häufige und umfangreiche Änderungen bei den Application-Pods problemlos. Wenn Ihr NGINX Ingress Controller jedoch horizontal skaliert, um Verkehrsspitzen oder Rückgänge auszugleichen, informiert CIS BIG‑IP über diese Änderungen (durch die IngressLink-Ressource), damit BIG‑IP sich schnell anpasst.

Erste Schritte

Für ausführlichere Informationen zur Funktionsweise der IngressLink-Ressource und zum Bereitstellungshandbuch besuchen Sie 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.