Ankündigung der NGINX Gateway Fabric-Version 1.2.0

Wir freuen uns, die neuesten Nachrichten zu NGINX Gateway Fabric bekannt zu geben, unserer konformen Implementierung der Kubernetes Gateway API. Wir haben es kürzlich auf Version 1.2.0 aktualisiert und bieten mehrere spannende neue Funktionen und Verbesserungen. Der Schwerpunkt dieser Version liegt auf der Erweiterung der Funktionen der Plattform und der Sicherstellung, dass sie den Anforderungen unserer Benutzer entspricht. Wir haben F5 NGINX Plus-Unterstützung integriert und unsere API-Oberfläche erweitert, um die am häufigsten nachgefragten Anwendungsfälle abzudecken. Wir glauben, dass diese Verbesserungen allen unseren Benutzern ein besseres Erlebnis bieten und ihnen helfen werden, ihre Ziele effizienter zu erreichen.

Abbildung 1: Überblick über Design und Architektur von NGINX Gateway Fabric

NGINX Gateway Fabric 1.2.0 auf einen Blick:

• NGINX Plus-Unterstützung – NGINX Gateway Fabric unterstützt jetzt NGINX Plus für die Datenebene, was verbesserte Verfügbarkeit, detaillierte Metriken und Dashboards zur Echtzeit-Beobachtbarkeit bietet.
• BackendTLSPolicy – Durch die TLS-Verifizierung kann NGINX Gateway Fabric die Identität der Backend-Anwendung bestätigen und so vor einer möglichen Entführung der Verbindung durch bösartige Anwendungen schützen. Darüber hinaus verschlüsselt TLS den Datenverkehr innerhalb des Clusters und gewährleistet so eine sichere Kommunikation zwischen dem Client und der Backend-Anwendung.
• URLRewrite – NGINX Gateway Fabric unterstützt jetzt URL-Umschreibungen in Route-Objekten. Mit dieser Funktion können Sie die ursprüngliche Anforderungs-URL einfach ändern und an ein geeigneteres Ziel umleiten. Auf diese Weise können Sie die Konsistenz der APIs, die Sie Ihren Clients zur Verfügung stellen, wahren, während sich die APIs Ihrer Backend-Anwendungen ändern.
• Produkttelemetrie – Mit der jetzt in NGINX Gateway Fabric vorhandenen Produkttelemetrie können wir Ihnen dabei helfen, die Betriebseffizienz Ihrer Infrastruktur weiter zu verbessern, indem wir erfahren, wie Sie das Produkt in Ihrer Umgebung verwenden. Darüber hinaus planen wir, diese Erkenntnisse im Rahmen unserer Meetings regelmäßig mit der Community zu teilen.

Wir werden uns die neuen Funktionen unten genauer ansehen.

Was ist neu in NGINX Gateway Fabric 1.2.0?

NGINX Plus-Unterstützung

NGINX Gateway Fabric Version 1.2.0 wurde mit Unterstützung für NGINX Plus veröffentlicht und bietet Benutzern viele neue Vorteile. Mit dem neuen Upgrade können Benutzer jetzt die erweiterten Funktionen von NGINX Plus in ihren Bereitstellungen nutzen, darunter zusätzliche Prometheus-Metriken, dynamische Upstream-Neuladungen und das NGINX Plus-Dashboard. Dieses Upgrade bietet Ihnen auch die Möglichkeit, direkt von NGINX Support für Ihre Umgebung zu erhalten.

Zusätzliche Prometheus-Metriken

Wenn Sie NGINX Plus als Ihre Datenebene verwenden, werden neben den Metriken, die Sie normalerweise mit NGINX Open Source erhalten, zusätzliche erweiterte Metriken exportiert. Zu den Highlights zählen unter anderem Metriken zu HTTP-Anfragen, Streams, Verbindungen und vielem mehr. Die vollständige Liste finden Sie im Prometheus-Exporter von NGINX. Beachten Sie jedoch, dass der Exporter für NGINX Gateway Fabric nicht unbedingt erforderlich ist. Mit jeder Installation von Prometheus oder einem Prometheus-kompatiblen Scraper können Sie diese Metriken in Ihren Observability-Stack scrapen und Dashboards und Warnmeldungen mithilfe einer konsistenten Ebene innerhalb Ihrer Architektur erstellen. Prometheus-Metriken sind automatisch im NGINX Gateway Fabric über HTTP-Port 9113 verfügbar. Sie können den Standardport auch ändern, indem Sie die Pod-Vorlage aktualisieren. Wenn Sie nach einer einfachen Einrichtung suchen, können Sie unsere GitHub-Seite besuchen. Dort finden Sie weitere Informationen zum Bereitstellen und Konfigurieren von Prometheus, um mit dem Sammeln zu beginnen. Wenn Sie alternativ nur die Metriken anzeigen und die Einrichtung überspringen möchten, können Sie das NGINX Plus-Dashboard verwenden, das im nächsten Abschnitt erläutert wird. Nachdem Sie Prometheus in Ihrem Cluster installiert haben, können Sie auf das Dashboard zugreifen, indem Sie die Portweiterleitung im Hintergrund ausführen. kubectl -n monitoring port-forward svc/prometheus-server 9090:80

Abbildung 2: Prometheus-Diagramm, das akzeptierte NGINX Gateway Fabric-Verbindungen zeigt

Das obige Setup funktioniert auch, wenn Sie die standardmäßige Open Source NGINX als Datenebene verwenden! Sie werden jedoch keine der zusätzlichen Metriken sehen, die NGINX Plus bereitstellt. Wenn die Größe und der Umfang Ihres Clusters wachsen, empfehlen wir Ihnen, sich anzusehen, wie NGINX Plus-Metriken Ihnen dabei helfen können, Ihre Kapazitätsplanungsprobleme, Vorfälle und sogar Back-End-Anwendungsfehler schnell zu lösen.

Dynamisches Upstream-Neuladen

Dynamische Upstream-Neuladungen, die NGINX Gateway Fabric automatisch aktiviert, wenn Sie NGINX Plus installieren, ermöglichen es Ihnen, NGINX-Konfigurationen ohne Neustart von NGINX zu aktualisieren. Beim traditionellen NGINX-Neustart verwalten die alten Worker-Prozesse bestehende Verbindungen, während die neu konfigurierten Worker neue Verbindungen übernehmen. Sobald alle alten Verbindungen abgeschlossen sind, stoppen wir die alten Worker, und NGINX läuft nur mit den neu konfigurierten Workern weiter. So nehmen wir Konfigurationsänderungen auch in NGINX Open Source reibungslos vor. Unter hoher Last kann die gleichzeitige Verwaltung alter und neuer Worker jedoch Ressourcen belasten, was problematisch wird, wenn Sie NGINX Gateway Fabric möglichst schlank betreiben möchten. Die dynamischen Upstream-Neuladungen in NGINX Plus umgehen das Problem über einen API-Endpunkt für Konfigurationsänderungen, den NGINX Gateway Fabric automatisch nutzt, falls vorhanden. So reduzieren Sie den zusätzlichen Ressourcenaufwand, um alte und neue Worker während des Neuladens zu verwalten. Wenn Sie öfter Änderungen an NGINX Gateway Fabric vornehmen, finden diese Neuladungen entsprechend häufiger statt. Möchten Sie wissen, wie oft oder wann Neuladungen in Ihrer aktuellen NGF-Installation geschehen, schauen Sie sich die Prometheus-Metrik nginx_gateway_fabric_nginx_reloads_total an. Für eine ausführliche Analyse des Themas empfehlen wir den Artikel von Nick Shadrin hier! Hier sehen Sie ein Beispiel der Metrik in einer Umgebung mit zwei Deployments von NGINX Gateway Fabric im Prometheus-Dashboard:

Abbildung 3: Prometheus-Diagramm mit der Gesamtzahl der Neuladungen des NGINX Gateway Fabric

NGINX Plus Dashboard

Wie bereits erwähnt, erhalten Sie mit dem NGINX Plus-Dashboard eine schnelle Möglichkeit, NGINX Plus-Metriken ohne Prometheus oder eine Observability-Lösung in Echtzeit zu überwachen. So können Sie Vorfälle schnell beheben und die Kapazität Ihrer Serverressourcen im Blick behalten. Das Dashboard zeigt Ihnen alle von NGINX Plus verfügbaren Metriken in unterschiedlichen Ansichten, aufrufbar über einen internen Port. Wenn Sie die Funktionen des Dashboards direkt erleben möchten, besuchen Sie unsere Demo-Website unter demo.nginx.com. Um auf das NGINX Plus-Dashboard Ihrer NGINX Gateway Fabric-Installation zuzugreifen, leiten wir Verbindungen zum Port 8765 Ihres lokalen Rechners per Port-Forwarding weiter: kubectl port-forward -n nginx-gateway 8765:8765. Öffnen Sie anschließend Ihren Browser und geben http://localhost:8765/dashboard.html in die Adresszeile ein.

Abbildung 4: NGINX Plus Dashboard-Übersicht

BackendTLSPolicy

Diese Version enthält jetzt die lang erwartete Unterstützung für BackendTLSPolicy . Die BackendTLSPolicy führt eine verschlüsselte TLS-Kommunikation zwischen NGINX Gateway Fabric und der Anwendung ein und verbessert so die Sicherheit des Kommunikationskanals erheblich. Das folgende Beispiel zeigt, wie die Richtlinie durch Angabe von Einstellungen wie TLS-Chiffren und -Protokollen beim Validieren von Serverzertifikaten gegenüber einer vertrauenswürdigen Zertifizierungsstelle (CA) angewendet wird. Mit der BackendTLSPolicy können Benutzer ihren Datenverkehr zwischen NGF und ihren Backends sichern. Sie können auch die minimale TLS-Version und die Verschlüsselungssammlungen festlegen. Dies schützt vor bösartigen Anwendungen, die die Verbindung kapern, und verschlüsselt den Datenverkehr innerhalb des Clusters. Um die TLS-Terminierung im Back-End zu konfigurieren, erstellen Sie zunächst eine ConfigMap mit der CA-Zertifizierung, die Sie verwenden möchten. Hilfe zur Verwaltung interner Kubernetes-Zertifikate finden Sie in diesem Handbuch .

Art: ConfigMap
API-Version: v1
Metadaten:
Name: Backend-Zertifikat
Daten:
ca.crt: 
< -----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
>

Als Nächstes erstellen wir die BackendTLSPolicy, die auf unseren Secure-App- Dienst abzielt und auf die im vorherigen Schritt erstellte ConfigMap verweist:

API-Version: gateway.networking.k8s.io/v1alpha2
Art: BackendTLSPolicy
Metadaten:
Name: Backend-TLS
Spezifikation:
Zielreferenz:
Gruppe: ''
Art: Dienst
Name: Secure-App
Namespace: Standard
TLS:
caCertRefs:
-Name: Backend-Zertifikat
Gruppe: ''
Art: ConfigMap
Hostname: secure-app.example.com

URLRewrite

Mit einem URLRewrite-Filter können Sie die ursprüngliche URL einer eingehenden Anfrage ändern und sie ohne Leistungseinbußen auf eine andere URL umleiten. Dies ist insbesondere dann nützlich, wenn Ihre Backend-Anwendungen ihre freigegebene API ändern, Sie jedoch die Abwärtskompatibilität für Ihre vorhandenen Clients beibehalten möchten. Sie können diese Funktion auch verwenden, um Ihren Clients eine konsistente API-URL bereitzustellen und gleichzeitig die Anforderungen an verschiedene Anwendungen mit unterschiedlichen API-URLs umzuleiten. So können Sie eine „Erlebnis-API“ bereitstellen, die die Funktionen mehrerer verschiedener APIs kombiniert, um den Komfort und die Leistung Ihrer Clients zu steigern. Lassen Sie uns zunächst ein Gateway für die NGINX-Gateway-Struktur erstellen. Dadurch können wir HTTP-Listener definieren und Port 80 für optimale Leistung konfigurieren.

API-Version: gateway.networking.k8s.io/v1
Art: Gateway
Metadaten:
Name: Café
Spezifikation:
Gateway-Klassenname: nginx
Listener:
- Name: http
Port: 80
Protokoll: HTTP

Erstellen wir eine HTTPRoute-Ressource und richten Anforderungsfilter ein, die alle Anfragen von /coffee auf /beans umschreiben. Außerdem richten wir einen /latte-Endpunkt ein, der das /latte-Präfix im Backend berücksichtigt (" /latte/126" wird zu "/126").

API-Version: gateway.networking.k8s.io/v1
Art: HTTPRoute
Metadaten:
Name: Kaffee
Spezifikation:
ParentRefs:
- Name: Café
Abschnittsname: http
Hostnamen:
- „cafe.example.com“
Regeln:
- Übereinstimmungen:
- Pfad:
Typ: PathPrefix
Wert: /Kaffee
Filter:
-Typ: URLRewrite
urlRewrite:
Pfad:
Typ: ReplaceFullPath
replaceFullPath: /beans
backendRefs:
- Name: Kaffee
Port: 80
- Übereinstimmungen:
- Pfad:
Typ: PathPrefix
Wert: /latte
Filter:
-Typ: URLRewrite
urlRewrite:
Pfad:
Typ: ReplacePrefixMatch
replacePrefixMatch: /
backendRefs:
- Name: Kaffee
Port: 80

Die HTTP-Rewrite-Funktion trägt dazu bei, Flexibilität zwischen den Endpunkten auf der Clientseite und ihrer Zuordnung zum Backend sicherzustellen. Darüber hinaus ermöglicht es die Umleitung des Datenverkehrs von einer URL zu einer anderen, was insbesondere bei der Migration von Inhalten auf eine neue Website oder bei API-Datenverkehr hilfreich ist. Obwohl NGINX Gateway Fabric pfadbasiertes Umschreiben unterstützt, unterstützt es derzeit keine pfadbasierten Umleitungen. Lassen Sie uns wissen, ob Sie diese Funktion für Ihre Umgebung benötigen.

Produkttelemetrie

Wir haben entschieden, Produkttelemetrie als Mechanismus zur passiven Erfassung von Feedback als Teil der Version 1.2 einzubinden. Diese Funktion sammelt verschiedene Messdaten aus Ihrer Umgebung und sendet sie alle 24 Stunden an unsere Datenerfassungsplattform. Es werden keine personenbezogenen Daten erfasst. Eine vollständige Liste der erfassten Daten finden Sie hier . Wir legen Wert darauf, vollständige Transparenz hinsichtlich unserer Telemetriefunktionen zu gewährleisten. Obwohl wir jedes erfasste Feld dokumentieren und Sie anhand unseres Codes überprüfen können, was wir erfassen, haben Sie jederzeit die Möglichkeit, ihn vollständig zu deaktivieren. Wir planen, interessante Beobachtungen auf Grundlage der von uns mit der Community gesammelten Statistiken regelmäßig in unseren Community-Meetings zu besprechen, also schauen Sie unbedingt vorbei!

Ressourcen

Das vollständige Änderungsprotokoll für NGINX Gateway Fabric 1.2.0 finden Sie in den Versionshinweisen . Um NGINX Gateway Fabric für Kubernetes mit NGINX Plus auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen . Wenn Sie mitmachen und sehen möchten, was als Nächstes kommt, oder den Quellcode für NGINX Gateway Fabric ansehen möchten, sehen Sie sich unser Repository auf GitHub an! Wir haben zweiwöchentliche Community-Meetings montags um 9:00 Uhr Pazifikzeit/17:00 Uhr GMT. Den Besprechungslink, Aktualisierungen, die Tagesordnung und Notizen finden Sie im Besprechungskalender von NGINX Gateway Fabric . Links sind auch immer in unserer GitHub-Readme-Datei verfügbar.