[Redaktion– Dieser Beitrag ist ein Auszug aus unserem umfassenden E-Book „Kubernetes-Datenverkehr mit F5 NGINX verwalten: Ein Praxisleitfaden“. Laden Sie es noch heute kostenlos herunter.]
Neben HTTP-Datenverkehr verteilt der NGINX Ingress Controller auch TCP- und UDP-Datenverkehr, sodass Sie damit den Datenverkehr für eine Vielzahl von Anwendungen und Dienstprogrammen verwalten können, die auf diesen Protokollen basieren, darunter:
- MySQL, LDAP und MQTT – TCP-basierte Apps, die von vielen beliebten Anwendungen verwendet werden
- DNS, Syslog und RADIUS – UDP-basierte Dienstprogramme, die von Edge-Geräten und nicht transaktionsorientierten Anwendungen verwendet werden
Der TCP- und UDP-Lastenausgleich mit dem NGINX Ingress Controller ist auch unter den folgenden Umständen eine effektive Lösung für die Verteilung des Netzwerkverkehrs auf Kubernetes-Anwendungen:
- Sie verwenden Ende-zu-Ende-Verschlüsselung (EE2E), wobei die Anwendung anstelle des NGINX Ingress Controllers die Ver- und Entschlüsselung übernimmt
- Sie benötigen einen leistungsstarken Lastenausgleich für Anwendungen, die auf TCP oder UDP basieren.
- Sie möchten den Änderungsaufwand bei der Migration eines bestehenden Netzwerk-Load-Balancers (TCP/UDP) in eine Kubernetes-Umgebung minimieren
Der NGINX Ingress Controller umfasst zwei NGINX-Ingress-Ressourcen, die TCP/UDP-Lastverteilung unterstützen:
- GlobalConfiguration-Ressourcen werden in der Regel von Clusteradministratoren verwendet, um die TCP/UDP-Ports (
Listener) festzulegen, die DevOps-Teams zur Verfügung stehen. Beachten Sie, dass jede Bereitstellung des NGINX Ingress Controllers nur über eine GlobalConfiguration-Ressource verfügen kann. - TransportServer-Ressourcen werden in der Regel von DevOps-Teams verwendet, um den TCP/UDP-Lastenausgleich für ihre Anwendungen zu konfigurieren. Der NGINX Ingress Controller lauscht nur an Ports, die vom Administrator in der GlobalConfiguration-Ressource eingerichtet wurden. Dies verhindert Portkonflikte und bietet eine zusätzliche Sicherheitsebene, da sichergestellt wird, dass DevOps-Teams für öffentliche externe Dienste nur Ports freigeben, die der Administrator zuvor als sicher eingestuft hat.
Das folgende Diagramm zeigt einen beispielhaften Anwendungsfall für die Ressourcen GlobalConfiguration und TransportServer. In „gc.yaml“ definiert der Clusteradministrator TCP- und UDP-Listener in einer GlobalConfiguration-Ressource. In „ts.yaml“ verweist ein DevOps-Techniker auf den TCP-Listener in einer TransportServer-Ressource, die den Datenverkehr an eine MySQL-Bereitstellung weiterleitet.
Die GlobalConfiguration-Ressource in gc.yaml definiert zwei Listener: einen UDP-Listener an Port 514 für die Verbindung mit einem Syslog-Dienst und einen TCP-Listener an Port 5353 für die Verbindung mit einem MySQL-Dienst.
Codebeispiel wird geladen…
Die Zeilen 6–8 der TransportServer-Ressource in ts.yaml verweisen anhand des Namens auf den in gc.yaml definierten TCP-Listener (mysql-tcp). Die Zeilen 9–14 definieren die Routingregel, die den TCP-Datenverkehr an den Upstream mysql-db weiterleitet.
Codebeispiel wird geladen…
In diesem Beispiel verwendet ein DevOps-Engineer den MySQL-Client, um zu überprüfen, ob die Konfiguration funktioniert. Dies wird durch die Ausgabe mit der Liste der Tabellen in der Datenbank „rawdata_content_schema“ innerhalb der MySQL-Bereitstellung bestätigt.
$ echo “SHOW TABLES” | mysql –h <external_IP_address> -P <port> -u <user> –p rawdata_content_schema Enter Password: <password>
Tables_in_rawdata_content_schema
authors
postsTransportServer-Ressourcen für UDP-Datenverkehr werden auf ähnliche Weise konfiguriert. Ein vollständiges Beispiel finden Sie unter „Grundlegender TCP/UDP-Lastenausgleich“ im Repository des NGINX Ingress Controllers auf GitHub. Erfahrene NGINX-Benutzer können die TransportServer-Ressource mithilfe des ConfigMap-Schlüssels „stream-snippets“ um native NGINX-Konfigurationen erweitern, wie im Beispiel „Unterstützung für TCP/UDP-Lastenausgleich“ im Repository gezeigt.
Weitere Informationen zu den Funktionen, die Sie in TransportServer-Ressourcen konfigurieren können, finden Sie in der Dokumentation zum NGINX Ingress Controller.
Dieser Beitrag ist ein Auszug aus unserem umfassenden E-Book „Kubernetes-Datenverkehr mit NGINX verwalten: Ein Praxisleitfaden“. Laden Sie es noch heute kostenlos herunter.
Testen Sie den auf NGINX Plus basierenden NGINX Ingress Controller selbst im Rahmen einer 30-tägigen kostenlosen Testversion oder kontaktieren Sie uns noch heute, um Ihre Anwendungsfälle zu besprechen.
Ü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.