BLOG | NGINX

Bringen Sie mich zum Cluster … mit BGP?

NGINX-Teil-von-F5-horiz-schwarz-Typ-RGB
Chris Akker Miniaturbild
Chris Akker
Veröffentlicht am 28. Februar 2023

Das Erstellen und Verwalten einer robusten Kubernetes-Umgebung erfordert eine reibungslose Zusammenarbeit zwischen Ihren Netzwerk- und Anwendungsteams. Ihre Prioritäten und Arbeitsweisen sind jedoch in der Regel völlig unterschiedlich, was zu Konflikten mit potenziell schwerwiegenden Folgen führt – langsame App-Entwicklung, verzögerte Bereitstellung und sogar Netzwerkausfallzeiten.

Nur der Erfolg beider Teams, die auf ein gemeinsames Ziel hinarbeiten, kann gewährleisten, dass die modernen Anwendungen von heute pünktlich und mit der erforderlichen Sicherheit und Skalierbarkeit bereitgestellt werden. Wie können Sie also die Fähigkeiten und das Fachwissen jedes Teams nutzen und ihnen gleichzeitig dabei helfen, zusammenzuarbeiten?

In unserem Whitepaper „Get Me to the Cluster“ beschreiben wir ausführlich eine Lösung zum Aktivieren des externen Zugriffs auf Kubernetes-Dienste, die es Netzwerk- und Anwendungsteams ermöglicht, ihre Stärken ohne Konflikte zu bündeln.

So stellen Sie Apps in Kubernetes-Clustern bereit

Die Lösung funktioniert speziell für vor Ort gehostete Kubernetes-Cluster, wobei die Knoten auf Bare-Metal- oder herkömmlichen virtuellen Linux-Maschinen (VMs) laufen und Standard-Layer-2-Switches und Layer-3-Router die Netzwerkverbindung für die Kommunikation im Rechenzentrum bereitstellen. Dies gilt nicht für in der Cloud gehostete Kubernetes-Cluster, da die Cloud-Anbieter uns weder die Kontrolle über das Kernnetzwerk in ihren Rechenzentren noch über das Netzwerk in ihrer verwalteten Kubernetes-Umgebung gestatten.

Diagramm von vor Ort gehosteten Kubernetes-Clustern mit Knoten und Standard-Layer-2-Switches sowie Layer-3-Routern, die die Vernetzung für die Kommunikation im Rechenzentrum bereitstellen.

Bevor wir auf die Einzelheiten unserer Lösung eingehen, wollen wir uns ansehen, warum andere Standardmethoden zum Bereitstellen von Anwendungen in einem Kubernetes-Cluster für lokale Bereitstellungen nicht funktionieren:

  • Service – Gruppiert Pods, auf denen dieselben Apps ausgeführt werden. Dies eignet sich hervorragend für die interne Pod-zu-Pod -Kommunikation, ist jedoch nur innerhalb des Clusters sichtbar und trägt daher nicht dazu bei, Apps extern verfügbar zu machen.
  • NodePort – Öffnet einen bestimmten Port auf jedem Knoten im Cluster und leitet den Datenverkehr an die entsprechende App weiter. Dadurch können externe Benutzer zwar auf den Dienst zugreifen, es ist jedoch nicht ideal, da die Konfiguration statisch ist und Sie TCP-Ports mit hohen Nummern verwenden müssen (anstelle bekannter niedrigerer Portnummern) und Portnummern mit anderen Apps koordinieren müssen. Sie können gemeinsame TCP-Ports auch nicht zwischen verschiedenen Apps teilen.
  • LoadBalancer – Verwendet die NodePort-Definitionen auf jedem Knoten, um einen Netzwerkpfad von der Außenwelt zu Ihren Kubernetes-Knoten zu erstellen. Es eignet sich hervorragend für in der Cloud gehostetes Kubernetes, da AWS, Google Cloud Platform, Microsoft Azure und die meisten anderen Cloud-Anbieter es als leicht konfigurierbare Funktion unterstützen, die gut funktioniert und die erforderliche öffentliche IP-Adresse und den passenden DNS- A -Eintrag für einen Dienst bereitstellt. Leider gibt es kein Äquivalent für lokale Cluster.

Externen Benutzern den Zugriff auf lokale Kubernetes-Cluster ermöglichen

Bleibt noch das Kubernetes- Ingress-Objekt , das speziell für den Datenverkehr konzipiert ist, der von Benutzern außerhalb des Clusters zu Pods innerhalb des Clusters fließt (Nord-Süd-Datenverkehr). Der Ingress erstellt einen externen HTTP/HTTPS-Einstiegspunkt für den Cluster – eine einzelne IP-Adresse oder einen DNS-Namen, unter dem externe Benutzer auf mehrere Dienste zugreifen können. Das ist genau das, was wir brauchen! Das Ingress-Objekt wird von einem Ingress-Controller implementiert – in unserer Lösung dem unternehmenstauglichen F5 NGINX Ingress Controller basierend auf NGINX Plus .

Es mag Sie überraschen, dass eine weitere Schlüsselkomponente der Lösung das Border Gateway Protocol (BGP) ist, ein Layer-3-Routingprotokoll. Aber eine großartige Lösung muss nicht komplex sein!

Die in Get Me to the Cluster beschriebene Lösung besteht eigentlich aus vier Komponenten:

  1. iBGP-Netzwerk – Internes BGP (iBGP) wird zum Austausch von Routing-Informationen innerhalb eines autonomen Systems (AS) im Rechenzentrum verwendet und trägt dazu bei, die Zuverlässigkeit und Skalierbarkeit des Netzwerks sicherzustellen. iBGP ist in den meisten Rechenzentren bereits vorhanden und wird vom Netzwerkteam unterstützt.
  2. Project Calico CNI-NetzwerkProject Calico ist eine Open-Source-Netzwerklösung, die Umgebungen in lokalen Rechenzentren flexibel verbindet und gleichzeitig eine detaillierte Kontrolle über den Verkehrsfluss ermöglicht. Wir verwenden das CNI-Plug-in von Project Calico für die Vernetzung im Kubernetes-Cluster mit aktiviertem BGP. Auf diese Weise können Sie die den Pods zugewiesenen IP-Adresspools steuern und etwaige Netzwerkprobleme schnell erkennen.
  3. NGINX Ingress Controller basierend auf NGINX Plus – Mit dem NGINX Ingress Controller können Sie die Service-Endpunkt-IP-Adressen der Pods überwachen und die Liste der Upstream-Dienste automatisch neu konfigurieren, ohne dass die Verkehrsverarbeitung unterbrochen wird. Anwendungsteams können auch die vielen anderen Layer-7-HTTP-Funktionen der Unternehmensklasse in NGINX Plus nutzen, darunter aktive Integritätsprüfungen, mTLS und JWT-basierte Authentifizierung.
  4. NGINX Plus als Reverse-Proxy am Rand – NGINX Plus befindet sich als Reverse-Proxy am Rand des Kubernetes-Clusters und bietet einen Pfad zwischen Switches und Routern im Rechenzentrum und dem internen Netzwerk im Kubernetes-Cluster. Dies fungiert als Ersatz für das Kubernetes LoadBalancer-Objekt und verwendet Quagga für BGP.

Das Diagramm veranschaulicht die Lösungsarchitektur und gibt an, welche Protokolle die Lösungskomponenten zur Kommunikation verwenden, nicht jedoch die Reihenfolge, in der Daten während der Anforderungsverarbeitung ausgetauscht werden.

Diagramm zur Veranschaulichung der Lösungsarchitektur, das angibt, welche Protokolle die Lösungskomponenten zur Kommunikation verwenden

Kostenloses Whitepaper herunterladen

Durch die Zusammenarbeit bei der Implementierung einer Lösung mit genau definierten Komponenten können Netzwerk- und Anwendungsteams problemlos optimale Leistung und Zuverlässigkeit erzielen.

Unsere Lösung nutzt moderne Netzwerktools, Protokolle und vorhandene Architekturen. Da es kostengünstig und einfach zu implementieren, zu verwalten und zu unterstützen ist, sorgt es für mehr Benutzerfreundlichkeit und baut Brücken zwischen Ihren Teams.

Um den Code in Aktion zu sehen und Schritt für Schritt zu erfahren, wie Sie unsere Lösung bereitstellen, laden Sie „Get Me to the Cluster“ kostenlos herunter .


„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."