So vereinfachen Sie die Verwaltung des eingehenden und ausgehenden Datenverkehrs von Kubernetes

Ein Service Mesh kann die Verwaltung einer Kubernetes -Umgebung unter anderem dann erschweren, wenn es separat vom Ingress-Controller konfiguriert werden muss. Außerdem sind separate Konfigurationen nicht nur zeitaufwändig. Sie erhöhen die Wahrscheinlichkeit von Konfigurationsfehlern, die eine ordnungsgemäße Datenverkehrsweiterleitung verhindern und sogar zu Sicherheitslücken (z. B. wenn böswillige Akteure Zugriff auf eingeschränkte Apps erhalten) und schlechten Erfahrungen (z. B. wenn Kunden nicht auf Apps zugreifen können, für die sie autorisiert sind) führen können. Abgesehen vom Zeitaufwand für die Durchführung separater Konfigurationen verbringen Sie letztendlich mehr Zeit mit der Fehlerbehebung.

Sie können diese Probleme vermeiden – und Zeit sparen –, indem Sie den auf NGINX Plus basierenden NGINX Ingress Controller mit NGINX Service Mesh integrieren, um sowohl eingehenden als auch ausgehenden mTLS-Verkehr zu steuern. In dieser Video-Demo behandeln wir alle Schritte.

In den folgenden Abschnitten wird auf unterstützende Dokumentation verwiesen:

• Voraussetzungen
• Bereitstellen des NGINX Ingress Controllers mit NGINX Service Mesh
• Verwenden einer standardmäßigen Kubernetes-Ingress-Ressource zum Freigeben der App
• Verwenden einer NGINX VirtualServer-Ressource zum Bereitstellen der App
• Konfigurieren einer sicheren Ausgangsroute mit dem NGINX Ingress Controller

Voraussetzungen (0:18)

Bevor wir mit der eigentlichen Demo begannen, haben wir diese Voraussetzungen erfüllt:

1. Die NGINX Server Mesh-Steuerungsebene im Kubernetes-Cluster installiert und mTLS und die strenge Richtlinie für das Service Mesh eingerichtet .

2. NGINX Ingress Controller auf NGINX Plus-Basis als Bereitstellung (anstelle eines DaemonSets) im Kubernetes-Cluster installiert, Egress aktiviert und als Dienst vom Typ LoadBalancer verfügbar gemacht .

   Notiz: Die Demo funktioniert nicht mit dem auf Open Source basierenden NGINX Ingress Controller. Der einfacheren Lesbarkeit halber bezeichnen wir den auf NGINX Plus basierenden NGINX Ingress Controller im weiteren Verlauf dieses Blogs einfach als „NGINX Ingress Controller“.

3. Befolgen Sie unsere Anweisungen , um die Beispiel-App „Bookinfo“ herunterzuladen, den NGINX Service Mesh-Sidecar einzufügen und die App bereitzustellen.

Aufgrund der strengen Richtlinie, die in Schritt 1 erstellt wurde, werden Anfragen an die Bookinfo- App von Clients außerhalb des Mesh im Sidecar abgelehnt. Wir veranschaulichen dies in der Demo, indem wir zunächst den folgenden Befehl ausführen, um die Portweiterleitung einzurichten:

> kubectl port-forward svc/product-page 9080 Weiterleitung von 127.0.0.1:9080 -> 9080 Weiterleitung von [::1]:9080 -> 9080 Verbindungshandhabung für 9080

Wenn wir versuchen, auf die App zuzugreifen, erhalten wir den Statuscode503 weil unsere lokale Maschine nicht Teil des Service Mesh ist:

> curl localhost:9080503

Bereitstellen des NGINX Ingress Controllers mit NGINX Service Mesh (1:50)

Der erste Schritt beim Bereitstellen einer App besteht darin, eine NGINX Ingress Controller-Instanz bereitzustellen. Entsprechende Anweisungen finden Sie in unserem Tutorial „Bereitstellen mit NGINX Plus Ingress Controller für Kubernetes“ .

NGINX stellt zu diesem Zweck sowohl Bereitstellungs- als auch DaemonSet-Manifeste bereit. In der Demo verwenden wir das Bereitstellungsmanifest nginx-plus-ingress.yaml . Es enthält Anmerkungen, um sowohl eingehenden als auch ausgehenden Datenverkehr über dieselbe NGINX Ingress Controller-Instanz zu leiten:

Das Manifest ermöglicht die direkte Integration des NGINX Ingress Controllers mit Spire, der Zertifizierungsstelle (CA) für NGINX Service Mesh, wodurch die Notwendigkeit entfällt, den NGINX Service Mesh-Sidecar in den NGINX Ingress Controller einzufügen. Stattdessen ruft der NGINX Ingress Controller Zertifikate und Schlüssel direkt von der Spire CA ab, um sie für mTLS mit den Pods im Mesh zu verwenden. Das Manifest gibt die Spire-Agentenadresse an:

und hängt den Spire-Agent-UNIX-Socket in den NGINX Ingress Controller-Pod ein:

Das letzte, was zum Manifest zu beachten ist, ist das CLI-Argument -enable-internal-routes , das uns das Routing zu Ausgangsdiensten ermöglicht:

Vor Beginn der Demo haben wir den Befehl „kubectl apply -f nginx-plus-ingress.yaml“ ausgeführt, um den NGINX Ingress Controller zu installieren , und an diesem Punkt überprüfen wir die Bereitstellung im nginx-ingress -Namespace. Wie in der Spalte „READY“ der folgenden Ausgabe gezeigt, gibt es nur einen Container für den NGINX Ingress Controller-Pod, da wir ihm keinen NGINX Service Mesh-Sidecar hinzugefügt haben.

Wir haben außerdem einen Dienst vom Typ LoadBalancer bereitgestellt, um die externe IP-Adresse des NGINX Ingress Controllers (hier 35.233.133.188) außerhalb des Clusters verfügbar zu machen. Wir greifen unter dieser IP-Adresse auf die Beispielanwendung „Bookinfo“ zu.

> kubectl get pods --namespace=nginx-ingress NAME BEREIT STATUS NEUSTART ALTER pod/nginx-ingress-867f954b8f0fzdrm 1/1 Wird ausgeführt 0 3d3h NAME TYP CLUSTER-IP EXTERNE-IP ... service-nginx-ingress LoadBalancer 10.31.245.207 35.233.133.188 ... ... ALTER DES HAFENS ... 80:31469/TCP,443:32481/TCP 4d2h ...

Verwenden einer standardmäßigen Kubernetes-Ingress-Ressource zum Freigeben der App (3:55)

Jetzt stellen wir die Bookinfo- App im Mesh bereit, indem wir eine Standard-Kubernetes-Ingress-Ressource verwenden, wie in bookinfo-ingress.yaml definiert. Entsprechende Anweisungen finden Sie in unserem Tutorial „Eine Anwendung mit dem NGINX Plus Ingress Controller verfügbar machen“ .

Die Ressource verweist in Zeile 10 auf ein Kubernetes-Geheimnis für die Bookinfo- App und enthält eine Routing-Regel, die angibt, dass Anforderungen für bookinfo.example.com an den Productpage -Dienst gesendet werden ( Zeilen 11–18 ). Das Geheimnis ist in bookinfo-secret.yaml definiert:

Wir führen diesen Befehl aus, um den Schlüssel und das Zertifikat zu laden, das in der Demo selbstsigniert ist:

> kubectl apply -f bookinfo-secret.yaml secret/bookinfo-secret unverändert

Wir aktivieren die Ingress-Ressource:

> kubectl apply -f bookinfo-ingress.yaml ingress.networking.k8s.io/bookinfo-ingress gelöscht

und überprüfen Sie, ob der Ingress Controller die in der Ressource definierte Route hinzugefügt hat, wie durch das Ereignis am Ende der Ausgabe bestätigt:

> kubectl beschreibt Ingress Bookinfo-Ingress …
Veranstaltungen:
  Typ Grund Alter Von Nachricht ---- ------ ---- ---- ------- Normal HinzugefügtOderAktualisiert 5s nginx-ingress-controller Konfiguration für ... ...default/bookinfo-ingress wurde hinzugefügt oder aktualisiert

In der Demo greifen wir nun über einen Browser auf die Bookinfo- App unter https://bookinfo.example.com/ zu. (Wir haben zuvor in der lokalen Datei /etc/hosts eine Zuordnung zwischen der IP-Adresse des Ingress Controller-Dienstes – 35.233.133.188 in der Demo, wie oben erwähnt – und bookinfo.example.com hinzugefügt. Anweisungen finden Sie in der Dokumentation .) Die Informationen im Abschnitt „Buchrezensionen“ der Seite ändern sich regelmäßig, da die Anfragen zwischen den drei Versionen des in bookinfo.yaml ( Download ) definierten Rezensionsdienstes wechseln.

Als nächstes untersuchen wir den eingehenden Datenverkehr in den Clustern. Wir führen das Skript generate-traffic.sh aus, um über die öffentliche IP-Adresse des NGINX Ingress Controllers Anfragen an den Productpage -Dienst zu stellen, und führen dann den Befehl nginx-meshctl top aus, um den Datenverkehr zu überwachen:

> nginxmesh-ctl top deploy/productpage-v1 Bereitstellungsrichtung Ressource Erfolgsrate P99 P90 P50 ... productpage-v1 Zu details-v1 100,00 % 3 ms 3 ms 2 ms Zu reviews-v2 100,00 % 99 ms 90 ms 20 ms Zu reviews-v3 100,00 % 99 ms 85 ms 18 ms Zu reviews-v1 100,00 % 20 ms 17 ms 9 ms Von nginx-ingress 100,00 % 192 ms 120 ms 38 ms ... Anzahl Anfragen ... 14 ... 5 ... 5 ... 12

Verwenden einer NGINX VirtualServer-Ressource zum Bereitstellen der App (6:45)

Als Nächstes zeigen wir eine alternative Möglichkeit zum Bereitstellen einer App unter Verwendung einer NGINX VirtualServer-Ressource . Es handelt sich um eine benutzerdefinierte NGINX Ingress Controller-Ressource, die eine komplexere Verkehrsabwicklung unterstützt, wie etwa Verkehrsaufteilung und inhaltsbasiertes Routing.

Zuerst löschen wir die Standard-Ingress-Ressource:

> kubectl delete -f bookinfo-ingress.yaml ingress.networking.k8s.io "bookinfo-ingress" gelöscht

Unsere Datei bookinfo-vs.yaml konfiguriert mTLS mit demselben Geheimnis wie in bookinfo-ingress.yaml ( Zeilen 7–8 ). Die Zeilen 9–12 definieren den Productpage- Dienst als Upstream und die Zeilen 13–24 eine Route, die alle bei bookinfo.example.com gestellten GET -Anfragen an diesen Upstream sendet. Für andere HTTP-Methoden als GET wird der Statuscode zurückgegeben405 .

Wir wenden die Ressource an:

> kubectl apply -f bookinfo-vs.yaml virtualserver.kubernetes.nginx.org/bookinfo-vs erstellt

Anschließend führen wir dieselben Schritte aus wie bei der Ingress-Ressource: Wir führen den Befehl „kubectl describe“ aus, um die korrekte Bereitstellung zu bestätigen, und greifen in einem Browser auf die App zu. Eine weitere Bestätigung dafür, dass die App ordnungsgemäß funktioniert, ist die Ablehnung der POST- Methode:

> curl -k -X POST https://bookinfo.example.com/ Methode nicht zulässig

Konfigurieren einer sicheren Ausgangsroute mit NGINX Ingress Controller (8:44)

Jetzt zeigen wir, wie ausgehender Datenverkehr über den NGINX Ingress Controller geleitet wird. Unser Tutorial „Konfigurieren einer sicheren Ausgangsroute mit NGINX Plus Ingress Controller“ behandelt den Vorgang anhand verschiedener Beispiel-Apps.

Wir haben bereits ein einfaches Bash- Pod in bash.yaml definiert und es im Standardnamespace bereitgestellt, aus dem wir Anfragen senden. Wie in der Spalte „READY“ dieser Ausgabe gezeigt, wurde der NGINX Service Mesh-Sidecar eingefügt.

> kubectl bekommt allesNAME BEREIT STATUS NEUSTART ALTER
pod/bash-6ccb678958-zsgm7 2/2 Läuft 0 77s

NAME TYP CLUSTER-IP EXTERNE-IP PORT(S) ALTER
service/kubernetes ClusterIP 10.31.240.1 <keine> 443/TCP 4d2h
...

Es gibt mehrere Anwendungsfälle, in denen Sie möglicherweise Anfragen innerhalb des Pods an einen Ausgangsdienst aktivieren möchten, d. h. an jede Entität, die nicht Teil des NGINX Service Mesh ist. Beispiele für eingesetzte Dienste:

• Außerhalb des Clusters
• Auf einem anderen Cluster
• Im selben Cluster, aber nicht mit dem NGINX Service Mesh Sidecar injiziert

In der Demo betrachten wir den finalen Anwendungsfall. Wir haben eine Anwendung im Legacy -Namespace bereitgestellt, die nicht von NGINX Service Mesh gesteuert wird und bei der die automatische Injektion des NGINX Service Mesh-Sidecars deaktiviert ist. Für die App wird nur ein Pod ausgeführt.

> kubectl get all --namespaces=legacyNAME BEREIT STATUS NEUSTART ALTER
pod/target-5f7bcb96c6-km9lz 1/1 Läuft 0 27m

NAME TYP CLUSTER-IP EXTERNE-IP PORT(S) ALTER
service/target-svc ClusterIP 10.31.245.213 <keine> 80/TCP,443/TCP 27m
...

Denken Sie daran, dass wir eine strikte mTLS-Richtlinie für NGINX Service Mesh konfiguriert haben. Daher können wir keine Anfragen direkt vom Bash- Pod an den Zieldienst senden, da sich die beiden nicht gegenseitig authentifizieren können. Wenn wir es versuchen, erhalten wir den Statuscode503 wie hier dargestellt:

> kubectl exec -it bash-6ccb678958-zsgm7 -c bash -- curl target-svc.legacy curl: (56) Empfangsfehler: Verbindung wurde durch Peer-Befehl 503 zurückgesetzt und mit Exitcode 56 beendet.

Die Lösung besteht darin, dem Bash- Pod zu ermöglichen, ausgehenden Datenverkehr über den NGINX Ingress Controller zu senden. Wir entfernen die Kommentarzeichen aus der Annotation in den Zeilen 14–15 von bash.yaml :

Dann wenden wir die neue Konfiguration an:

> kubectl apply -f bash.yaml deployment.apps/bash konfiguriert

und überprüfen Sie, ob ein neuer Bash- Pod gestartet ist:

> kubectl get pods NAME BEREIT STATUS NEUSTART ALTER bash-678c8b4579-7sfml 2/2 Wird ausgeführt 0 6s bash-6ccb678958-zsgm7 2/2 Wird beendet 0 3m28s

Wenn wir nun denselben kubectl exec -Befehl wie zuvor ausführen, um eine Anfrage vom Bash- Pod an den Zieldienst zu senden, erhalten wir den Statuscode404 anstatt503 . Dies zeigt an, dass der Bash- Pod die Anforderung erfolgreich an den NGINX Ingress Controller gesendet hat, dieser jedoch nicht weiß, wohin er sie weiterleiten soll, da keine Route definiert ist.

Wir erstellen die erforderliche Route mit der folgenden Ingress-Ressourcendefinition in legacy-route.yaml . Die interne Routenannotation in Zeile 7 bedeutet, dass der Zieldienst nicht dem Internet, sondern nur den Workloads innerhalb des NGINX Service Mesh ausgesetzt ist.

Wir aktivieren die neue Ressource und bestätigen, dass NGINX Ingress Controller die in der Ressource definierte Route hinzugefügt hat:

> kubectl apply -f legacy-route.yaml ingress.networking.k8s.io/target-internal-route erstellt > kubectl describe ingress target-internal-route -n legacy …
Veranstaltungen:
  Typ Grund Alter Von Nachricht ---- ------ ---- ---- ------- Normal HinzugefügtOderAktualisiert 6s nginx-ingress-controller Konfiguration für ... ...legacy/target-internal-route wurde hinzugefügt oder aktualisiert

Wenn wir jetzt den Befehl kubectl exec ausführen, erreichen wir den Zieldienst:

{"Anforderung": {"Methode": "GET" "url": "/",
"Host": "target-svc.legacy",
"remoteAddr": "10.28.2.76:56086"}}

Ein Vorteil der Weiterleitung des ausgehenden Datenverkehrs über den NGINX Ingress Controller besteht darin, dass Sie genau steuern können, welche externen Dienste innerhalb des Clusters erreicht werden können – nur diejenigen, für die Sie eine Route definieren.

Eine letzte Sache, die wir in der Demo zeigen, ist, wie ausgehender Datenverkehr überwacht wird. Wir führen den Befehl kubectl exec aus, um mehrere Anfragen zu senden, und führen dann diesen Befehl aus:

> nginxmesh-ctl top deploy/nginx-ingress -n nginx-ingress Bereitstellungsrichtung Ressource Erfolgsrate P99 P90 P50 NumRequests nginx-ingress Zum Ziel 100,00 % 1 ms 1 ms 1 ms 9 Von Bash 100,00 % 0 ms 0 ms 0 ms 9

Sagen Sie „Nein“ zur Latenz – testen Sie NGINX Service Mesh mit NGINX Ingress Controller

Viele Service-Meshes bieten Ingress- und Egress-Gateway-Optionen, aber wir glauben, dass Sie einen zusätzlichen Vorteil der NGINX-Integration zu schätzen wissen werden: geringere Latenz. Für die meisten Meshes ist das Einfügen eines Sidecars in den Ingress-Controller erforderlich, wodurch der Datenverkehr auf dem Weg zu Ihren Apps einen zusätzlichen Hop zurücklegen muss. Jede Sekunde zählt, und dieser zusätzliche Schritt, der Ihr digitales Erlebnis verlangsamt, kann dazu führen, dass sich die Kunden woanders umsehen. NGINX Service Mesh verursacht keine unnötige Latenz, da es keinen Sidecar in den NGINX Ingress Controller einfügt. Stattdessen wird NGINX Ingress Controller durch die direkte Integration mit Spire, der CA des Mesh, Teil von NGINX Service Mesh. NGINX Ingress Controller ruft einfach Zertifikate und Schlüssel vom Spire-Agenten ab und verwendet sie, um am mTLS-Zertifikatsaustausch mit Mesh-Pods teilzunehmen.

Es gibt zwei Versionen des NGINX Ingress Controller für Kubernetes: NGINX Open Source und NGINX Plus. Um NGINX Ingress Controller mit NGINX Service Mesh wie in diesem Blog beschrieben bereitzustellen, müssen Sie die NGINX Plus-Version verwenden, die für eine kostenlose 30-Tage-Testversion verfügbar ist.

NGINX Service Mesh ist völlig kostenlos und zum sofortigen Download verfügbar und kann in weniger als 10 Minuten bereitgestellt werden! Sehen Sie sich zunächst die Dokumentation an und teilen Sie uns über GitHub mit, wie es läuft.