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

Micheál KingstonSenior-Produktmanager

In unserer vorherigen Blogreihe „Bereitstellung von Anwendungsdiensten in Kubernetes“ haben wir ein Muster erörtert, das wir bei vielen Kunden im Zuge ihrer digitalen Transformation beobachten. Meist beginnt dieser Weg mit dem traditionellen Modell für die Entwicklung und Bereitstellung von Anwendungen (in der Regel Monolithen), bei dem die Verantwortung für diese beiden Aufgaben auf voneinander abgeschottete Entwicklungs- und Betriebsteams verteilt ist. Beim Übergang zu einem moderneren Modell entwickeln Unternehmen auf Microservices basierende Anwendungen und stellen sie mithilfe von DevOps-Praktiken bereit, wodurch die Grenzen zwischen den traditionellen Silos verschwimmen.

Während DevOps-Teams und Anwendungsverantwortliche zunehmend die direkte Kontrolle darüber übernehmen, wie ihre Anwendungen bereitgestellt, verwaltet und ausgeliefert werden, ist es häufig nicht praktikabel, die Silos auf einmal aufzubrechen – und unserer Erfahrung nach ist dies auch nicht notwendig. Stattdessen beobachten wir, dass eine logische Aufgabenteilung weiterhin sinnvoll ist:

• Netzwerk- und Sicherheitsteams konzentrieren sich weiterhin auf die allgemeine Sicherheit, Leistung und Verfügbarkeit der Unternehmensinfrastruktur. Ihr Hauptaugenmerk liegt auf globalen Diensten, die in der Regel am „Eingang“ dieser Infrastruktur bereitgestellt werden. Diese Teams setzen auf F5 BIG-IP für Anwendungsfälle wie globalen Serverlastenausgleich (GSLB), DNS-Auflösung und -Lastenausgleich sowie eine ausgefeilte Datenverkehrssteuerung. BIG‑IQ und NGINX Controller [jetzt F5 NGINX Management Suite] stellen Metriken und Warnmeldungen in einer Form bereit, die optimal auf die Anforderungen von NetOps-Teams zugeschnitten ist. SecOps-Teams bieten sie zudem die Transparenz und Kontrolle über die Sicherheit, die diese benötigen, um die Ressourcen 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. Ihr Hauptaugenmerk liegt auf Diensten wie Automatisierung und CI/CD-Pipelines, mit denen sie aktualisierte Funktionen schneller weiterentwickeln können. Solche Dienste werden in der Regel „näher“ an der Anwendung bereitgestellt, beispielsweise innerhalb einer Kubernetes-Umgebung. Diese Teams setzen auf NGINX-Produkte wie NGINX Plus, NGINX App Protect, NGINX Ingress Controller und NGINX Service Mesh, um den Lastenausgleich und die Datenverkehrssteuerung für verteilte, auf Microservices basierende Anwendungen zu übernehmen, die in mehreren Umgebungen einschließlich Kubernetes-Clustern gehostet werden. Zu den Anwendungsfällen gehören TLS-Terminierung, hostbasiertes Routing, URI-Umschreibung, JWT-Authentifizierung, Sitzungspersistenz, Ratenbegrenzung, Zustandsprüfungen, Sicherheit (mit NGINX App Protect als integrierter WAF) und vieles mehr.

NetOps und DevOps in Kubernetes-Umgebungen

Die unterschiedlichen Schwerpunkte von NetOps- und DevOps-Teams spiegeln sich in ihren jeweiligen Rollen in Kubernetes-Umgebungen und den Tools wider, die sie zur Erfüllung ihrer Aufgaben einsetzen. Vereinfacht lässt sich sagen, dass NetOps-Teams in erster Linie für die Infrastruktur und Netzwerkfunktionen außerhalb des Kubernetes-Clusters zuständig sind, während DevOps-Teams diese Funktionen innerhalb des Clusters verantworten.

Um Datenverkehr in Kubernetes-Cluster zu leiten, können NetOps-Teams BIG‑IP als externen Load Balancer einsetzen, der die ihnen bereits vertrauten Funktionen und vielfältigen Overlay-Netzwerktechnologien unterstützt. BIG‑IP allein kann jedoch Änderungen an den Pods innerhalb des Kubernetes-Clusters nicht nachverfolgen (beispielsweise Änderungen an der Anzahl der Pods oder ihren IP-Adressen). Um diese Einschränkung zu umgehen, werden F5 Container Ingress Services (CIS) als Operator innerhalb des Clusters bereitgestellt. CIS überwacht Änderungen an den Pods und passt die Adressen im Load-Balancing-Pool des BIG‑IP-Systems automatisch entsprechend an. Darüber hinaus erkennt CIS die Erstellung neuer Ingress-, Route- und benutzerdefinierter Ressourcen und aktualisiert die BIG‑IP-Konfiguration entsprechend.

Obwohl Sie BIG‑IP in Kombination mit CIS verwenden können, um den Datenverkehr direkt auf Anwendungs-Pods zu verteilen, ist der NGINX Ingress Controller in der Praxis die ideale Lösung, um dynamische Änderungen an Anwendungs-Pods und Workloads, die eine große Anzahl von Diensten umfassen, zu erkennen und nachzuverfolgen – beispielsweise bei der horizontalen Skalierung Ihrer Anwendungs-Pods zur Anpassung an eine veränderte Nachfrage.

Ein weiterer Vorteil der Bereitstellung des NGINX Ingress Controllers besteht darin, dass die Kontrolle über den Anwendungslastenausgleich auf die DevOps-Teams übertragen wird, die für die Anwendungen selbst verantwortlich sind. Dank seiner leistungsstarken Steuerungsebene und seines DevOps-zentrierten Designs eignet er sich besonders gut für sich schnell ändernde DevOps-Anwendungsfälle – etwa direkte Neukonfigurationen und rollierende Updates – über Kubernetes-Services in mehreren Namespaces hinweg. Der NGINX Ingress Controller verwendet die native Kubernetes-API, um Pods bei ihrer Skalierung zu erkennen.

So arbeiten BIG-IP und NGINX Ingress Controller zusammen

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

Die IngressLink-Ressource ist eine einfache Erweiterung, die eine Kubernetes-CustomResourceDefinition (CRD) verwendet, um den NGINX Ingress Controller und BIG‑IP miteinander zu „verknüpfen“. Vereinfacht gesagt ermöglicht sie CIS, BIG‑IP zu „informieren“, sobald sich die Gruppe der NGINX Ingress Controller-Pods geändert hat. Anhand dieser Informationen kann BIG‑IP die entsprechenden Richtlinien für den Lastenausgleich flexibel anpassen.

Wenn BIG‑IP für den Lastenausgleich der Kubernetes-Cluster bereitgestellt ist und der NGINX Ingress Controller den ein- und ausgehenden Datenverkehr verarbeitet, sieht der Datenfluss wie folgt aus:

1. BIG‑IP leitet externen Datenverkehr an die Instanzen des NGINX Ingress Controllers weiter.
2. Der NGINX Ingress Controller verteilt den Datenverkehr auf die entsprechenden Dienste innerhalb des Clusters.
3. Da der NGINX Ingress Controller außerordentlich effizient ist, kann eine stabile Gruppe von Instanzen häufige und umfangreiche Änderungen an den Anwendungs-Pods bewältigen. Wenn Ihr NGINX Ingress Controller jedoch horizontal hoch- oder herunterskaliert werden muss (um Spitzen und Rückgänge beim Datenverkehr zu bewältigen), informiert CIS BIG‑IP über die Änderungen (über die IngressLink-Ressource), sodass sich BIG‑IP schnell daran anpassen kann.

Erste Schritte

Weitere Informationen zur Funktionsweise der IngressLink-Ressource sowie eine Anleitung zur Bereitstellung finden Sie in der F5 CloudDocs-Dokumentation.

Fordern Sie zunächst Ihre kostenlose 30-Tage-Testversion von NGINX Ingress Controller mit NGINX App Protect WAF und DoS an. Wenn Sie BIG‑IP noch nicht nutzen, wählen Sie auf F5.com die Testversion aus, die am besten zu Ihrem Team passt.

Über den Autor

Micheál KingstonSenior-Produktmanager

Weitere Blogbeiträge von Micheál Kingston