Ankündigung von NGINX Gateway Fabric Version 1.2.0

Akash AnanthanarayananManager für technisches Marketing | F5 NGINX

Mike StefaniakSenior-Produktmanager | F5 NGINX

Wir freuen uns, Ihnen die neuesten Nachrichten zu NGINX Gateway Fabric mitteilen zu können, unserer konformen Implementierung der Kubernetes Gateway API. Vor Kurzem haben wir sie auf Version 1.2.0 aktualisiert und dabei mehrere spannende neue Funktionen und Verbesserungen eingeführt. Der Schwerpunkt dieser Version liegt darauf, die Funktionen der Plattform zu erweitern und sicherzustellen, dass sie den Anforderungen unserer Benutzer gerecht wird. Wir haben Unterstützung für F5 NGINX Plus hinzugefügt und unsere API-Oberfläche erweitert, um die am häufigsten nachgefragten Anwendungsfälle abzudecken. Wir sind überzeugt, 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 und bietet damit eine höhere Verfügbarkeit, detaillierte Metriken und Observability-Dashboards in Echtzeit.
• BackendTLSPolicy – Durch die TLS-Verifizierung kann NGINX Gateway Fabric die Identität der Backend-Anwendung bestätigen und so verhindern, dass bösartige Anwendungen die Verbindung übernehmen. Darüber hinaus verschlüsselt TLS den Datenverkehr innerhalb des Clusters und gewährleistet damit 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 Anfrage-URL ganz einfach ändern und an ein geeigneteres Ziel weiterleiten. So können Sie die APIs, die Sie Ihren Clients zur Verfügung stellen, auch dann konsistent halten, wenn sich die APIs Ihrer Backend-Anwendungen ändern.
• Produkttelemetrie – Dank der jetzt in NGINX Gateway Fabric verfügbaren Produkttelemetrie können wir dazu beitragen, die betriebliche Effizienz Ihrer Infrastruktur weiter zu verbessern, indem wir Erkenntnisse darüber gewinnen, wie Sie das Produkt in Ihrer Umgebung nutzen. Außerdem planen wir, diese Erkenntnisse bei unseren Treffen regelmäßig mit der Community zu teilen.

Im Folgenden sehen wir uns die neuen Funktionen genauer an.

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 zahlreiche neue Vorteile. Mit dem neuen Upgrade können Benutzer nun die erweiterten Funktionen von NGINX Plus in ihren Bereitstellungen nutzen, darunter zusätzliche Prometheus-Metriken, dynamisches Neuladen von Upstreams und das NGINX Plus-Dashboard. Dieses Upgrade bietet Ihnen außerdem die Möglichkeit, für Ihre Umgebung direkten Support von NGINX zu erhalten.

Zusätzliche Prometheus-Metriken

Wenn Sie NGINX Plus als Datenebene verwenden, werden zusätzlich zu den Metriken, die Sie normalerweise mit NGINX Open Source erhalten, weitere erweiterte Metriken exportiert. Dazu gehören unter anderem Metriken zu HTTP-Anfragen, Streams und Verbindungen. Eine vollständige Übersicht finden Sie im Prometheus-Exporter von NGINX in Form einer praktischen Liste. Beachten Sie jedoch, dass der Exporter für NGINX Gateway Fabric nicht zwingend erforderlich ist. Mit jeder Installation von Prometheus oder einem Prometheus-kompatiblen Scraper können Sie diese Metriken in Ihren Observability-Stack übernehmen und Dashboards sowie Warnmeldungen über eine einheitliche Ebene innerhalb Ihrer Architektur erstellen. Prometheus-Metriken sind in NGINX Gateway Fabric automatisch über HTTP-Port 9113 verfügbar. Sie können den Standardport auch ändern, indem Sie die Pod-Vorlage aktualisieren. Wenn Sie eine einfache Einrichtung wünschen, finden Sie auf unserer GitHub-Seite weitere Informationen dazu, wie Sie Prometheus bereitstellen und konfigurieren, um mit der Erfassung zu beginnen. Wenn Sie hingegen lediglich die Metriken anzeigen und die Einrichtung überspringen möchten, können Sie das im nächsten Abschnitt erläuterte NGINX Plus-Dashboard verwenden. 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 mit den akzeptierten Verbindungen von NGINX Gateway Fabric

Die oben beschriebene Konfiguration funktioniert auch, wenn Sie standardmäßig NGINX Open Source als Datenebene verwenden. Allerdings stehen Ihnen dann die zusätzlichen Metriken von NGINX Plus nicht zur Verfügung. Mit zunehmender Größe und wachsendem Umfang Ihres Clusters empfehlen wir Ihnen, zu prüfen, wie die Metriken von NGINX Plus dazu beitragen können, Probleme bei der Kapazitätsplanung, Störungen und sogar Fehler in Backend-Anwendungen schnell zu beheben.

Dynamisches Neuladen von Upstreams

Dynamische Upstream-Neuladungen, die von NGINX Gateway Fabric bei einer Installation mit NGINX Plus automatisch aktiviert werden, ermöglichen es NGINX Gateway Fabric, NGINX-Konfigurationen ohne ein Neuladen von NGINX zu aktualisieren. Bei einem herkömmlichen Neuladen von NGINX werden bestehende Verbindungen von den alten Worker-Prozessen verarbeitet, während die neu konfigurierten Worker neue Verbindungen übernehmen. Sobald alle alten Verbindungen abgeschlossen sind, werden die alten Worker beendet und NGINX wird ausschließlich mit den neu konfigurierten Workern weiter ausgeführt. Auf diese Weise werden Konfigurationsänderungen selbst in NGINX Open Source reibungslos umgesetzt. Wenn NGINX jedoch stark ausgelastet ist, kann der gleichzeitige Betrieb alter und neuer Worker einen zusätzlichen Ressourcenbedarf verursachen, der zu Problemen führen kann – insbesondere, wenn NGINX Gateway Fabric mit möglichst geringem Ressourcenverbrauch betrieben werden soll. Die in NGINX Plus verfügbaren dynamischen Upstream-Neuladungen umgehen dieses Problem, indem sie einen API-Endpunkt für Konfigurationsänderungen bereitstellen. NGINX Gateway Fabric verwendet diesen automatisch, sofern er vorhanden ist. Dadurch werden weniger zusätzliche Ressourcen benötigt, um während des Neuladevorgangs alte und neue Worker parallel zu betreiben. Wenn Sie häufiger Änderungen an NGINX Gateway Fabric vornehmen, werden auch Neuladungen häufiger durchgeführt. Wenn Sie wissen möchten, wie oft oder wann in Ihrer aktuellen NGF-Installation Neuladungen stattfinden, können Sie die Prometheus-Metrik nginx_gateway_fabric_nginx_reloads_total aufrufen. Eine ausführliche Analyse des Problems finden Sie in Nick Shadrins Artikel hier! Hier sehen Sie 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 von NGINX Gateway Fabric

NGINX Plus-Dashboard

Wie bereits erwähnt, bietet Ihnen das NGINX Plus-Dashboard eine Echtzeitüberwachung von Leistungsmetriken, mit denen Sie Störungen beheben und die Ressourcenkapazität im Blick behalten können, wenn Sie NGINX Plus-Metriken schnell und ohne Prometheus-Installation oder Observability-Stack anzeigen möchten. Das Dashboard stellt Ihnen sofort verschiedene Ansichten für alle von NGINX Plus bereitgestellten Metriken zur Verfügung und ist über einen internen Port leicht zugänglich. Wenn Sie sich selbst einen kurzen Überblick über die Funktionen des Dashboards verschaffen möchten, besuchen Sie unsere Dashboard-Demoseite unter demo.nginx.com. Um auf das NGINX Plus-Dashboard Ihrer NGINX Gateway Fabric-Installation zuzugreifen, können Sie Verbindungen per Portweiterleitung an Port 8765 auf Ihrem lokalen Rechner 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: Übersicht über das NGINX Plus Dashboard

BackendTLSPolicy

Diese Version bietet nun die lang erwartete Unterstützung für die BackendTLSPolicy. Die BackendTLSPolicy ermöglicht eine verschlüsselte TLS-Kommunikation zwischen NGINX Gateway Fabric und der Anwendung und erhöht damit die Sicherheit des Kommunikationskanals erheblich. Das folgende Beispiel zeigt, wie Sie die Richtlinie anwenden, indem Sie Einstellungen wie TLS-Verschlüsselungsverfahren und -Protokolle festlegen, wenn Sie Serverzertifikate anhand einer vertrauenswürdigen Zertifizierungsstelle (CA) validieren. Mit der BackendTLSPolicy können Benutzer den Datenverkehr zwischen NGF und ihren Backends absichern. Sie können außerdem die TLS-Mindestversion und die Verschlüsselungssammlungen festlegen. Dies verhindert, dass bösartige Anwendungen die Verbindung übernehmen, und verschlüsselt den Datenverkehr innerhalb des Clusters. Um die TLS-Terminierung für das Backend zu konfigurieren, erstellen Sie zunächst eine ConfigMap mit dem gewünschten CA-Zertifikat. Hilfe zur Verwaltung interner Kubernetes-Zertifikate finden Sie in diesem Leitfaden.

kind: ConfigMap
apiVersion: v1
metadata:
  name: backend-cert
data:
  ca.crt: 
         < -----BEGIN CERTIFICATE-----
	   -----END CERTIFICATE-----
          >

Als Nächstes erstellen wir die BackendTLSPolicy, die auf unseren secure-app-Service ausgerichtet ist und auf die im vorherigen Schritt erstellte ConfigMap verweist:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendTLSPolicy
metadata:
  name: backend-tls
spec:
  targetRef:
    group: ''
    kind: Service
    name: secure-app
    namespace: default
  tls:
    caCertRefs:
    - name: backend-cert
      group: ''
      kind: ConfigMap
    hostname: secure-app.example.com

URL-Umschreibung

Mit einem URLRewrite-Filter können Sie die ursprüngliche URL einer eingehenden Anfrage ändern und sie ohne Leistungseinbußen an eine andere URL weiterleiten. Dies ist besonders nützlich, wenn sich die von Ihren Backend-Anwendungen bereitgestellte API ändert, Sie aber die Abwärtskompatibilität für Ihre bestehenden Clients beibehalten möchten. Mit dieser Funktion können Sie Ihren Clients außerdem eine einheitliche API-URL bereitstellen und die Anfragen gleichzeitig an verschiedene Anwendungen mit unterschiedlichen API-URLs weiterleiten. So entsteht eine „Experience“-API, die die Funktionen mehrerer APIs kombiniert und Ihren Clients dadurch mehr Komfort und eine bessere Performance bietet. Erstellen wir zunächst ein Gateway für NGINX Gateway Fabric. Damit können wir HTTP-Listener definieren und Port 80 für eine optimale Performance konfigurieren.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cafe
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP

Erstellen wir eine HTTPRoute-Ressource und konfigurieren wir Anfragefilter so, dass alle Anfragen an /coffee in /beans umgeschrieben werden. Außerdem können wir einen /latte-Endpunkt bereitstellen, der so umgeschrieben wird, dass das Backend das Präfix /latte verarbeiten kann („/latte/126“ wird zu „/126“).

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: coffee
spec:
  parentRefs:
  - name: cafe
    sectionName: http
  hostnames:
  - "cafe.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplaceFullPath
          replaceFullPath: /beans
    backendRefs:
    - name: coffee
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /latte
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - name: coffee
      port: 80

Die HTTP-Rewrite-Funktion sorgt für Flexibilität zwischen den Endpunkten auf der Clientseite und ihrer Zuordnung zum Backend. Sie ermöglicht außerdem die Umleitung des Datenverkehrs von einer URL zu einer anderen, was insbesondere bei der Migration von Inhalten auf eine neue Website oder von API-Datenverkehr hilfreich ist. Obwohl NGINX Gateway Fabric pfadbasierte Rewrites unterstützt, werden pfadbasierte Weiterleitungen derzeit nicht unterstützt. Teilen Sie uns mit, wenn Sie diese Funktion für Ihre Umgebung benötigen.

Produkttelemetrie

Wir haben uns entschieden, im Rahmen der Version 1.2 Produkttelemetrie als Mechanismus zur passiven Erfassung von Feedback einzuführen. Diese Funktion erfasst verschiedene Metriken aus Ihrer Umgebung und übermittelt sie alle 24 Stunden an unsere Datenerfassungsplattform. Es werden keine personenbezogenen Daten erfasst. Eine vollständige Liste der erfassten Daten finden Sie hier. Wir verpflichten uns zu vollständiger Transparenz hinsichtlich unserer Telemetriefunktion. Wir dokumentieren jedes erfasste Feld, und Sie können anhand unseres Codes überprüfen, welche Daten wir erfassen. Zudem haben Sie jederzeit die Möglichkeit, die Funktion vollständig zu deaktivieren. Wir planen, interessante Erkenntnisse aus den erfassten Statistiken regelmäßig gemeinsam mit der Community in unseren Community-Meetings zu besprechen – schauen Sie also unbedingt vorbei!

Ressourcen

Das vollständige Änderungsprotokoll für NGINX Gateway Fabric 1.2.0 finden Sie in den Versionshinweisen. Wenn Sie NGINX Gateway Fabric für Kubernetes mit NGINX Plus ausprobieren möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen. Wenn Sie sich beteiligen, erfahren möchten, was als Nächstes geplant ist, oder den Quellcode von NGINX Gateway Fabric einsehen möchten, besuchen Sie unser Repository auf GitHub! Unsere Community-Meetings finden alle zwei Wochen montags um 9:00 Uhr pazifischer Zeit bzw. 17:00 Uhr GMT statt. Den Link zum Meeting sowie Neuigkeiten, die Agenda und Notizen finden Sie im NGINX Gateway Fabric Meeting Calendar. Die Links sind außerdem jederzeit in unserer GitHub-README-Datei verfügbar.

Über die Autoren

Akash AnanthanarayananManager für technisches Marketing | F5 NGINX

Weitere Blogbeiträge von Akash Ananthanarayanan

Mike StefaniakSenior-Produktmanager | F5 NGINX

Weitere Blogbeiträge von Mike Stefaniak