Sie sind ein moderner App-Entwickler. Sie verwenden eine Reihe von Open-Source- und möglicherweise auch kommerziellen Tools, um neue Apps und Container zu entwickeln, zu testen, bereitzustellen und zu verwalten. Sie haben sich für Kubernetes entschieden, um diese Container und Pods in Entwicklungs-, Test-, Staging- und Produktionsumgebungen auszuführen. Sie setzen auf die Architekturen und Konzepte von Microservices, der Cloud Native Computing Foundation und anderen modernen Branchenstandards.
Auf dieser Reise haben Sie festgestellt, dass Kubernetes tatsächlich leistungsstark ist. Wahrscheinlich waren Sie aber auch überrascht, wie schwierig, unflexibel und frustrierend es sein kann. Änderungen und Aktualisierungen an Routern, Firewalls, Load Balancern und anderen Netzwerkgeräten umzusetzen und zu koordinieren, kann schnell überwältigend werden – insbesondere im eigenen Rechenzentrum! Da kommen Entwicklern schon mal die Tränen.
Wie Sie diese Herausforderungen bewältigen, hängt maßgeblich davon ab, wo und wie Sie Kubernetes betreiben (als Managed Service oder lokal). Dieser Artikel befasst sich mit dem TCP-Load-Balancing – einem zentralen Bereich, in dem sich die Wahl der Bereitstellungsart auf die Benutzerfreundlichkeit auswirkt.
TCP-Lastverteilung mit verwaltetem Kubernetes (auch bekannt als die einfache Option)
Wenn Sie für Kubernetes einen verwalteten Dienst nutzen, etwa den eines Public-Cloud-Anbieters, wird Ihnen ein Großteil der mühsamen Netzwerkkonfiguration abgenommen. Mit nur einem Befehl (kubectl apply -f loadbalancer.yaml) erhalten Sie über den Service-Typ LoadBalancer eine öffentliche IP-Adresse, einen DNS-Eintrag und einen TCP-Load-Balancer. Sie könnten beispielsweise den Amazon Elastic Load Balancer so konfigurieren, dass er den Datenverkehr auf Pods mit dem NGINX Ingress Controller verteilt. Mit diesem Befehl müssen Sie sich dann keine Gedanken mehr machen, wenn sich die Backends ändern. Es ist so einfach, dass Sie es bestimmt für selbstverständlich halten!
TCP-Lastverteilung mit lokal betriebenem Kubernetes (auch bekannt als die schwierige Variante)
Bei On-Premises-Clustern sieht die Situation völlig anders aus. Sie oder Ihre Netzwerkverantwortlichen müssen die erforderliche Netzwerkinfrastruktur bereitstellen. Vielleicht fragen Sie sich: „Warum ist es so schwierig, Benutzern den Zugriff auf meine Kubernetes-Anwendungen zu ermöglichen?“ Die Antwort ist einfach, aber etwas überraschend: Der Service-Typ LoadBalancer, das Eingangstor zu Ihrem Cluster, existiert in Wirklichkeit gar nicht.
Um Ihre Apps und Services außerhalb des Clusters verfügbar zu machen, verlangt Ihr Netzwerkteam wahrscheinlich Tickets, Genehmigungen, die Einhaltung bestimmter Verfahren und vielleicht sogar Sicherheitsprüfungen – und das alles, bevor es seine Geräte neu konfiguriert. Oder Sie müssen möglicherweise alles selbst erledigen, wodurch die Anwendungsbereitstellung nahezu zum Erliegen kommt. Schlimmer noch: Sie wagen es nicht, Änderungen an Kubernetes Services vorzunehmen, denn wenn sich der NodePort ändert, könnte der Datenverkehr blockiert werden! Und wir alle wissen, wie sehr Benutzer 500-Fehler mögen. Ihrem Chef gefallen sie wahrscheinlich noch weniger.
Eine bessere Lösung für lokales TCP-Load-Balancing: NGINX Loadbalancer für Kubernetes
Mit unserem neuen Projekt können Sie aus der „schwierigen Option“ eine „einfache Option“ machen: NGINX Loadbalancer for Kubernetes. Dieses kostenlose Projekt ist ein Kubernetes-Controller, der den NGINX Ingress Controller überwacht und automatisch eine externe, für den Lastenausgleich konfigurierte NGINX Plus-Instanz aktualisiert. Dank seines unkomplizierten Designs lässt es sich einfach installieren und betreiben. Mit dieser Lösung können Sie TCP-Lastenausgleich in lokalen Umgebungen implementieren und sicherstellen, dass neue Anwendungen und Dienste sofort erkannt werden und für den Datenverkehr verfügbar sind – ganz ohne manuelles Eingreifen.
Architektur und Ablauf
NGINX Loadbalancer for Kubernetes wird innerhalb eines Kubernetes-Clusters ausgeführt. Er ist bei Kubernetes registriert, um den nginx-ingress-Service (NGINX Ingress Controller) zu überwachen. Wenn sich die Backends ändern, erfasst NGINX Loadbalancer for Kubernetes die Worker-IPs und die TCP-Portnummern der NodePorts und sendet anschließend die IP:Ports über die NGINX Plus API an NGINX Plus. Die NGINX-Upstream-Server werden aktualisiert, wobei kein Neuladen erforderlich ist, und NGINX Plus verteilt den Datenverkehr auf die richtigen Upstream-Server und Kubernetes-NodePorts. Zusätzliche NGINX Plus-Instanzen können hinzugefügt werden, um Hochverfügbarkeit zu erreichen.
Ein Einblick in den NGINX Loadbalancer für Kubernetes im Einsatz
Im folgenden Screenshot sind zwei Fenster zu sehen, die den bereitgestellten NGINX Loadbalancer für Kubernetes bei der Arbeit zeigen:
- Diensttyp – LoadBalancer (für
nginx-ingress) - Externe IP-Adresse – Stellt eine Verbindung zu den NGINX Plus-Servern her
- Ports – NodePort wird 443:30158 mit den entsprechenden NGINX-Upstream-Servern zugeordnet (wie im NGINX Plus Echtzeit-Dashboard dargestellt)
- Protokolle – Zeigt an, dass der NGINX Loadbalancer für Kubernetes erfolgreich Daten an NGINX Plus sendet
Hinweis: In diesem Beispiel lauten die Kubernetes-Worker-Knoten 10.1.1.8 und 10.1.1.10
Legen Sie noch heute los
Wenn Sie die Netzwerkprobleme am Rand Ihres Kubernetes-Clusters leid sind, probieren Sie das Projekt aus und teilen Sie uns Ihre Meinung mit. Der Quellcode von NGINX Loadbalancer for Kubernetes ist Open Source (unter der Apache-2.0-Lizenz); sämtliche Installationsanweisungen sind auf GitHub verfügbar.
Wenn Sie uns Feedback geben möchten, hinterlassen Sie einen Kommentar im Repository oder schreiben Sie uns im NGINX Community Slack.
Ü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.