Dynamisches A/B-Kubernetes-Multicluster-Load-Balancing und Sicherheitskontrollen mit NGINX Plus
Sie sind ein moderner Platform-Ops- oder DevOps-Ingenieur. Sie verwenden eine Bibliothek mit Open Source-Tools (und möglicherweise einigen kommerziellen Tools), um neue Apps und Container für Ihr Entwicklerteam zu testen, bereitzustellen und zu verwalten. Sie haben Kubernetes ausgewählt, um diese Container und Pods in Entwicklungs-, Test-, Staging- und Produktionsumgebungen auszuführen. Sie haben sich mit den Architekturen und Konzepten von Microservices vertraut gemacht und größtenteils funktioniert es ziemlich gut. Auf dieser Reise sind Ihnen jedoch einige Hindernisse begegnet.
Wie können Sie beispielsweise beim Erstellen und Einführen neuer Cluster, Dienste und Anwendungen diese neuen Ressourcen problemlos in die Produktion integrieren oder migrieren, ohne dass es zu Datenverkehrseinbrüchen kommt? Bei herkömmlichen Netzwerkgeräten sind Neuladungen oder Neustarts erforderlich, wenn Konfigurationsänderungen an DNS-Einträgen, Lastenausgleichsmodulen, Firewalls und Proxys vorgenommen werden. Diese Anpassungen können nicht neu konfiguriert werden, ohne Ausfallzeiten zu verursachen, da ein „Diensteausfall“ oder ein „Wartungsfenster“ erforderlich ist, um DNS, Load Balancer und Firewall-Regeln zu aktualisieren. Meistens müssen Sie ein gefürchtetes Serviceticket einreichen und auf die Genehmigung und Durchführung der Änderungen durch ein anderes Team warten.
Wartungsfenster können Ihr Team in Verlegenheit bringen, die Anwendungsbereitstellung verzögern und Sie zu der Aussage verleiten: „Es muss einen besseren Weg geben, den Datenverkehr zu verwalten!“ Lassen Sie uns also eine Lösung erkunden, die Sie wieder auf die Überholspur bringt.
Aktiv-Aktiv-Lastausgleich für mehrere Cluster
Wenn Sie über mehrere Kubernetes-Cluster verfügen, empfiehlt es sich, den Datenverkehr gleichzeitig an beide Cluster weiterzuleiten. Eine noch bessere Option besteht darin, eine A/B-, Canary- oder Blue-Green-Verkehrsaufteilung durchzuführen und einen kleinen Prozentsatz Ihres Datenverkehrs als Test zu senden. Dazu können Sie NGINX Plus mit ngx_http_split_clients_module verwenden.
Das Modul „HTTP Split Clients“ wurde von NGINX Open Source geschrieben und ermöglicht die Verteilung des Anforderungsverhältnisses auf der Grundlage eines Schlüssels. In diesem Anwendungsfall sind die Cluster die „Upstreams“ von NGINX. Wenn also die Clientanforderungen eintreffen, wird der Datenverkehr auf zwei Cluster aufgeteilt. Der Schlüssel, der zur Bestimmung der Client-Anforderung verwendet wird, ist eine beliebige verfügbare NGINX-Client- $variable . Um dies für jede Anfrage zu steuern, verwenden Sie die Variable $request_id . Dabei handelt es sich um eine eindeutige Nummer, die von NGINX jeder eingehenden Anfrage zugewiesen wird.
Um die Aufteilungsverhältnisse zu konfigurieren, legen Sie fest, welche Prozentsätze jedem Cluster zugewiesen werden sollen. In diesem Beispiel verwenden wir K8s Cluster1 als „großen Cluster“ für die Produktion und Cluster2 als „kleinen Cluster“ für Tests vor der Produktion. Wenn Sie einen kleinen Cluster für die Staging-Umgebung hätten, könnten Sie ein Verhältnis von 90:10 verwenden und 10 % Ihres Datenverkehrs auf dem kleinen Cluster testen, um sicherzustellen, dass alles funktioniert, bevor Sie neue Änderungen im großen Cluster einführen. Wenn Ihnen das zu riskant erscheint, können Sie das Verhältnis auch auf 95:5 ändern. Ehrlich gesagt können Sie jedes beliebige Verhältnis zwischen 0 und 100 % auswählen.
Für den Großteil des Echtzeit-Produktionsdatenverkehrs wünschen Sie sich wahrscheinlich ein Verhältnis von 50:50, bei dem Ihre beiden Cluster gleich groß sind. Sie können jedoch problemlos andere Verhältnisse angeben, basierend auf der Clustergröße oder anderen Details. Sie können das Verhältnis einfach auf 0:100 (oder 100:0) einstellen und einen ganzen Cluster ohne Ausfallzeiten aktualisieren, patchen, reparieren oder sogar ersetzen. Lassen Sie NGINX split_clients die Anfragen an den Live-Cluster weiterleiten, während Sie sich auf dem anderen Cluster um die Probleme kümmern.
# Nginx Multi-Cluster-Lastausgleich
# HTTP Split Clients-Konfiguration für Cluster1:Cluster2-Verhältnisse
# Geben Sie die Verhältnisse 100, 99, 50, 1, 0 % an (fügen Sie sie nach Bedarf hinzu/ändern Sie sie)
# Basierend auf
# https://www.nginx.com/blog/dynamic-a-b-testing-with-nginx-plus/
# Chris Akker – Jan 2024
#
split_clients $request_id $split100 {
* cluster1-cafe; # Der gesamte Datenverkehr zu Cluster1
}
split_clients $request_id $split99 {
99 % cluster1-cafe; # 99 % cluster1, 1 % cluster2
* cluster2-cafe;
}
split_clients $request_id $split50 {
50 % cluster1-cafe; # 50 % Cluster1, 50 % Cluster2
* Cluster2-Cafe;
}
split_clients $request_id $split1 {
1,0 % Cluster1-Cafe; # 1 % zu Cluster1, 99 % zu Cluster2
* Cluster2-Cafe;
}
split_clients $request_id $split0 {
* Cluster2-Cafe; # Der gesamte Verkehr zu Cluster2
}
# Wählen Sie basierend auf dem Verhältnis den Cluster Upstream aus
map $split_level $upstream {
100 $split100;
99 $split99;
50 $split50;
1,0 $split1;
0 $split0;
Standard $split50;
}
Sie können die obige Konfiguration ergänzen oder bearbeiten, um sie an die benötigten Verhältnisse anzupassen (z. B. 90:10, 80:20, 60:40 usw.).
Notiz: NGINX verfügt außerdem über ein Split-Clients-Modul für TCP-Verbindungen im Stream-Kontext, das für Nicht-HTTP-Verkehr verwendet werden kann. Dadurch wird der Datenverkehr basierend auf neuen TCP-Verbindungen statt auf HTTP-Anfragen aufgeteilt.
NGINX Plus Schlüssel-Wert-Speicher
Die nächste Funktion, die Sie verwenden können, ist der Schlüssel-Wert-Speicher von NGINX Plus. Dies ist ein Schlüssel-Wert-Objekt in einer gemeinsam genutzten NGINX-Speicherzone, das für viele verschiedene Anwendungsfälle der Datenspeicherung verwendet werden kann. Hier verwenden wir es, um den im obigen Abschnitt erwähnten Split-Ratio-Wert zu speichern. Mit NGINX Plus können Sie jeden Schlüsselwertdatensatz ändern, ohne NGINX neu zu laden. Dadurch können Sie diesen Split-Wert mit einem API-Aufruf ändern und so die dynamische Split-Funktion erstellen.
Anhand unseres Beispiels sieht das dann so aus:
{“cafe.example.com”:90}
Dieser KeyVal-Datensatz lautet:
Der Schlüssel ist der Hostname „cafe.example.com“
Der Wert für das Split-Verhältnis beträgt „90“
Anstatt das Aufteilungsverhältnis in den NGINX-Konfigurationsdateien fest zu codieren, können Sie stattdessen den Schlüssel-Wert-Speicher verwenden. Dadurch entfällt das Neuladen von NGINX, das zum Ändern eines statischen Split-Werts in NGINX erforderlich ist.
In diesem Beispiel ist NGINX so konfiguriert, dass das Aufteilungsverhältnis 90:10 beträgt, wobei der große Cluster1 für 90 % und der kleine Cluster2 für die restlichen 10 % zuständig ist. Da es sich um einen Schlüssel-Wert-Datensatz handelt, können Sie dieses Verhältnis mit der NGINX Plus-API dynamisch ändern, ohne dass die Konfiguration neu geladen werden muss! Das Modul „Split Clients“ verwendet diesen neuen Verhältniswert, sobald Sie ihn ändern, bei der nächsten Anfrage.
Erstellen Sie den KV-Eintrag und beginnen Sie mit einem Verhältnis von 50/50:
Fügen Sie dem KeyValue-Speicher einen neuen Datensatz hinzu, indem Sie einen API-Befehl an NGINX Plus senden:
curl -iX POST -d '{"cafe.example.com":50}' http://nginxlb:9000/api/8/http/keyvals/split
Änderung des KV-Rekords, Änderung auf das Verhältnis 90/10:
Ändern Sie das KeyVal-Split-Verhältnis auf 90, indem Sie eine HTTP-PATCH-Methode verwenden, um den KeyVal-Datensatz im Speicher zu aktualisieren:
curl -iX PATCH -d '{"cafe.example.com":90}' http://nginxlb:9000/api/8/http/keyvals/split
Als Nächstes überprüft das Vorproduktionstestteam, ob der neue Anwendungscode bereit ist. Sie stellen ihn im großen Cluster1 bereit und ändern das Verhältnis auf 100 %. Dadurch wird der gesamte Datenverkehr sofort an Cluster1 gesendet und Ihre neue Anwendung ist „live“, ohne dass es zu Verkehrsunterbrechungen, Dienstausfällen, Wartungsfenstern, Neustarts, Neuladungen oder vielen Tickets kommt. Es ist nur ein API-Aufruf erforderlich, um dieses Aufteilungsverhältnis zum gewünschten Zeitpunkt zu ändern.
Da der Wechsel von 90 % auf 100 % so einfach ist, können Sie das Verhältnis natürlich auch ganz einfach von 100:0 auf 50:50 (oder sogar 0:100) ändern. Sie können also über einen Hot-Backup-Cluster verfügen oder Ihre Cluster mit neuen Ressourcen horizontal skalieren. Bei voller Leistung können Sie sogar einen komplett neuen Cluster mit der aktuellsten Software, Hardware und den neuesten Software-Patches erstellen – und dabei die Anwendung bereitstellen und den Datenverkehr über einen bestimmten Zeitraum migrieren, ohne dass eine einzige Verbindung verloren geht!
Anwendungsfälle
Die Verwendung des Moduls „HTTP Split Clients“ mit dem dynamischen Schlüssel-Wert-Speicher kann die folgenden Anwendungsfälle ermöglichen:
- Aktiv-Aktiv-Lastausgleich – Zum Lastausgleich auf mehrere Cluster.
- Aktiv-passiver Lastausgleich – Zum Lastausgleich für primäre, Backup- und DR-Cluster und -Anwendungen.
- A/B-, Blue-Green- und Canary-Tests – Werden bei neuen Kubernetes-Anwendungen verwendet.
- Horizontale Cluster-Skalierung – Fügt weitere Cluster-Ressourcen hinzu und ändert das Verhältnis, wenn Sie bereit sind.
- Unterbrechungsfreie Cluster-Upgrades – Möglichkeit, einen Cluster zu verwenden, während Sie den anderen Cluster aktualisieren, patchen oder reparieren.
- Sofortiges Failover – Wenn bei einem Cluster ein schwerwiegendes Problem auftritt, können Sie das Verhältnis ändern, um Ihren anderen Cluster zu verwenden.
Konfigurationsbeispiele
Hier ist ein Beispiel für die Schlüssel-Wert-Konfiguration:
# Definieren Sie den Key Value Store, sichern Sie die Statusdatei, das Timeout und aktivieren Sie die Synchronisierung
keyval_zone zone=split:1m state=/var/lib/nginx/state/split.keyval timeout=365d sync;
keyval $host $split_level zone=split;
Und dies ist ein Beispiel für die Anwendungskonfiguration von cafe.example.com:
# Definieren Sie Server- und Standortblöcke für cafe.example.com mit TLS-Server { listen 443 ssl; Servername cafe.example.com; Statuszone https://cafe.example.com; SSL-Zertifikat /etc/ssl/nginx/cafe.example.com.crt; SSL-Zertifikatschlüssel /etc/ssl/nginx/cafe.example.com.key; Standort / { Statuszone /; Proxy-Set-Header Host $host; Proxy-http_Version 1.1; Proxy-Set-Header „Verbindung“ „“; Proxy-Passwort https://$upstream; # Datenverkehr auf Upstream-Blöcke aufteilen } # Definieren Sie 2 Upstream-Blöcke – einen für jeden Cluster # Server werden dynamisch von NLK verwaltet, Statusdateisicherung # Cluster1-Upstreams Upstream cluster1-cafe { Zone cluster1-cafe 256k; geringste_Zeit letztes_Byte; Keepalive 16; #vom NLK-Controller verwaltete Server status /var/lib/nginx/state/cluster1-cafe.state; } # Cluster2-Upstreams upstream cluster2-cafe { zone cluster2-cafe 256k; least_time last_byte; keepalive 16; #vom NLK-Controller verwaltete Server status /var/lib/nginx/state/cluster2-cafe.state; }
Die IP:Ports des Upstream-Servers werden von NGINX Loadbalancer für Kubernetes verwaltet, einem neuen Controller, der auch die NGINX Plus-API verwendet, um NGINX Plus dynamisch zu konfigurieren. Einzelheiten finden Sie im nächsten Abschnitt .
Werfen wir einen Blick auf den HTTP-Split-Verkehr im Zeitverlauf mit Grafana , einem beliebten Überwachungs- und Visualisierungstool. Sie verwenden den NGINX Prometheus Exporter (basierend auf njs ), um alle Ihre NGINX Plus-Metriken zu exportieren, die dann von Grafana gesammelt und grafisch dargestellt werden. Details zur Konfiguration von Prometheus und Grafana finden Sie hier .
Im Diagramm sind vier Upstream-Server dargestellt: Zwei für Cluster1 und zwei für Cluster2 . Wir verwenden ein HTTP-Lastgenerierungstool, um HTTP-Anfragen zu erstellen und sie an NGINX Plus zu senden.
In den drei folgenden Grafiken können Sie sehen, dass das Aufteilungsverhältnis zu Beginn der Grafik bei 50:50 liegt.
Dann ändert sich das Verhältnis um 12:56:30 auf 10:90.
Dann ändert es sich um 13:00:00 auf 90:10.
Funktionierende Konfigurationen von Prometheus und Grafana finden Sie im GitHub-Repository „NGINX Loadbalancer für Kubernetes“ .
Dynamische HTTP-Upstreams: NGINX Loadbalancer für Kubernetes
Sie können die statische NGINX-Upstream-Konfiguration mithilfe der NGINX Plus-API und des NGINX Loadbalancer für den Kubernetes -Controller in dynamische Cluster-Upstreams ändern. Dieses kostenlose Projekt ist ein Kubernetes-Controller , der den NGINX Ingress Controller überwacht und automatisch eine externe NGINX Plus -Instanz aktualisiert, die für den TCP/HTTP-Lastausgleich konfiguriert ist. Es hat ein sehr geradliniges Design und lässt sich leicht installieren und bedienen. Mit dieser Lösung können Sie TCP/HTTP-Lastausgleich in Kubernetes-Umgebungen implementieren und so sicherstellen, dass neue Apps und Dienste sofort erkannt werden und für den Datenverkehr verfügbar sind – ohne dass ein Neuladen erforderlich ist.
Architektur und Flow
NGINX Loadbalancer für Kubernetes befindet sich in einem Kubernetes-Cluster. Es ist bei Kubernetes registriert, um den NGINX Ingress Controller-Dienst ( nginx-ingress ) zu überwachen. Wenn es eine Änderung an den Ingress-Controllern gibt, sammelt NGINX Loadbalancer für Kubernetes die Worker-IPs und die NodePort-TCP-Portnummern und sendet die IP:Ports dann über die NGINX Plus-API an NGINX Plus.
Die NGINX-Upstream-Server werden aktualisiert, ohne dass ein Neuladen erforderlich ist, und NGINX Plus verteilt den Datenverkehr auf die richtigen Upstream-Server und Kubernetes-NodePorts. Um eine hohe Verfügbarkeit zu erreichen, können zusätzliche NGINX Plus-Instanzen hinzugefügt werden.
Ein Snapshot des NGINX Loadbalancer für Kubernetes in Aktion
Im folgenden Screenshot sind zwei Fenster zu sehen, die den bereitgestellten und funktionierenden NGINX Loadbalancer für Kubernetes zeigen:
- Servicetyp –
LoadBalancerfürnginx-ingress - Externe IP – Verbindung zu den NGINX Plus-Servern
- Ports – NodePort wird mit den entsprechenden NGINX-Upstream-Servern auf 443:30158 abgebildet (wie im Echtzeit-Dashboard von NGINX Plus angezeigt)
- Protokolle – Zeigt an, dass NGINX Loadbalancer für Kubernetes erfolgreich Daten an NGINX Plus sendet.
Notiz : In diesem Beispiel sind die Kubernetes-Arbeitsknoten 10.1.1.8 und 10.1.1.10
Hinzufügen von NGINX Plus-Sicherheitsfunktionen
Da immer mehr in Kubernetes ausgeführte Anwendungen dem offenen Internet ausgesetzt sind, wird Sicherheit notwendig. Glücklicherweise verfügt NGINX Plus über Sicherheitsfunktionen der Enterprise-Klasse, mit denen eine mehrschichtige, tiefgreifende Verteidigungsarchitektur erstellt werden kann.
Warum nutzen Sie NGINX Plus vor Ihren Clustern und führen die Funktion „split_clients“ aus? Und warum fügen Sie diese Präsenz nicht hinzu, indem Sie einige nützliche Sicherheitsfunktionen hinzufügen? Hier sind einige der NGINX Plus-Funktionen, die zur Verbesserung der Sicherheit verwendet werden könnten, mit Links und Verweisen auf andere Dokumentationen, die zum Konfigurieren, Testen und Bereitstellen verwendet werden können.
- IP-Sperr-/Zulassungslisten – Kontrolliert den Zugriff basierend auf der Quell-IP-Adresse. Eine Konfigurationsanleitung zur Verwendung des NGINX Plus-Schlüssel-Wert-Speichers für dynamische IP-Block-/Allow-Listen unter Verwendung der Plus-API finden Sie auf der Seite „Dynamische Denylists von IP-Adressen“ in den NGINX-Dokumenten.
- Ratenbegrenzung – Steuert die Anzahl der TCP-Verbindungen, HTTP-Anfragen und die Bandbreitennutzung für Anwendungen, API-Endpunkte und Mediendownloads. Weitere Informationen zur Ratenbegrenzung mit NGINX finden Sie unter „Begrenzung des Zugriffs auf proxied HTTP-Ressourcen“ in den NGINX-Dokumenten und in den Blog-Beiträgen „Ratenbegrenzung mit NGINX und NGINX Plus“ und „Dynamische Bandbreitenbegrenzungen mithilfe des Schlüssel-Wert-Speichers von NGINX Plus“ .
- Dynamisches GeoIP2-Modul – Sammelt Standortmetadaten basierend auf der Quell-IP-Adresse. Weitere Informationen hierzu finden Sie auf der Seite „Einschränken des Zugriffs nach geografischem Standort“ in den NGINX-Dokumenten.
- JWT- und OpenID Connect (OIDC)-Modul – Steuert den Benutzerzugriff mit Industriestandardprotokollen. Weitere Informationen hierzu finden Sie auf der Seite „Einrichten der JWT-Authentifizierung“ in den NGINX-Dokumenten.
- NGINX App Protect – Eine leichte Web Application Firewall mit geringer Latenz, die vor bestehenden und sich entwickelnden Bedrohungen schützt.
Legen Sie noch heute los
Wenn Sie über die Netzwerkprobleme am Rand Ihres Kubernetes-Clusters frustriert sind, sollten Sie diese NGINX-Multicluster-Lösung ausprobieren. Machen Sie eine Probefahrt mit der NGINX Loadbalancer-Software für Kubernetes und teilen Sie uns Ihre Meinung mit. Der Quellcode ist Open Source (unter der Apache 2.0-Lizenz) und alle Installationsanweisungen sind auf GitHub verfügbar .
Um Feedback zu geben, hinterlassen Sie uns einen Kommentar im Repo oder senden Sie uns eine Nachricht im NGINX Community Slack .
„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."