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.
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.
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:
A
-Eintrag für einen Dienst bereitstellt. Leider gibt es kein Äquivalent für lokale Cluster.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:
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.
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."