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 von NGINX Gateway Fabric automatisch aktiviert werden, wenn es mit NGINX Plus installiert wird, ermöglichen es NGINX Gateway Fabric, Aktualisierungen an NGINX-Konfigurationen vorzunehmen, ohne dass ein NGINX-Neuladen durchgeführt werden muss. Wenn ein NGINX-Neuladen erfolgt, werden die vorhandenen Verbindungen traditionell von den alten Arbeitsprozessen verwaltet, während die neu konfigurierten Arbeitsprozessen die neuen Verbindungen verwalten. Wenn alle alten Verbindungen hergestellt sind, werden die alten Worker gestoppt und NGINX wird nur mit den neu konfigurierten Workern fortgesetzt. Auf diese Weise werden Konfigurationsänderungen auch in NGINX Open Source reibungslos gehandhabt. Wenn NGINX jedoch stark ausgelastet ist, kann die Wartung sowohl alter als auch neuer Worker zu einem Ressourcen-Overhead führen, der Probleme verursachen kann, insbesondere wenn versucht wird, NGINX Gateway Fabric so schlank wie möglich auszuführen. Die dynamischen Upstream-Neuladungen in NGINX Plus umgehen dieses Problem, indem sie einen API-Endpunkt für Konfigurationsänderungen bereitstellen, den NGINX Gateway Fabric automatisch verwendet, sofern vorhanden. Dadurch wird der Bedarf an zusätzlichen Ressourcen zur Handhabung alter und neuer Worker während des Neuladevorgangs reduziert. Wenn Sie häufiger Änderungen an NGINX Gateway Fabric vornehmen, werden auch die Neuladevorgänge häufiger erfolgen. Wenn Sie wissen möchten, wie oft oder wann in Ihrer aktuellen NGF-Installation Neuladevorgänge erfolgen, können Sie sich die Prometheus-Metrik nginx_gateway_fabric_nginx_reloads_total ansehen. Um umfassend und eingehend auf das Problem einzugehen, lesen Sie hier den Artikel von Nick Shadrin! Hier ist ein Beispiel für die Metrik in einer Umgebung mit zwei Bereitstellungen von NGINX Gateway Fabric im Prometheus-Dashboard:

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

NGINX Plus Dashboard

Wenn Sie, wie bereits erwähnt, nach einer schnellen Möglichkeit suchen, NGINX Plus-Metriken ohne eine Prometheus-Installation oder einen Observability-Stack anzuzeigen, bietet Ihnen das NGINX Plus-Dashboard eine Echtzeitüberwachung der Leistungsmetriken, die Sie zur Fehlerbehebung bei Vorfällen und zur Überwachung der Ressourcenkapazität verwenden können. Das Dashboard bietet Ihnen verschiedene Ansichten für alle Metriken, die NGINX Plus sofort bereitstellt, und ist über einen internen Port leicht zugänglich. Wenn Sie sich selbst einen kurzen Eindruck von den Dashboard-Funktionen verschaffen möchten, sehen Sie sich unsere Dashboard-Demosite unter demo.nginx.com an. Um auf das NGINX Plus-Dashboard Ihrer NGINX Gateway Fabric-Installation zuzugreifen, können Sie Verbindungen per Portweiterleitung an Port 8765 auf Ihrem lokalen Computer weiterleiten: kubectl port-forward -n nginx-gateway 8765:8765. Öffnen Sie anschließend Ihren bevorzugten Browser und geben Sie http://localhost:8765/dashboard.html in die Adressleiste 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

Lassen Sie uns eine HTTPRoute-Ressource erstellen und Anforderungsfilter konfigurieren, um alle Anforderungen für /coffee in /beans umzuschreiben. Wir können auch einen /latte-Endpunkt bereitstellen, der so umgeschrieben wird, dass er das /latte-Präfix für die Verarbeitung durch das Backend enthält („/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.