Von Daten bis hin zu großen Modellanwendungen: Am 25. November fand die Hangzhou Yuanchuang-Konferenz statt, um Entwicklungstipps auszutauschen.

NGINX entwickelt sich zu Cloud Native, einem Überblick über alles in OpenNJet

OpenNJet KIC (K ubernetes Ingress Controller) basiert auf den dynamischen Eigenschaften und der leistungsstarken Implementierung des OpenNJet-Proxys. Machen Sie die Mängel von Nginx in Cloud-nativen Szenarien wett. Bietet umfassende Funktionen zur Verkehrsverwaltung, wie z. B. dynamischer Standort, Host-/Pfad-Routing, Lastausgleich, dynamischer Upstream, Canary-Publishing, TLS-Terminierung/SNI usw.

Hauptmerkmale dieser Version:

Unterstützt Ingress-API, unterstützt Pfad-/Host-Routing
Unterstützt benutzerdefinierte Ressourcen-VirtualServer, unterstützt Pfad/Host, erweitertes Routing (Header, Anforderungsmethode usw.).
Unterstützt dynamischen Upstream
Unterstützt Upstream-Lastausgleich, Round-Robin und konsistente Hash-Algorithmen
Unterstützen Sie die aktive Upstream-Gesundheitsprüfung
Unterstützt TLS SNI
Unterstützen Sie die Sammlung von Prometheus-Indikatoren

Das Architekturdiagramm sieht wie folgt aus:

Übersicht über neue Funktionen

Ingress-API

OpenNJet KIC verwendet eine dynamische API-Methode, um Änderungen im grundlegenden Routing/TLS zu implementieren. Wenn sich die Ingress-Ressource ändert, ist es nicht erforderlich, die OpenNJet-Konfigurationsdatei neu zu laden. Wir verwenden einen einzelnen Server und mehrere Standorte, um den HTTP-Host-Header-Abgleich und den Pfad-Abgleich zu erreichen. Wie nachfolgend dargestellt:

Wenn sich der Host oder Pfad in der Ingress-Ressource ändert, werden die OpenNJet-Konfigurationsinformationen über die dynamische Standort-API aktualisiert, anstatt die OpenNJet-Konfigurationsdatei neu zu laden.

Wenn sich der mit der Ingress-Ressource verknüpfte Dienst ändert oder der mit dem Dienst verknüpfte Pod dynamisch erweitert oder verkleinert wird, aktualisieren wir die OpenNJet-Konfigurationsinformationen über die dynamische Upstream-API (derzeit basierend auf Lua implementiert), anstatt die OpenNJet-Konfigurationsdatei neu zu laden. Ressourcenänderungen gelten wie in der folgenden Tabelle beschrieben:

Ressourcenänderungen	Wie sich die OpenNJet-Konfigurationsinformationen ändern
Änderungen der Ingress-Ressource	neu löschen	Eindringen	Dynamische Standort-API Dynamische Upstream-API
Inhalt	Gastgeber	Dynamische Standort-API
Weg	Dynamische Standort-API
Service	Dynamische Upstream-API
Dynamische Expansion und Kontraktion der Schote		Endpunkt	Dynamische Upstream-API

VirtualServer CR-API

VirtualServer ist eine benutzerdefinierte Ressource, die die Ingress-Ressource in OpenNJet KIC ersetzt und eine Alternative darstellt. Zusätzlich zur Ingress-Funktion bietet VirtualServer auch umfangreichere Funktionen wie erweitertes inhaltsbasiertes Routing usw. und kann Anpassungsstrategien flexibel konfigurieren, um eine Graustufenveröffentlichung zu erreichen.

Wenn VS eine Route verarbeitet, wird der erweiterte Routenabgleich durch Übereinstimmungen in der Spezifikation definiert. Bedingungen definieren Bedingungen beim Abgleichen, Unterstützen von header , cookie , argument . variable

Hier ist ein Beispiel von VS:

apiVersion: k8s.njet.org/v1
kind: VirtualServer
metadata:
  name: cafe
  namespace: default
spec:
  host: cafe.example.com.vs
  routes:
  - action:
      pass: details
    matches:
    - action:
        pass: tea-post
      conditions:
      - value: POST
        variable: $request_method
    path: ~* \.html$
  - action:
      pass: ratings
    matches:
    - action:
        pass: productpage
      conditions:
      - cookie: version
        value: v2
      - value: GET
        variable: $request_method
    path: /productpage
  upstreams:
  - name: ratings
    port: 9080
    service: ratings
  - name: productpage
    port: 9080
    service: productpage
  - name: tea-post
    port: 80
    service: tea-post-svc
  - name: details
    port: 9080
    service: details

Im VS-Bild oben sind zwei Routen konfiguriert:

Regelmäßiger Abgleich mit Pfad als \.html$, Abgleich von Anfragen mit der Endung .html zur Implementierung des erweiterten Routings (Anfragen mit der Anfragemethode POST werden an den tea-post Upstream weitergeleitet, andere Anfragen werden an den Upstream weitergeleitet details (standardmäßig verarbeitet))
Der Pfad ist ein Präfixabgleich von /productpage, um erweitertes Routing zu implementieren (Anfragen mit der Anfragemethode GET und Cookie-Version=v2 werden an den productpage Upstream weitergeleitet, andere Anfragen werden an den Upstream weitergeleitet ratings (standardmäßig verarbeitet))

Die Implementierungsmethode ist grundsätzlich dieselbe wie bei Ingress.

Dynamischer Upstream

Im Hinblick auf die Upstream-Konfigurationsaktualisierung verwendet OpenNJet KIC Lua, um die dynamische Upstream-Konfiguration zu implementieren, um Cloud-native-Szenarien zu bewältigen. In Cloud-nativen Szenarien sind Upstream-Änderungen normal. Beispielsweise werden neue Dienste im Cluster bereitgestellt, ein Dienst wird dynamisch erweitert oder reduziert, Pods werden neu geplant usw., was alles zu Änderungen in Upstream-bezogenen Konfigurationen führt.

Die OpenNJet KIC-Konfiguration generiert einen Standard-Upstream namens „upstream_balancer“, der das gesamte Routing übernimmt. Wenn echter Datenverkehr eintrifft, wird er vom internen Lua-Kontext verarbeitet. „upstream_balancer“ ist wie folgt konfiguriert:

 upstream upstream_balancer {
        ### Attention!!!
        #
        # We no longer create "upstream" section for every backend.
        # Backends are handled dynamically using Lua.
        #
        ###

        server 0.0.0.1; # placeholder

        balancer_by_lua_block {
            balancer.balance()
        }

        keepalive 320;
        keepalive_time 1h;
        keepalive_timeout  120s;
        keepalive_requests 10000;
    }

Wie unterscheidet der Lua-Kontext, wer unterschiedliche Verkehrsströme bewältigen soll?

Zunächst erstellt OpenNJet KIC alle Upstream-Informationen über die dynamische Upstream-API-Schnittstelle.

Zweitens ist jede Route (Standort) mit dem Upstream-Namen verknüpft, der sie tatsächlich verwaltet.

Schließlich wird der Upstream-Name, der den Datenverkehr tatsächlich abwickelt, an den Lua-Kontext übergeben, um letztendlich sicherzustellen, dass der Datenverkehr korrekt verarbeitet wird.

Die Route ist flussaufwärts wie folgt zugeordnet:

Upstream-Update-Prozess

Upstream-Lastausgleich

Upstream kann die entsprechende Lastausgleichsstrategie festlegen. Derzeit werden der Standard-Round_Robin und ein konsistenter Hash unterstützt. Round_robin verwendet Polling, um Peers zu erhalten. Konsistentes Hashing führt den Ladevorgang basierend auf dem konfigurierten Hash-Schlüsselwert durch. Derselbe Schlüsselwert greift immer auf denselben Backend-Peer zu. Häufig verwendete Hash-Schlüssel sind:

Hash-Schlüssel	beschreiben
$arg_{VAR}	Führen Sie ein konsistentes Hashing basierend auf dem von der URL übergebenen Parameter VAR durch
$http_{NAME}	Führen Sie ein konsistentes Hashing basierend auf dem von HEADER übergebenen Parameter NAME durch
$cookie_{NAME}	Führen Sie ein konsistentes Hashing basierend auf dem vom Cookie übergebenen Parameter NAME durch
$remote_addr	Führen Sie konsistentes Hashing basierend auf der IP des Clients durch

Die internen Variablen, die OpenNJet verwenden kann, sind mit Nginx konsistent. Sie können sich auf die Dokumentation beziehen: https://nginx.org/en/docs/varindex.html

Sowohl Ingress als auch VirtualServer CR unterstützen die Konfiguration der Upstream-Lastausgleichsrichtlinie.

Das Folgende ist ein Beispiel für die Konfiguration des Upstream-Lastausgleichs durch VS:

Das obige Beispiel verwendet lb-method: „chash $arg_uu“, um explizit zu deklarieren, dass der Upstream-Lastausgleichsalgorithmus chash ist, und verwendet den in der Anfrage enthaltenen Parameter uu als Hash-Schlüssel.

Vorgelagerter proaktiver Gesundheitscheck

OpenNJet KIC bietet aktive Upstream-Zustandsprüfungsfunktionen, um sicherzustellen, dass alle Anfragen von einem fehlerfreien Upstream-Backend verarbeitet werden können, was die Benutzererfahrung verbessert.

Konfigurieren Sie die aktive Gesundheitsprüfung des Upstreams über Ingress und VirtualServer CR. OpenNJet KIC prüft jeden Upstream-Peer über einen separaten Privilege-Agent-Prozess. Wenn die Peer-Prüfung fehlschlägt und die Anzahl der Fehler den vorkonfigurierten Schwellenwert erreicht, überprüft das Gesundheitsprüfungsprogramm dies entsprechend Der Peer wird aus der Upstream-Peer-Liste entfernt. Wenn sich der entfernte Peer in einem fehlerfreien Zustand befindet und bei nachfolgenden Prüfungen den konfigurierten Schwellenwert erreicht, wird ein Re-Online-Vorgang ausgelöst.

Die folgende Abbildung zeigt das Diagramm der Health-Check-Architektur:

Wenn Upstream-Daten aktualisiert werden, wird eine Kopie der „rohen HC-Backends“ generiert und die Integritätsprüfung im Timer verwendet die Daten in dieser Kopie. Wenn die Ergebnisse der Integritätsprüfung Änderungen bei Peers auslösen müssen, aktualisieren Sie die Upstream-Back-Ends im gemeinsam genutzten Speicher.
Das aktuelle Timer-Intervall des Health-Check-Moduls beträgt 5 Sekunden. Das Integritätsprüfungsintervall in der Richtlinie muss >=5 s betragen.

Hier ist ein Beispiel für die Konfiguration aktiver Integritätsprüfungen durch VS:

TLS-Terminierung/SNI

OpenNJet KIC verarbeitet den TLS-Verkehr auf dem internen Port 443, unterstützt die TLS-Terminierungs-/SNI-Funktionalität und wird basierend auf dem Hostnamen auf demselben Port gemultiplext.

Sowohl Ingress als auch VirtualServer CR unterstützen die TLS-Terminierung/SNI-Konfiguration und OpenNJet KIC unterstützt die dynamische Aktualisierung der Konfiguration ohne Neuladen. Diese Funktion profitiert von der dynamischen Kartenfunktion von OpenNJet. Die entsprechende Beziehung zwischen Host und Zertifikat wird über die dynamische Map-HTTP-Schnittstelle aktualisiert.

Hier ist ein Beispiel für die VS-Konfiguration von TLS:

Die obige Beispielkonfiguration geht davon aus, dass sie vstest.example.com mit a.test.com dem entsprechenden Zertifikat verknüpft ist.

Prometheus-Indikatorsammlung

Um die Geschäftsüberwachung der Benutzer zu erfüllen, bietet OpenNJet KIC derzeit die Sammlung von VTS-Indikatoren (Virtual Host Traffic Status) an. OpenNJet verwendet ein angepasstes VTS-Modul, um Upstream-bezogene Indikatoren zu sammeln.

Der OpenNJet-Prozess im OpenNJet KIC-Container zeichnet Upstream-bezogene Indikatorinformationen über das vts-Modul auf, und OpenNJet bietet eine HTTP-Schnittstelle zum Abrufen von Indikatorinformationen im Prometheus-Format.

Der KIC-Dienst deklariert den Sammelport und den Pfad der Prometheus-Indikatoren durch Anmerkungen. Die Konfiguration ist wie folgt:

apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/port: "12001"
    prometheus.io/scheme: http
    prometheus.io/scrape: "true"
    prometheus.io/path: "/stats"
  name: njet-ingress
  namespace: njet-ingress
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  - port: 443
    targetPort: 443
    protocol: TCP
    name: https
  selector:
    app: njet-ingress

Referenzlink

OpenNJet basierte zunächst auf dem Basiszweig von NGINX1.19 und entwickelte sich unabhängig davon. Es zeichnet sich durch hohe Leistung, Stabilität und einfache Erweiterung aus. Es löst auch die seit langem bestehenden Probleme von NGINX, wie z. B. Schwierigkeiten bei der dynamischen Konfiguration und die Auswirkungen auf Verwaltungsfunktionen Geschäft.

Offizielle Website des KIC-Benutzerhandbuchs

OpenNJet KIC v1.0 veröffentlicht! K8s Ingress Controller