NGINX Service Mesh verfügbar

NGINX Service Mesh verfügbar

Wir freuen uns, die Vorabversion vorzustellen NGINX Service Mesh (NSM), ein leichtgewichtiges Service Mesh, das einen auf NGINX Plus basierenden Datenpfad zur Verwaltung des Containertraffics in Kubernetes-Umgebungen verwendet.

NSM kann kostenlos hier heruntergeladen werden. Wir hoffen, dass Sie es für Entwicklungs- und Testumgebungen ausprobieren und freuen uns auf Ihr Feedback auf GitHub.

Die Implementierung von Microservices-Methoden bringt Herausforderungen mit sich, insbesondere beim Wachstum und der Komplexität der Bereitstellung. Die Kommunikation zwischen den Services wird komplexer, Debugging-Probleme werden schwieriger, und zunehmend mehr Services erfordern mehr Ressourcen für das Management.

NSM löst diese Probleme, indem es Ihnen vor allem Folgendes bietet:

  • Sicherheit, was jetzt wichtiger ist denn je. Datenlecks können ein Unternehmen jährlich Millionen Dollar an Einnahmen und Ruf kosten. NSM sorgt für die Verschlüsselung aller Verbindungen mit mTLS – sodass es keine sensiblen Daten gibt, die von Hackern im Netzwerk gestohlen werden könnten. Die Zugriffskontrolle ermöglicht es Ihnen, Richtlinien festzulegen, wie Services miteinander kommunizieren werden.
  • Traffic-Management. Bei der Bereitstellung einer neuen Version der Anwendung möchten Sie möglicherweise zunächst den eingehenden Datenverkehr im Falle eines Fehlers begrenzen. Mit dem intelligenten Traffic Management für Container von NSM können Sie eine Traffic-Grenzpolitik für neue Dienste festlegen, die den Verkehr im Laufe der Zeit erhöht. Weitere Funktionen wie Geschwindigkeitsbegrenzungen und Circuit Breakers geben Ihnen vollständigen Zugriff auf die Steuerung des Datenverkehrs für all Ihre Dienste.
  • Visualisierung. Die Verwaltung von Tausenden von Diensten kann ein Alptraum in Bezug auf Debugging und Visualisierung sein. NSM hilft Ihnen dabei, indem es ein integriertes Grafana-Dashboard bereitstellt, das alle in NGINX Plus verfügbaren Metriken anzeigt. Außerdem ermöglicht das integrierte OpenTracing eine detaillierte Verfolgung der Transaktionen.
  • Hybride Bereitstellungen, falls Ihr Unternehmen, wie die meisten anderen, keine vollständig auf Kubernetes ausgeführte Infrastruktur nutzt. NSM stellt sicher, dass ältere Anwendungen nicht unbeaufsichtigt bleiben. Mit dem integrierten NGINX Kubernetes Ingress Controller können ältere Dienste mit Mesh-Diensten kommunizieren und umgekehrt.

NSM bietet auch Sicherheit für Anwendungen in Zero-Trust-Umgebungen, indem es die Verschlüsselung und Authentifizierung von Containerverkehr transparent anwendet. Es ermöglicht zudem die Überwachung und Analyse von Transaktionen, wodurch die Bereitstellung und Problemlösung schnell und präzise erfolgen kann. Darüber hinaus wird ein detaillierter Traffic-Kontrolle bereitgestellt, die es DevOps-Teams ermöglicht, Teile von Anwendungen bereitzustellen und zu optimieren, während Entwickler ihre verteilten Anwendungen schaffen und einfach miteinander verbinden können.

Wie funktioniert das NGINX Service Mesh?

NSM besteht aus einem integrierten Datenpfad für horizontalen (Service-zu-Service) Verkehr und einem eingebetteten NGINX Plus Ingress Controller für vertikalen Verkehr, die von einem einheitlichen Kontrollbereich verwaltet werden.

Der Kontrollbereich wurde speziell für den NGINX Plus Datenpfad entwickelt und optimiert und definiert die Verkehrsmanagementregeln, die über die NGINX Plus Sidecars verteilt sind.

In NSM werden Proxys für jedes Service im Mesh als Sidecars installiert. Sie interagieren mit den folgenden Open-Source-Lösungen:

  • Grafana, eine Visualisierungslösung für Prometheus, und das integrierte NSM-Dashboard unterstützen Sie bei der Arbeit;
  • Kubernetes Ingress Controller zur Verwaltung des eingehenden und ausgehenden Datenverkehrs im Mesh;
  • SPIRE, CA zur Verwaltung, Verteilung und Aktualisierung von Zertifikaten im Mesh;
  • NATS, ein skalierbares Nachrichtensystem, zum Beispiel zur Aktualisierung von Routen vom Control Plane zu den Sidecars;
  • OpenTracing, verteilte Fehlersuche (Zipkin und Jaeger werden unterstützt);
  • Prometheus, zur Sammlung und Speicherung von Metriken von NGINX Plus Sidecars, wie z. B. die Anzahl der Anfragen, Verbindungen und SSL-Handshakes.

Funktionen und Komponenten

NGINX Plus agiert als Data Plane und umfasst Sidecar-Proxy (horizontaler Datenverkehr) und Ingress Controller (vertikal), indem es den Datenverkehr zwischen Containern und Services abfängt und steuert.

Die Funktionen umfassen:

  • Mutual TLS-Authentifizierung (mTLS);
  • Lastverteilung;
  • Fehlertoleranz;
  • Geschwindigkeitsbegrenzung;
  • Circuit Breaking;
  • Blue-Green- und Canary-Deployments;
  • Zugangskontrolle.

Start von NGINX Service Mesh

Um NSM zu starten, benötigen Sie:

  • Zugriff auf die Kubernetes-Umgebung. NGINX Service Mesh wird auf vielen Kubernetes-Plattformen unterstützt, einschließlich Amazon Elastic Container Service for Kubernetes (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), VMware vSphere und herkömmlichen Kubernetes-Clustern, die auf "Bare-Metal"-Servern bereitgestellt werden;
  • Ein Tool kubectl, das auf dem Rechner installiert ist, von dem aus NSM eingerichtet wird;
  • Zugriff auf die Pakete von NGINX Service Mesh. Das Paket enthält NSM-Images, die zum Hochladen in ein privates Registry für Container, das im Kubernetes-Cluster verfügbar ist, erforderlich sind. Das Paket enthält außerdem nginx-meshctl, das für die Bereitstellung von NSM erforderlich ist.

Um NSM mit den Standardkonfigurationen bereitzustellen, führen Sie den folgenden Befehl aus. Während der Bereitstellung werden Nachrichten über die erfolgreiche Installation der Komponenten angezeigt und schließlich eine Nachricht, dass NSM in einem eigenen Namensraum läuft (zuerst muss es heruntergeladen und im Registry platziert werden, Anm. der Übersetzer):

$ DOCKER_REGISTRY=Ihr-Docker-registry ; MESH_VER=0.6.0 ; 
 ./nginx-meshctl deploy  
  --nginx-mesh-api-image "${DOCKER_REGISTRY}/nginx-mesh-api:${MESH_VER}" 
  --nginx-mesh-sidecar-image "${DOCKER_REGISTRY}/nginx-mesh-sidecar:${MESH_VER}" 
  --nginx-mesh-init-image "${DOCKER_REGISTRY}/nginx-mesh-init:${MESH_VER}" 
  --nginx-mesh-metrics-image "${DOCKER_REGISTRY}/nginx-mesh-metrics:${MESH_VER}"
Namensraum "nginx-mesh" erstellt.
SpiffeID CRD erstellt.
Warte auf die Ausführung der Spire-Pods...fertig.
Spire bereitgestellt.
NATS-Server bereitgestellt.
Traffic-Policy-CRDs erstellt.
Mesh API bereitgestellt.
Metrics API-Server bereitgestellt.
Prometheus-Server nginx-mesh/prometheus-server bereitgestellt.
Grafana nginx-mesh/grafana bereitgestellt.
Tracing-Server nginx-mesh/zipkin bereitgestellt.
Alle Ressourcen erstellt. Teste die Verbindung zum Service Mesh API-Server...

Erfolgreich mit der NGINX Service Mesh API verbunden.
NGINX Service Mesh läuft.

Um zusätzliche Optionen, einschließlich erweiterter Einstellungen, zu erhalten, führen Sie diesen Befehl aus:

$ nginx-meshctl deploy –h

Überprüfen Sie, ob die Control-Plane im Namespace nginx-mesh, so geht's:

$ kubectl get pods –n nginx-mesh
NAME                                 READY   STATUS    RESTARTS   AGE
grafana-6cc6958cd9-dccj6             1/1     Running   0          2d19h
mesh-api-6b95576c46-8npkb            1/1     Running   0          2d19h
nats-server-6d5c57f894-225qn         1/1     Running   0          2d19h
prometheus-server-65c95b788b-zkt95   1/1     Running   0          2d19h
smi-metrics-5986dfb8d5-q6gfj         1/1     Running   0          2d19h
spire-agent-5cf87                    1/1     Running   0          2d19h
spire-agent-rr2tt                    1/1     Running   0          2d19h
spire-agent-vwjbv                    1/1     Running   0          2d19h
spire-server-0                       2/2     Running   0          2d19h
zipkin-6f7cbf5467-ns6wc              1/1     Running   0          2d19h

Je nach den Bereitstellungsparametern, die manuelle oder automatische Injection-Richtlinien festlegen, werden NGINX Sidecar-Proxys standardmäßig zu den Anwendungen hinzugefügt. Um die automatische Hinzufügung zu deaktivieren, lesen Sie hier

Wenn wir beispielsweise die Anwendung sleep im Namespace default, und dann den Pod überprüfen, sehen wir zwei laufende Container: die Anwendung sleep und den zugehörigen Sidecar:

$ kubectl apply –f sleep.yaml
$ kubectl get pods –n default
NAME                     READY   STATUS    RESTARTS   AGE
sleep-674f75ff4d-gxjf2   2/2     Running   0          5h23m

Wir können auch die Anwendung überwachen. sleep Im NGINX Plus-Panel führen Sie diesen Befehl aus, um auf das Sidecar von Ihrem lokalen Rechner aus zuzugreifen:

$ kubectl port-forward sleep-674f75ff4d-gxjf2 8080:8886

Gehen Sie dann einfach hierhin im Browser. Sie können sich auch mit Prometheus verbinden, um die Anwendung zu überwachen. sleep.

Sie können separate Kubernetes-Ressourcen verwenden, um Traffic-Richtlinien wie Zugriffskontrolle, Bandbreitenbegrenzung und Circuit Breaking zu konfigurieren. Weitere Informationen finden Sie in Dokumentation

Fazit

dem F5-Portal. Probieren Sie es in Ihren Entwicklungs- und Testumgebungen aus undteilen Sie uns Ihre Ergebnisse mit. Um den NGINX Plus Ingress Controller auszuprobieren, aktivieren Sie.

eine kostenlose Testphase von 30 Tagen oder kontaktieren Sie uns um Ihre Anwendungsfälle zu besprechen. Übersetzung im Auftrag von Pawel Demkovich, Ingenieur bei

. Systemadministration für 15.000 ₽ pro Monat. Und als eigenständige Einheit — ein Schulungszentrum, SouthbridgePraxis und nichts als Praxis. Slurm, практика и ничего, кроме практики.

Quelle: habr.com

Zuverlässiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server kaufen 🔥 Zuverlässiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server kaufen | ProHoster