Die Einrichtung und Verwaltung einer robusten Kubernetes-Umgebung erfordert eine reibungslose Zusammenarbeit zwischen Ihren Netzwerk- und Anwendungsteams. Ihre Prioritäten und Arbeitsweisen unterscheiden sich jedoch meist erheblich, was zu Konflikten mit potenziell schwerwiegenden Folgen führen kann – einer langsamen Anwendungsentwicklung, verzögerten Bereitstellungen und sogar Netzwerkausfällen.
Nur wenn beide Teams erfolgreich auf ein gemeinsames Ziel hinarbeiten, können moderne Anwendungen termingerecht und mit der erforderlichen Sicherheit und Skalierbarkeit bereitgestellt werden. Wie können Sie also die Fähigkeiten und das Fachwissen beider Teams optimal nutzen und sie zugleich dabei unterstützen, Hand in Hand zu arbeiten?
In unserem Whitepaper „Get Me to the Cluster“ stellen wir ausführlich eine Lösung vor, die externen Zugriff auf Kubernetes-Dienste ermöglicht und Netzwerk- und Anwendungsteams dabei unterstützt, ihre Stärken konfliktfrei zu bündeln.
So machen Sie Anwendungen in Kubernetes-Clustern zugänglich
Die Lösung ist speziell für Kubernetes-Cluster ausgelegt, die lokal gehostet werden und deren Knoten auf Bare-Metal-Systemen oder herkömmlichen virtuellen Linux-Maschinen (VMs) ausgeführt werden. Dabei stellen standardmäßige Layer-2-Switches und Layer-3-Router die Netzwerkinfrastruktur für die Kommunikation im Rechenzentrum bereit. Für in der Cloud gehostete Kubernetes-Cluster ist die Lösung nicht geeignet, da Cloud-Anbieter weder die Kontrolle über die zentrale Netzwerkinfrastruktur ihrer Rechenzentren noch über die Netzwerkinfrastruktur ihrer verwalteten Kubernetes-Umgebungen zulassen.
Bevor wir auf die Einzelheiten unserer Lösung eingehen, sehen wir uns an, warum andere gängige Methoden zur Bereitstellung von Anwendungen in einem Kubernetes-Cluster bei On-Premises-Implementierungen nicht funktionieren:
- Service – Fasst Pods zusammen, auf denen dieselben Anwendungen ausgeführt werden. Dies eignet sich hervorragend für die interne Kommunikation zwischen Pods, ist jedoch nur innerhalb des Clusters sichtbar und hilft daher nicht dabei, Anwendungen extern zugänglich zu machen.
- NodePort – Öffnet einen bestimmten Port auf jedem Knoten im Cluster und leitet den Datenverkehr an die entsprechende App weiter. Externe Benutzer können dadurch zwar auf den Dienst zugreifen, optimal ist dies jedoch nicht, da die Konfiguration statisch ist, TCP-Ports mit hohen Nummern (anstelle bekannter niedriger Portnummern) verwendet und die Portnummern mit anderen Apps abgestimmt werden müssen. Außerdem können sich verschiedene Apps keine gemeinsamen TCP-Ports teilen.
- LoadBalancer – Verwendet die NodePort-Definitionen auf jedem Knoten, um einen Netzwerkpfad von außen zu Ihren Kubernetes-Knoten zu erstellen. Dies eignet sich hervorragend für in der Cloud gehostetes Kubernetes, da AWS, Google Cloud Platform, Microsoft Azure und die meisten anderen Cloud-Anbieter diese Funktion unterstützen. Sie lässt sich einfach konfigurieren, funktioniert zuverlässig und stellt die erforderliche öffentliche IP-Adresse sowie den passenden DNS-
A-Eintrag für einen Dienst bereit. Leider gibt es keine entsprechende Lösung für lokale Cluster.
Externen Benutzerzugriff auf lokale Kubernetes-Cluster ermöglichen
Damit bleibt uns das Kubernetes-Ingress-Objekt, das speziell für Datenverkehr konzipiert ist, der von Benutzern außerhalb des Clusters zu Pods innerhalb des Clusters fließt (Nord-Süd-Datenverkehr). Ingress erstellt einen externen HTTP/HTTPS-Zugangspunkt für den Cluster – eine einzelne IP-Adresse oder einen DNS-Namen, über den externe Benutzer auf mehrere Dienste zugreifen können. Genau das brauchen wir! Das Ingress-Objekt wird durch einen Ingress-Controller implementiert – in unserer Lösung durch den für Unternehmen ausgelegten F5 NGINX Ingress Controller auf Basis von NGINX Plus.
Es mag Sie überraschen, dass eine weitere Schlüsselkomponente der Lösung das Border Gateway Protocol (BGP) ist, ein Routingprotokoll der Schicht 3. Doch eine hervorragende Lösung muss nicht komplex sein!
Die in „Get Me to the Cluster“ beschriebene Lösung besteht tatsächlich aus vier Komponenten:
- 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 implementiert und wird vom Netzwerkteam unterstützt.
- Project Calico-CNI-Netzwerk – Project Calico ist eine Open-Source-Netzwerklösung, die Umgebungen in lokalen Rechenzentren flexibel miteinander verbindet und gleichzeitig eine präzise Steuerung des Datenverkehrs ermöglicht. Für die Vernetzung im Kubernetes-Cluster verwenden wir das CNI-Plug-in von Project Calico mit aktiviertem BGP. So können Sie die den Pods zugewiesenen IP-Adresspools steuern und Netzwerkprobleme schnell erkennen.
- NGINX Ingress Controller auf Basis von NGINX Plus – Mit NGINX Ingress Controller können Sie die IP-Adressen der Dienstendpunkte der Pods überwachen und die Liste der Upstream-Dienste automatisch neu konfigurieren, ohne die Verarbeitung des Datenverkehrs zu unterbrechen. Anwendungsteams können außerdem die vielen weiteren unternehmenstauglichen Layer-7-HTTP-Funktionen von NGINX Plus nutzen, darunter aktive Integritätsprüfungen, mTLS und JWT-basierte Authentifizierung.
- NGINX Plus als Reverse-Proxy am Netzwerkrand – NGINX Plus fungiert am Rand des Kubernetes-Clusters als Reverse-Proxy und stellt eine Verbindung zwischen den Switches und Routern im Rechenzentrum und dem internen Netzwerk im Kubernetes-Cluster her. Dies dient als Ersatz für das Kubernetes-LoadBalancer-Objekt und verwendet Quagga für BGP.
Das Diagramm veranschaulicht die Lösungsarchitektur und zeigt, welche Protokolle die Lösungskomponenten für die Kommunikation verwenden, nicht jedoch die Reihenfolge, in der die Daten während der Verarbeitung von Anfragen ausgetauscht werden.
Whitepaper kostenlos herunterladen
Durch die gemeinsame Implementierung einer Lösung mit klar definierten Komponenten können Netzwerk- und Anwendungsteams auf einfache Weise optimale Leistung und Zuverlässigkeit gewährleisten.
Unsere Lösung nutzt moderne Netzwerktools und -protokolle sowie bestehende Architekturen. Da sie kostengünstig und einfach zu implementieren, zu verwalten und zu unterstützen ist, erleichtert sie die Zusammenarbeit und schlägt 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.
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.