Ankündigung von NGINX Plus R16

Liam CrillySenior Director, Produktmanagement

[ngx_snippet name=’table-style-blog’]
Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 16 (R16) ab sofort verfügbar ist. Das heutige Release ist eines der wichtigsten für die Weiterentwicklung der technischen Vision von NGINX. Mit R16 fungiert NGINX Plus nun als zentrale, elastische Ingress- und Egress-Schicht für all Ihre Anwendungen. Dadurch können Sie die Funktionen eines Load Balancers, API-Gateways und einer WAF in einem einzigen Softwarepaket bündeln, das sich über jede Cloud erstreckt.

Viele Unternehmen, mit denen wir heute sprechen, setzen jede dieser Komponenten ein, beziehen sie jedoch häufig von unterschiedlichen Anbietern. Dies erhöht die Kosten und die Komplexität, da die Betriebsteams jede Einzellösung separat verwalten müssen. Außerdem werden Leistung und Zuverlässigkeit beeinträchtigt, da jeder zusätzliche Verarbeitungsschritt die Latenz erhöht und weitere potenzielle Fehlerquellen schafft.

Mit den neuen Funktionen in NGINX Plus R16 können Sie damit beginnen, Ihre Infrastruktur zu konsolidieren und zu vereinfachen und eine elastische Ingress-/Egress-Schicht für Legacy- und moderne Anwendungen aufzubauen. NGINX Plus R16 umfasst neue Clustering-Funktionen, einen verbesserten UDP-Lastenausgleich und DDoS-Schutz und stellt damit einen umfassenderen Ersatz für kostspielige F5 BIG-IP-Hardware und andere Lastenausgleichsinfrastrukturen dar. Die neue Unterstützung für globale Ratenbegrenzung macht NGINX Plus zudem zu einer schlanken Alternative zu vielen API-Gateway-Lösungen. Und schließlich macht die neue Unterstützung für den Lastenausgleich nach dem Verfahren „Random with Two Choices“ NGINX Plus zur idealen Wahl für den Lastenausgleich des Microservices-Datenverkehrs in skalierten oder verteilten Umgebungen wie Kubernetes.

Zusammenfassung der neuen Funktionen von NGINX Plus R16

Zu den neuen Funktionen in NGINX Plus R16 gehören:

• Clusterweites Rate-Limiting – In NGINX Plus R15 haben wir das Modul zur gemeinsamen Statusnutzung eingeführt, mit dem Daten in einem NGINX Plus-Cluster synchronisiert werden können. In dieser Version wird die gemeinsame Statusnutzung auf die Funktion Rate-Limiting ausgeweitet, sodass Sie globale Ratenbegrenzungen für einen NGINX Plus-Cluster festlegen können. Globales Rate-Limiting ist eine wichtige Funktion für API-Gateways und ein äußerst beliebter Anwendungsfall für NGINX Plus.
• Clusterfähiger Schlüssel-Wert-Speicher – Mit NGINX Plus R13 haben wir einen Schlüssel-Wert-Speicher eingeführt, der beispielsweise zum Erstellen einer dynamischen Sperrliste für IP-Adressen oder zum Verwalten von HTTP-Weiterleitungen verwendet werden kann. In dieser Version kann der Schlüssel-Wert-Speicher nun clusterweit synchronisiert werden und verfügt über einen neuen Parameter namens timeout, mit dem einzelne Schlüssel-Wert-Paare automatisch entfernt werden können. Dank der neuen Synchronisierungsunterstützung kann der Schlüssel-Wert-Speicher nun zur dynamischen DDoS-Abwehr, zur Verteilung authentifizierter Sitzungstoken oder zum Aufbau eines verteilten Content-Caches (CDN) verwendet werden.
• Lastverteilung nach dem „Power of Two Choices“-Prinzip – Beim Clustering von Load Balancern ist es wichtig, einen Lastverteilungsalgorithmus zu verwenden, der nicht unbeabsichtigt einzelne Backend-Server überlastet. Die Lastverteilung nach dem „Power of Two Choices“-Prinzip ist für skalierte Cluster äußerst effizient und wird in der nächsten Version des NGINX Ingress Controller für Kubernetes die Standardmethode sein.
• Verbesserter UDP-Lastenausgleich – Mit NGINX Plus R9 haben wir erstmals den UDP-Lastenausgleich eingeführt. Diese ursprüngliche Implementierung war auf UDP-Anwendungen beschränkt, die bei jeder Interaktion mit dem Server ein einzelnes UDP-Paket vom Client erwarten (z. B. DNS und RADIUS). NGINX Plus R16 kann mehrere UDP-Pakete vom Client verarbeiten, sodass wir komplexere UDP-Protokolle wie OpenVPN, Voice over IP (VoIP) und virtuelle Desktop-Infrastrukturen (VDI) unterstützen können.
• Unterstützung für AWS PrivateLink – AWS PrivateLink ist eine Technologie von Amazon zur Einrichtung sicherer VPN-Tunnel in eine Virtual Private Cloud. Mit dieser Version können Sie nun den Datenverkehr authentifizieren, weiterleiten und per Lastenausgleich verteilen sowie den Datenfluss innerhalb eines AWS-PrivateLink-Rechenzentrums optimieren. Diese Funktionalität basiert auf der neuen Unterstützung für das PROXY-Protokoll v2.

Weitere Verbesserungen umfassen die Unterstützung für opake OpenID-Connect-Sitzungstoken, das dynamische Modul Encrypted Session, Aktualisierungen des NGINX-JavaScript-Moduls und vieles mehr. NGINX Plus R16 basiert auf NGINX Open Source 1.15.2 und enthält alle Funktionen der Open-Source-Version.

Während der Entwicklung von NGINX Plus R16 haben wir außerdem eine Reihe bedeutender Verbesserungen am offiziellen NGINX Ingress Controller für Kubernetes vorgenommen, einem wichtigen Anwendungsfall für NGINX Plus.

Erfahren Sie mehr über NGINX Plus R16 und alles rund um NGINX auf der NGINX Conf 2018. In speziellen Vorträgen und Demos stellen Ihnen unsere Experten alle neuen Funktionen ausführlich vor.

Wichtige Verhaltensänderungen

• Die Upstream-Conf- und Status-APIs, die durch die einheitliche NGINX Plus API ersetzt und als veraltet eingestuft wurden, sind entfernt worden. Im August 2017 wurde mit NGINX Plus R13 die völlig neue NGINX Plus API zur dynamischen Neukonfiguration von Upstream-Gruppen und zur Überwachung von Metriken eingeführt. Sie ersetzte die Upstream-Conf- und Status-APIs, die diese Funktionen zuvor bereitgestellt hatten. Wie damals angekündigt, blieben die veralteten APIs noch über einen längeren Zeitraum verfügbar und wurden weiterhin unterstützt. Dieser Zeitraum ist nun abgelaufen. Wenn Ihre Konfiguration die Direktiven upstream_conf und/oder status enthält, müssen Sie diese im Rahmen des Upgrades auf R16 durch die Direktive api ersetzen. Hinweise und Unterstützung bei der Migration zur neuen NGINX Plus API finden Sie im Migrationsleitfaden in unserem Blog. Alternativ können Sie sich an unser Supportteam wenden.
• Unterstützung für nicht mehr gepflegte Betriebssystemversionen eingestellt – NGINX Plus wird unter Ubuntu 17.10 (Artful), FreeBSD 10.3 und FreeBSD 11.0 nicht mehr unterstützt. Weitere Informationen zu den unterstützten Plattformen finden Sie in den technischen Spezifikationen für NGINX Plus und dynamische Module.
• Das NGINX New Relic-Plug-in wurde aktualisiert und verwendet nun die neue NGINX Plus API. Außerdem ist es jetzt ein Open-Source-Projekt. Das aktualisierte Plug-in funktioniert mit allen Versionen von NGINX Plus ab R13, wird jedoch nicht mehr von NGINX, Inc. unterstützt oder gepflegt.

Neue Funktionen im Detail

Clusterweites Rate-Limiting

Mit NGINX Plus R15 wurde das Modul „zone_sync“ eingeführt, mit dem der Laufzeitstatus von allen NGINX Plus-Knoten in einem Cluster gemeinsam genutzt werden kann.

Die erste synchronisierte Funktion war die Sticky-Learn-Sitzungspersistenz. NGINX Plus R16 erweitert die gemeinsame Nutzung von Zustandsinformationen auf die Funktion Ratenbegrenzung. Beim Einsatz in einem Cluster kann NGINX Plus nun unabhängig davon, bei welchem Mitgliedsknoten des Clusters eine Anfrage eingeht, eine einheitliche Ratenbegrenzung auf eingehende Anfragen anwenden. Dies wird allgemein als globale Ratenbegrenzung bezeichnet. Die Anwendung einer einheitlichen Ratenbegrenzung in einem Cluster ist insbesondere für API-Gateway-Anwendungsfälle relevant, bei denen APIs gemäß einer Dienstgütevereinbarung (SLA) bereitgestellt werden, die verhindert, dass Clients eine festgelegte Ratenbegrenzung überschreiten.

Für die gemeinsame Nutzung von Zustandsinformationen benötigt und verwendet NGINX Plus keinen primären Knoten – alle Knoten sind gleichberechtigt und tauschen Daten in einer Full-Mesh-Topologie aus. Ein NGINX Plus-Cluster für die gemeinsame Nutzung von Zustandsinformationen muss drei Anforderungen erfüllen:

• Netzwerkverbindung zwischen allen Clusterknoten
• Synchronisierte Uhren
• Konfiguration auf jedem Knoten, die das Modul „zone_sync“ aktiviert, wie im folgenden Ausschnitt gezeigt.

stream {    resolver 10.0.0.53 valid=20s;

    server {
        listen 10.0.0.1:9000;
        zone_sync;
        zone_sync_server nginx-cluster.example.com:9000 resolve;
    }
}

Die zone_sync-Direktive ermöglicht die Synchronisierung gemeinsam genutzter Speicherzonen in einem Cluster. Die zone_sync_server-Direktive identifiziert die anderen NGINX Plus-Instanzen im Cluster. NGINX Plus unterstützt die DNS-Diensterkennung, sodass Clusterknoten anhand ihres Hostnamens identifiziert werden können und die Konfiguration auf allen Knoten identisch ist. Beachten Sie, dass es sich hierbei um eine Minimalkonfiguration ohne die für den Produktivbetrieb erforderlichen Sicherheitsmaßnahmen handelt. Weitere Informationen finden Sie in der Ankündigung zu NGINX Plus R15 und in der Referenzdokumentation für das zone_sync-Modul.

Sobald diese Konfiguration auf allen Knoten eingerichtet ist, können Ratenbegrenzungen im gesamten Cluster angewendet werden, indem einfach der neue Parameter „sync“ zur Direktive „limit_req_zone“ hinzugefügt wird. Mit der folgenden Konfiguration legt NGINX Plus für jeden Client eine Ratenbegrenzung von 100 Anfragen pro Sekunde fest, die auf der IP-Adresse des Clients basiert.

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync; # Cluster-aware
server {
    listen 80;
    location / {
        limit_req zone=per_ip; # Apply rate limit here
        proxy_pass http://my_backend;
    }
}

Darüber hinaus ist die Clusterlösung mit gemeinsamer Statusverwaltung unabhängig von der keepalived-basierten Hochverfügbarkeitslösung für Netzwerkresilienz. Daher kann sich ein Cluster mit gemeinsamer Statusverwaltung im Gegensatz zu dieser Lösung über mehrere physische Standorte erstrecken.

Clusterfähiger Schlüssel-Wert-Speicher

Mit NGINX Plus R13 wurde ein leichtgewichtiger In-Memory-Schlüssel-Wert-Speicher als natives NGINX-Modul eingeführt. Dieses Modul ist in NGINX Plus enthalten. Dadurch können Lösungen, die einen einfachen Datenbankspeicher benötigen, ohne die Installation zusätzlicher Softwarekomponenten konfiguriert werden. Darüber hinaus wird der Schlüssel-Wert-Speicher über die NGINX Plus API gesteuert, sodass Einträge über eine REST-Schnittstelle erstellt, geändert und gelöscht werden können.

Zu den Anwendungsfällen für den Schlüssel-Wert-Speicher von NGINX Plus gehören die dynamische Sperrung von IP-Adressen, die dynamische Bandbreitenbegrenzung und das Zwischenspeichern von Authentifizierungstoken.

Mit NGINX Plus R16 ist der Schlüssel-Wert-Speicher jetzt clusterfähig, sodass Einträge über alle Knoten eines Clusters hinweg synchronisiert werden. Das bedeutet, dass Lösungen, die den Schlüssel-Wert-Speicher von NGINX Plus verwenden, in allen Arten von Clusterumgebungen bereitgestellt werden können – aktiv-passiv, aktiv-aktiv und auch weit verteilt.

Wie bei den anderen clusterfähigen Funktionen konfigurieren Sie die Synchronisierung des Schlüssel-Wert-Speichers, indem Sie einfach den Parameter sync zur Direktive keyval_zone für einen Cluster hinzufügen, der bereits für die gemeinsame Nutzung von Zustandsinformationen konfiguriert wurde (mit den Direktiven zone_sync und zone_sync_server).

Der Schlüssel-Wert-Speicher wurde außerdem um die Möglichkeit erweitert, für jedes hinzugefügte Schlüssel-Wert-Paar einen Zeitüberschreitungswert festzulegen. Solche Einträge laufen nach Ablauf des angegebenen Zeitraums automatisch ab und werden aus dem Schlüssel-Wert-Speicher entfernt. Der Parameter „timeout“ ist bei der Konfiguration eines synchronisierten Schlüssel-Wert-Speichers obligatorisch.

Verwendung des NGINX Plus Schlüssel-Wert-Speichers für dynamischen DDoS-Schutz

Sie können die neuen Clustering-Funktionen von NGINX Plus kombinieren, um eine ausgefeilte Lösung zum Schutz vor DDoS-Angriffen zu entwickeln. Wenn ein Pool von NGINX Plus-Instanzen in einem Aktiv-Aktiv-Cluster bereitgestellt oder über ein Weitverkehrsnetz verteilt wird, kann schädlicher Datenverkehr jede dieser Instanzen erreichen. Diese Lösung nutzt eine synchronisierte Ratenbegrenzung und einen synchronisierten Schlüssel-Wert-Speicher, um dynamisch auf DDoS-Angriffe zu reagieren und deren Auswirkungen wie folgt zu mindern.

• Eine clusterweite Ratenbegrenzung erkennt Clients, die mehr als 100 Anfragen pro Sekunde senden – unabhängig davon, welcher NGINX Plus-Knoten die Anfrage empfängt.
• Wenn ein Client das Ratenlimit überschreitet, wird seine IP-Adresse durch einen Aufruf der NGINX Plus-API einem Schlüssel-Wert-Speicher für gesperrte Clients hinzugefügt. Dieser Speicher wird im gesamten Cluster synchronisiert.
• Weitere Anfragen von Clients in der Sperrliste unterliegen einer sehr niedrigen Bandbreitenbegrenzung, unabhängig davon, welcher NGINX Plus-Knoten sie empfängt. Die Bandbreite zu begrenzen ist einer vollständigen Ablehnung der Anfragen vorzuziehen, da dem Client dadurch nicht eindeutig signalisiert wird, dass Maßnahmen zur DDoS-Abwehr aktiv sind.
• Nach zehn Minuten wird der Client automatisch von der Sperrliste entfernt.

Die folgende Konfiguration zeigt eine vereinfachte Implementierung dieser dynamischen Lösung zur DDoS-Abwehr.

limit_req_zone   $remote_addr zone=per_ip:1M rate=100r/s sync; # Cluster-aware rate limitlimit_req_status 429;

keyval_zone zone=sinbin:1M timeout=600 sync; # Cluster-aware "sin bin" with 
                                             # 10-minute TTL
keyval $remote_addr $in_sinbin zone=sinbin;  # Populate $in_sinbin with 
                                             # matched client IP addresses

server {
    listen 80;
    location / {
        if ($in_sinbin) {
            set $limit_rate 50; # Restrict bandwidth of bad clients
        }

        limit_req zone=per_ip;            # Apply the rate limit here
        error_page 429 = @send_to_sinbin; # Excessive clients are moved to 
                                          # this location
        proxy_pass http://my_backend;
    }

    location @send_to_sinbin {
        rewrite ^ /api/3/http/keyvals/sinbin break; # Set the URI of the 
                                                    # "sin bin" key-val
        proxy_method POST;
        proxy_set_body '{"$remote_addr":"1"}';
        proxy_pass http://127.0.0.1:80;
    }

    location /api/ {
        api write=on;
        # directives to control access to the API
    }
}

Zufälliger Lastenausgleich mit zwei Auswahlmöglichkeiten

Sowohl bei der Bereitstellung von Anwendungen als auch von APIs kommen zunehmend skalierte oder verteilte Load-Balancing-Ebenen zum Einsatz, die Clientanfragen entgegennehmen und an eine gemeinsam genutzte Anwendungsumgebung weiterleiten. Wenn mehrere Load Balancer Anfragen an dieselbe Gruppe von Backend-Servern weiterleiten, ist es wichtig, ein Load-Balancing-Verfahren zu verwenden, das nicht unbeabsichtigt einzelne Backend-Server überlastet.

NGINX Plus-Cluster, die in einer Aktiv-Aktiv-Konfiguration bereitgestellt werden, oder verteilte Umgebungen mit mehreren Einstiegspunkten sind gängige Szenarien, die herkömmliche Lastverteilungsverfahren vor Herausforderungen stellen können, da kein einzelner Load Balancer vollständige Kenntnis über alle an die Backend-Server gesendeten Anfragen haben kann.

Der Lastenausgleich innerhalb eines containerisierten Clusters weist dieselben Merkmale auf wie eine skalierte Aktiv-Aktiv-Bereitstellung. Kubernetes-Ingress-Controller, die in einem Replikatsatz mit mehreren Instanzen der Ingress-Ressource bereitgestellt werden, stehen ebenfalls vor der Herausforderung, die Last effektiv auf die Pods zu verteilen, die die einzelnen Dienste im Cluster bereitstellen.

Clustertopologien, die vom Lastenausgleich nach dem Prinzip „Random with Two Choices“ profitieren

Schwankungen der Arbeitslast haben einen erheblichen Einfluss auf die Effektivität der verteilten Lastverteilung. Wenn jede Anfrage den Backend-Server gleich stark belastet, lässt sich anhand der Reaktionszeit der einzelnen Server auf frühere Anfragen effektiv entscheiden, wohin die nächste Anfrage gesendet werden soll. Exklusiv in NGINX Plus verfügbar ist die Lastverteilungsmethode Least Time, die genau dies leistet. Wenn die Belastung des Backend-Servers jedoch variiert (etwa weil sowohl Lese- als auch Schreibvorgänge ausgeführt werden), ist die bisherige Leistung ein schlechter Indikator für die zukünftige Leistung.

Die einfachste Möglichkeit, die Last in einer verteilten Umgebung auszugleichen, besteht darin, einen Backend-Server nach dem Zufallsprinzip auszuwählen. Mit der Zeit gleicht sich die Last zwar aus, doch dieser grobe Ansatz führt wahrscheinlich dazu, dass einzelne Server gelegentlich mit Lastspitzen konfrontiert werden.

Eine einfache Variante des zufälligen Lastenausgleichs, die jedoch nachweislich die Lastverteilung verbessert, besteht darin, zwei Backend-Server nach dem Zufallsprinzip auszuwählen und die Anfrage anschließend an den Server mit der geringeren Auslastung zu senden. Durch den Vergleich zweier zufälliger Optionen soll eine schlechte Entscheidung beim Lastenausgleich vermieden werden, auch wenn die getroffene Entscheidung nicht optimal ist. Indem der Backend-Server mit der höheren Auslastung gemieden wird, kann jeder Load Balancer unabhängig arbeiten und dennoch verhindern, dass einzelne Backend-Server mit Lastspitzen konfrontiert werden. Dadurch bietet diese Methode die Vorteile und die Recheneffizienz des zufälligen Lastenausgleichs, erzielt jedoch eine nachweislich bessere Lastverteilung.

NGINX Plus R16 führt zwei neue Methoden für den Lastenausgleich ein: „Random“ und „Random with Two Choices“. Bei Letzterer können Sie zusätzlich festlegen, welche Metrik zur Lastanzeige NGINX Plus vergleicht, um zu entscheiden, welches der beiden ausgewählten Backends die Anfrage erhält. Die folgende Tabelle führt die verfügbaren Metriken auf.

* Alle zeitbasierten Metriken sind ausschließlich in NGINX Plus verfügbar

Das folgende Snippet zeigt ein einfaches Beispiel für eine „Random with Two Choices“-Konfiguration zur Lastverteilung mit der Direktive random two (HTTP, Stream).

upstream my_backend {    zone my_backend 64k;
    server 10.0.0.1;
    server 10.0.0.2;
    server 10.0.0.3;
    #...
    random two least_time=last_byte; # Choose the quicker response time from two random choices
}

server {
    listen 80;
    location / {
        proxy_pass http://my_backend; # Load balance to upstream group
    }
}

Beachten Sie, dass die Methode „Random with Two Choices“ nur für verteilte Umgebungen geeignet ist, in denen mehrere Load Balancer Anfragen an dieselbe Gruppe von Backends weiterleiten. Verwenden Sie sie nicht, wenn NGINX Plus auf einem einzelnen Host oder in einer Aktiv-Passiv-Konfiguration bereitgestellt wird. In diesen Fällen hat der einzelne Load Balancer einen vollständigen Überblick über alle Anfragen, und die Methoden Round Robin, Least Connections und Least Time liefern die besten Ergebnisse.

Verbesserter UDP-Lastenausgleich

Mit NGINX Plus R9 wurde die Unterstützung für Proxying und Lastverteilung von UDP-Datenverkehr eingeführt. Dadurch kann NGINX Plus beliebten UDP-Anwendungen wie DNS, Syslog, NTP und RADIUS vorgeschaltet werden, um eine hohe Verfügbarkeit und Skalierbarkeit der Anwendungsserver zu gewährleisten. Die ursprüngliche Implementierung war auf UDP-Anwendungen beschränkt, die bei jeder Interaktion mit dem Server ein einzelnes UDP-Paket vom Client erwarten.

Mit NGINX Plus R16 werden mehrere eingehende Pakete unterstützt, sodass auch komplexere UDP-Anwendungen über einen Proxy geleitet und per Lastverteilung verteilt werden können. Dazu gehören OpenVPN, VoIP, virtuelle Desktop-Lösungen und Sitzungen mit Datagram Transport Layer Security (DTLS). Darüber hinaus verarbeitet NGINX Plus alle UDP-Anwendungen – ob einfach oder komplex – deutlich schneller.

NGINX Plus ist der einzige softwarebasierte Load Balancer, der vier der beliebtesten Webprotokolle – UDP, TCP, HTTP und HTTP/2 – gleichzeitig auf derselben Instanz per Load Balancing verteilen kann.

Unterstützung für PROXY Protocol v2

NGINX Plus R16 unterstützt nun den PROXY-Protocol-v2-Header (PPv2) sowie die Überprüfung benutzerdefinierter Typ-Längen-Wert-Felder (TLV) im Header.

Das PROXY-Protokoll wird von Layer-7-Proxys wie NGINX Plus und den Load Balancern von Amazon verwendet, um Verbindungsinformationen an Upstream-Server zu übertragen, die sich hinter weiteren Layer-7-Proxys oder NAT-Geräten befinden. Dies ist erforderlich, da beim Weiterleiten von Verbindungen durch Proxys bestimmte Verbindungsinformationen wie die Quell-IP-Adresse und der Quellport verloren gehen können und es nicht immer möglich ist, diese Informationen durch das Einfügen von HTTP-Headern zu übertragen. Frühere Versionen von NGINX Plus unterstützten den PPv1-Header; NGINX Plus R16 unterstützt nun auch den PPv2-Header.

PPv2 mit Amazon Network Load Balancer verwenden

Ein Anwendungsfall für den PPv2-Header sind Verbindungen, die über den Amazon Network Load Balancer (NLB) weitergeleitet werden und scheinbar von einer privaten IP-Adresse des Load Balancers stammen. Der NLB stellt jeder Verbindung einen PPv2-Header voran, der die tatsächliche Quell-IP-Adresse und den Port der Clientverbindung angibt. Die tatsächliche Quelle kann aus der Variable $proxy_protocol_addr abgerufen werden. Mit dem Modul realip können Sie außerdem die internen Quellvariablen von NGINX überschreiben und dafür die Werte aus dem PPv2-Header verwenden.

PPv2 mit AWS PrivateLink verwenden

AWS PrivateLink ist eine Technologie von Amazon zum Erstellen sicherer VPN-Tunnel in eine Virtual Private Cloud (VPC). Sie wird häufig verwendet, um einen Anbieterdienst (der in der Anbieter-VPC ausgeführt wird) zu veröffentlichen und für eine oder mehrere Client-VPCs verfügbar zu machen. Verbindungen zum Anbieterdienst gehen von einem NLB aus, der in der Anbieter-VPC ausgeführt wird.

In vielen Fällen muss der Anbieterdienst wissen, woher die einzelnen Verbindungen stammen. Die Quell-IP-Adresse im PPv2-Header ist jedoch im Grunde bedeutungslos, da sie einer internen, nicht routingfähigen Adresse in der Client-VPC entspricht. Der AWS PrivateLink-NLB fügt dem Header die Quell-VPC-ID mithilfe des PPv2-TLV-Eintrags 0xEA hinzu.

NGINX Plus kann PPv2-TLV-Datensätze untersuchen und mithilfe der Variable $proxy_protocol_tlv_0xEA die Quell-VPC-ID für AWS-PrivateLink-Verbindungen extrahieren. Dadurch kann der Datenverkehr in einem AWS-PrivateLink-Rechenzentrum authentifiziert, weitergeleitet und gesteuert werden.

Weitere neue Funktionen in NGINX Plus R16

Opake OpenID-Connect-Sitzungstoken

Die NGINX Plus OpenID Connect-Referenzimplementierung wurde um die Unterstützung undurchsichtiger Sitzungstoken erweitert. Bei diesem Anwendungsfall wird das JWT-Identitätstoken nicht an den Client gesendet. Stattdessen wird es im Schlüssel-Wert-Speicher von NGINX Plus gespeichert und durch eine zufällige Zeichenfolge ersetzt. Wenn der Client die zufällige Zeichenfolge übermittelt, wird sie gegen das JWT ausgetauscht und validiert. Dieser Anwendungsfall wurde vom Prototyp-/Experimentierstadium auf Produktionsreife angehoben, da Einträge im Schlüssel-Wert-Speicher nun mit einem Zeitlimit versehen und clusterübergreifend synchronisiert werden können.

Dynamisches Modul für verschlüsselte Sitzungen

Das Community-Modul „Encrypted Session“ unterstützt die Ver- und Entschlüsselung von NGINX-Variablen auf Basis von AES‑256 mit MAC. Es ist jetzt im NGINX Plus-Repository als unterstütztes dynamisches Modul für NGINX Plus verfügbar.

Verbesserungen am NGINX-JavaScript-Modul

Die NGINX-JavaScript-Module in R16 umfassen eine Reihe von Erweiterungen des Umfangs der JavaScript-Sprachunterstützung. Das HTTP-JavaScript-Modul wurde vereinfacht, sodass nun ein einzelnes Objekt (r) sowohl auf die Anfrage- als auch auf die Antwortattribute der jeweiligen Anfrage zugreift. Zuvor gab es separate Anfrage- (req) und Antwortobjekte (res). Durch diese Vereinfachung entspricht das HTTP-JavaScript-Modul nun dem Stream-JavaScript-Modul, das über ein einzelnes Sitzungsobjekt (s) verfügt. Diese Änderung ist vollständig abwärtskompatibel – vorhandener JavaScript-Code funktioniert weiterhin unverändert –, wir empfehlen jedoch, vorhandenen JavaScript-Code anzupassen, um diese Vereinfachung zu nutzen, und sie auch in künftig geschriebenem Code zu verwenden.

Die JavaScript-Sprachunterstützung umfasst jetzt:

• String-Methoden: bytesFrom(), padStart(), und padEnd()
• Zusätzliche Methoden: getrandom() und getentropy()
• Binärliterale

Die vollständige Liste der Änderungen am JavaScript-Modul ist im Änderungsprotokoll dokumentiert.

Neue $ssl_preread_protocol-Variable

Mit der neuen Variable $ssl_preread_protocol können Sie beim Weiterleiten von Datenverkehr über einen TCP-Proxy (Stream-Proxy) zwischen SSL/TLS und anderen Protokollen unterscheiden. Die Variable enthält die höchste vom Client unterstützte SSL/TLS-Protokollversion. Dies ist nützlich, wenn Sie Firewall-Einschränkungen umgehen möchten, indem Sie beispielsweise SSL/TLS- und SSH-Dienste über denselben Port betreiben.

Weitere Informationen finden Sie im Beitrag „SSL- und Nicht-SSL-Protokolle über denselben Port ausführen“ in unserem Blog.

Verbesserungen am Kubernetes Ingress Controller

NGINX Plus kann den Datenverkehr in einer Vielzahl von Umgebungen verwalten. Ein wichtiger Anwendungsfall ist der Einsatz als Ingress-Load-Balancer für Kubernetes. NGINX entwickelt eine Ingress-Controller-Lösung, die NGINX Plus automatisch konfiguriert. Diese Integration wird für alle Abonnenten von NGINX Plus vollständig unterstützt. (Alle Benutzer von NGINX Open Source und Kunden von NGINX Plus finden die Open-Source-Implementierung auf GitHub; außerdem werden regelmäßig offizielle Versionen veröffentlicht.)

NGINX Plus kann SSL für Kubernetes-Datenverkehr terminieren sowie diesen weiterleiten und lastverteilen

Im Zuge der Entwicklung von NGINX Plus R16 wurde der offizielle NGINX Ingress Controller für Kubernetes um eine Reihe bedeutender Verbesserungen erweitert:

• Prometheus-Unterstützung ermöglicht es Benutzern, Metriken von NGINX und NGINX Plus direkt nach Prometheus auf Kubernetes zu exportieren.
• Unterstützung für Helm-Charts vereinfacht die Installation und Verwaltung des Ingress-Controllers.
• Unterstützung für den Lastenausgleich von gRPC-Datenverkehr sorgt für hohe Verfügbarkeit und Skalierbarkeit von gPRC-basierten Anwendungen. (Hinzugefügt in Version 1.2.0.)
• Aktive Integritätsprüfungen von Kubernetes-Pods erkennen Ausfälle von Pods und Netzwerkverbindungen schnell.
• Mandantenfähige, zusammenführbare Konfiguration ermöglicht eine klare Aufgabentrennung, sodass Teams verschiedene Pfade derselben Webanwendung unabhängig voneinander verwalten können, während das Betriebsteam die Kontrolle über den Frontend-Listener und die SSL-Konfiguration behält.
• Feingranulare JWT-Authentifizierung, die pfadbezogen konfiguriert werden kann, ermöglicht eine präzisere Steuerung der Authentifizierung für komplexe Anwendungen.
• Die direkte Verwaltung von Konfigurationsvorlagen erleichtert die Entwicklung und das Testen benutzerdefinierter Änderungen an der NGINX-Konfiguration erheblich.

NGINX Ingress Controller kann zusätzlich mithilfe von ConfigMaps (zum Einbetten der NGINX-Konfiguration) oder durch Bearbeiten der Basisvorlagen erweitert werden. Dadurch können Benutzer beim Erstellen von Richtlinien für die Datenverkehrsverwaltung ihrer auf Kubernetes ausgeführten Anwendungen auf alle Funktionen von NGINX zugreifen.

Weitere Informationen finden Sie unter „Ankündigung von NGINX Ingress Controller für Kubernetes, Version 1.3.0“ in unserem Blog.

NGINX Plus aktualisieren oder testen

NGINX Plus R16 bietet zusätzliche Clustering-Funktionen, globale Ratenbegrenzung, einen neuen Lastverteilungsalgorithmus und mehrere Fehlerbehebungen. Wenn Sie NGINX Plus einsetzen, empfehlen wir Ihnen dringend, so bald wie möglich auf R16 zu aktualisieren. Dadurch erhalten Sie eine Reihe von Fehlerbehebungen und Verbesserungen. Außerdem kann NGINX, Inc. Sie so besser unterstützen, wenn Sie ein Support-Ticket erstellen müssen.

Bitte lesen Sie sich die neuen Funktionen und Verhaltensänderungen in diesem Blogbeitrag sorgfältig durch, bevor Sie mit dem Upgrade fortfahren.

Wenn Sie NGINX Plusnoch nicht ausprobiert haben, empfehlen wir Ihnen, es zu testen – zur Webbeschleunigung, zum Lastenausgleich und zur Anwendungsbereitstellung oder als vollständig unterstützten Webserver mit erweiterten APIs für Überwachung und Verwaltung. Starten Sie noch heute kostenlos mit einer 30-tägigen kostenlosen Testversion. Überzeugen Sie sich selbst davon, wie NGINX Plus Sie bei der Bereitstellung und Skalierung Ihrer Anwendungen unterstützen kann.

Über den Autor

Liam CrillySenior Director, Produktmanagement

Weitere Blogbeiträge von Liam Crilly