OpenNJet KIC V2.0 veröffentlicht!

[Shenzhen] Yuanchuanghui: 17.26 Uhr, der Partysaal wartet auf Sie.“

NGINX entwickelt sich zu Cloud Native weiter, alles in OpenNJet

Überblick

OpenNJet KIC (Kubernetes 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, TCP/UDP, WebSocket usw.

Hauptmerkmale dieser Version:

Unterstützt die Sharding-Verarbeitung von Ingress/VS CR
Unterstützt die Integration mit ADC
Unterstützt HTTP-Header-Operationen
Unterstützt TCP-Proxy
Unterstützt Cross-Namespace
Unterstützt WebSocket-Proxy
Unterstützt UDP-Proxy
Unterstützt dynamisches NJet VS/Accesslog
Unterstützt die aktive TCP-Gesundheitsprüfung
Unterstützen Sie die dynamische Anpassung der Anzahl der Worker-Prozesse

Dieser Artikel bietet eine kurze Einführung in diese neuen Funktionen.

Das Architekturdiagramm sieht wie folgt aus:

Übersicht über neue Funktionen

Sharding-Verarbeitung Ingress/VS CR

Es gibt spezielle KICs für die Verarbeitung verschiedener Ingress-/VS-Ressourcen. Dies ist der KIC-Sharding-Mechanismus.

Verschiedene Ingress-/VS-Ressourcen werden durch ingressClass identifiziert. Ingress-Ressourcen können durch die Annotation kubernetes.io/ingress.class oder spec.ingressClassName identifiziert werden, und VS-Ressourcen können durch spec.ingressClassName identifiziert werden.

Beachten Sie, dass jeder KIC in diesem Sharding-Mechanismus als KIC-Typ bezeichnet wird und IngressClass eins zu eins entspricht. Wenn in einem k8s-Cluster mehrere Njet-KICs vorhanden sind, müssen mehrere IngressClass-Objekte erstellt werden. Jeder KIC-Typ kann mehrere Kopien haben (entsprechend mehreren Pods in der k8s-Architektur).

Der Sharding-Mechanismus bewirkt, dass jeder KIC über seine eigenen Ingress-/VS-Ressourcen verfügt, an denen er interessiert ist, und nicht über alle Ingress-/VS-Ressourcen im k8s-Cluster. Ziel ist es, das Problem zu lösen, dass ein einzelner KIC-Typ dem Druck einer vollständigen Konfiguration nicht standhalten kann.

Integrieren Sie mit ADC

Nach der Integration von KIC in ADC kann ADC als Front-End-LB von KIC dienen, den Client-Verkehr über ADC verwalten und letztendlich den Lastausgleich für KIC-Dienste durchführen. KIC hat die folgenden Funktionen erfüllt:

Registrierung von ADC-Domänennamen: KIC registriert bei ADC die Domänennamen von Diensten im von KIC verwalteten k8s-Cluster, z. B. Dienste, die über k8s-Ingress und vs CR verwaltet werden. Mit dieser Funktion können Clients Anfragen direkt über Domänennamen stellen (der DNS-Server des ADC muss als Standard-DNS-Server konfiguriert werden).
ADC SlbPool-Registrierung: KIC registriert den mit dem KIC-Dienst verbundenen Anwendungspool (nodeIP+nodePort) mit ADC. Diese Funktion ermöglicht ADC die Weiterleitung an den KIC-Dienst.
ADC VS-Registrierung: KIC registriert einen VS bei ADC und ordnet ihn dem im zweiten Schritt erstellten Anwendungspool zu. Diese Funktion ermöglicht dem Client den direkten Zugriff auf den VS, sodass ADC als Front-End-LB von KIC dienen kann.

Die VIP in ADC VS entspricht dem Domänennamen des von KIC verwalteten Dienstes.
Die VIP in ADC VS ist eine öffentliche Netzwerk-IP, auf die externe Clients direkt zugreifen können.

Gesamtstruktur

Szenendiagramm:

Diagramm der Interaktionsarchitektur:

Manipulation des HTTP-Headers

Der OpenNJet KIC-Header-Vorgang kann den Client-Anforderungsheader ändern und den Antwortheader des Proxy-Dienstes bearbeiten. Einschließlich benutzerdefinierter Header und Header, die in der HTTP-Spezifikation definiert sind.

TCP-Proxy

Der KIC TCP-Proxy kann Upstream-TCP-Dienste weiterleiten. Der TCP-Proxy bietet Lastausgleichsfunktionen. Der TCP-Proxy ist vollständig dynamisch implementiert und erfordert keinen Neuladevorgang durch OpenNJet.

Der Proxy-TCP-Dienst verfügt über einen eigenen Überwachungsport, desto mehr Ports müssen überwacht werden. Bei der herkömmlichen Nginx-Implementierung ist eine Neuladekonfiguration erforderlich. Um das Neuladeproblem zu lösen, verwenden wir die Portweiterleitung . Die Methode implementiert den Proxy des TCP-Dienstes. Das konkrete Design ist wie folgt:

Die OpenNJet-Stream-Konfiguration überwacht einen 12003-Port vorab (der vom Proxy-TCP-Dienst überwachte Port wird auf 12003 umgeleitet).
KIC generiert iptables-Regeln über die vom Kunden definierte API und leitet den angeforderten TCP-Dienst-Port über die iptables-Regeln an Port 12003 um.
Der „TCP-Service-Port“, auf den der OpenNJet-Stream über den Client zugreift, stimmt mit dem Upstream überein, der vom Kunden vorab über die API konfiguriert wurde. Dieser Prozess wird durch die Stream-Map abgeglichen.
Der OpenNJet-Stream sendet die Client-Anfrage an den Server im Upstream, der erfolgreich übereinstimmt (der Lastausgleich wird durch Stream-LUA implementiert).

iptables-Regeln und Karteninhaltsaktualisierungen werden mithilfe der API dynamisch aktualisiert, wodurch Neuladevorgänge vermieden werden.

Die OpenNJet-Konfiguration wird wie folgt implementiert:

 map $njtmesh_port \$stream_upstream {
 }
 
 server {
 listen 12003 mesh;
 set $proxy_upstream_name \$stream_upstream;
 proxy_pass upstream_balancer;
 }

Der vom Client angeforderte Port ist immer der Port des Listeners im TransportServer.
Der Port kann vom Proxy-Dienst nicht verwendet werden, da er intern von KIC verwendet wird. Die Beschreibung ist in der folgenden Tabelle beschrieben:

Hafen	veranschaulichen
80	HTTP-Proxy
443	https-Proxy
12001	OpenNJet-Steuerungsebene
12002	TCP Lua Upstream
12003	TCP-Proxy-Port
12004	UDP-Proxy-Port
8080	stub_status und http lua upstream
8081	KIC-Pod-Bereitschaftsport

Über Namensräume hinweg

Der integrierte Ingress von K8s kann nur das Routing von Diensten im selben NS verarbeiten und keine Cross-NS-Vorgänge ausführen. Die Funktion zur namensraumübergreifenden Konfiguration behebt diese Einschränkung.

Zusätzlich zur Unterstützung der Cross-Namespace-Konfiguration durch Ingress unterstützt VS auch die Cross-NS-Konfiguration. Benutzer können entsprechend ihren eigenen Umständen wählen.

Ingress implementiert diese Funktion über verschiedene Ingress-Typen. Ingress selbst hat kein Typkonzept. Wir drücken es aus, indem wir die Anmerkung „njet.org.cn/mergeable-ingress-type“ hinzufügen. Anmerkungen können Werte aus der folgenden Tabelle annehmen:

Wert	veranschaulichen	Anmerkung
Meister	Haupteingang	eins
Günstling	FromIngress	Kann mehrere sein und dem Master-Ingress über den Host zugeordnet sein

Der Master und der Minion desselben Hosts können sich im selben NS oder in unterschiedlichen NS befinden.

Zusätzlich zur Cross-NS-Konfiguration können Sie diese Funktion auswählen. Wenn ein Host über eine große Anzahl von Pfaden verfügt und die Wartung eines einzelnen Ingress kompliziert ist, können Sie diese Funktion auch zum Verwalten von Pfaden auswählen.

VS CR hat die gleiche Funktion wie Ingress, die Implementierungsmethode ist jedoch unterschiedlich, indem es auf eine Sub-Routing-Ressource verweist. Die Sub-Route ist eine Zeichenfolge im NS/Name-Format, die zur Darstellung von VSR verwendet wird VSR ist ein K8s CR, ein neuer CR, der für diese Funktion eingeführt wurde.

WebSocket-Proxy

WebSocket ist ein unabhängiges TCP-basiertes Anwendungsschichtprotokoll und ein Vollduplex-Kommunikationsprotokoll. Seine einzige Beziehung zu HTTP besteht darin, dass sein Handshake vom HTTP-Server als HTTP-Upgrade-Anfrage interpretiert wird. Wenn der Handshake endet, hat er nichts mit HTTP zu tun. Das Protokoll besteht aus zwei Teilen: Handshake und Datenübertragung. Die Handshake-Phase ist in der folgenden Abbildung dargestellt:

Ingress implementiert diese Funktion durch das Hinzufügen von Annotationen, die wir durch das Hinzufügen der Annotation „njet.org.cn/websocket-services“ ausdrücken.

Anmerkungsname	Wertformat	beschreiben
njet.org.cn/websocket-services	service,service2 (durch Kommas getrennte Dienstnamen)	Websocket-Unterstützung

VS erfordert keine Konfiguration.

UDP-Proxy

Der KIC UDP-Proxy kann Upstream-UDP-Dienste vertreten. Der UDP-Proxy bietet Lastausgleichsfunktionen. Der UDP-Proxy ist vollständig dynamisch implementiert und erfordert keinen Neuladevorgang durch OpenNJet.

Die Implementierung des UDP-Dienst-Proxys ist grundsätzlich dieselbe wie die des TCP-Dienst-Proxys, außer dass die OpenNJet-Stream-Konfiguration einen 12004-Port vorab abhört (der vom Proxy-UDP-Dienst überwachte Port wird auf 12004 umgeleitet), während TCP vorab abhört ein 12003-Port. Ausführliche Anweisungen finden Sie unter TCP-Proxy.

Die OpenNJet-Konfiguration wird wie folgt implementiert:

map $njtmesh_port \$stream_upstream_udp {
}

server {
listen 12004 udp mesh;
set $proxy_upstream_name $stream_upstream_udp;
proxy_pass upstream_balancer;
}

Dynamischer NJet VS

Im Vergleich zur ersten Version haben wir den Ansatz für einen einzelnen Server und mehrere Standorte geändert, um einen HTTP-Host-Header-Abgleich und einen Pfadabgleich zu erreichen. Wir haben den Nginx-Standardservername verwendet, um den Host-Header-Abgleich zu implementieren Die Konfiguration wurde dynamisch aktualisiert. Ja, es ist kein Neuladevorgang erforderlich. Die zweite Version fügt keine zusätzlichen Funktionen für Ingress und VirtualServer hinzu.

DynamicAccesslog

Mit der KIC-Accesslog-Funktion können Sie Accesslog-Richtlinien (einschließlich Switch-Status und Accesslog-Dateipfad) individuell auf eine bestimmte Anwendung anwenden. Globale Einstellungen können auch über njet-config ConfigMap vorgenommen werden, allerdings hat das „individuelle Anwenden der Accesslog-Richtlinie auf eine Anwendung“ eine höhere Priorität.

Proaktive TCP-Gesundheitsprüfung

Für Transportserver-Ressourcen wird die Konfiguration eines TCP-Ports unterstützt. Die aktive Integritätsprüfung erkennt, ob der TCP-Port gemäß dem konfigurierten Prüfintervall normal lauscht, und das Backend wird basierend auf den Prüfergebnissen online und offline sein.

apiVersion: k8s.njet.org/v1alpha1
 kind: TransportServer
 metadata:
 name: testapp-tcp
 spec:
 listener:
 name: test-tcp
 protocol: TCP
 upstreams:
 - name: testapp1
 service: testapp
 port: 80
 healthCheck:
 enable: true
 interval: 20s
 timeout: 5s
 fails: 1
 passes: 1
 port: 83
 action:
 pass: testapp1

Die Konfigurationsanweisungen lauten wie folgt:

Feld	beschreiben	Typ	Ist es erforderlich?
aktivieren	Ob die Integritätsprüfung aktiviert werden soll, Standardeinstellung ist „false“.	Boolescher Wert	NEIN
Intervall	Das Intervall zwischen den Prüfungen. Der Standardwert ist 5	Zeichenfolge	NEIN
scheitert	Nach einigen Fehlern gelten Sie als offline. Standard 1 Mal	ganze Zahl	NEIN
geht vorbei	Nach mehreren Erfolgen wird es online geprüft. Standard 1 Mal	ganze Zahl	NEIN
Hafen	Der Port, an dem sich der Gesundheitsprüfungsdienst befindet	ganze Zahl	NEIN
Auszeit	Zeitüberschreitung bei der Integritätsprüfung der Verbindung	Zeichenfolge	NEIN

Dynamische Anpassung der Worker-Prozessnummer

Unterstützt die Konfiguration der Anzahl der Arbeitsprozesse von njet-Instanzen über ConfigMap-Ressourcen. Nachdem die Konfigurationselemente in ConfigMap aktualisiert wurden, wird die Anzahl der Arbeitsprozesse dynamisch geändert.

Konfigurationselemente	veranschaulichen	Feldtyp	Standardwert	Anmerkung
Arbeitsprozesse	Anzahl der Worker-Prozesse (erlaubte Werte 1 – 512)	Zeichenfolge	Der Standardwert ist die Anzahl der automatisch generierten Prozesse basierend auf der Anzahl der CPU-Kerne.

Referenzlink

OpenNJetKIC-Benutzerhandbuch

OpenNJet KIC-Quellcodeadresse

Die NJet -Anwendungs-Engine erreicht durch Kernel-Rekonstruktion einzigartige Funktionen zum dynamischen Laden von Konfigurationen zur Laufzeit und ist eine neue Generation leistungsstarker Web-Anwendungs-Engines . NJet verfügt über leistungsstarke Datenebenenverarbeitungsfunktionen und plant mehrere Hilfsfunktionen wie Clustering, Hochverfügbarkeit, aktive Zustandsprüfungen und deklarative APIs über das einzigartige Co-Pilot-Service-Framework von NJet, um Funktionserweiterungen zu erleichtern und fällige Verwaltungs-/Kontrollfunktionspaare zu isolieren Aufgrund der Auswirkungen auf die Datenebene ist die Leistung der NJet-Anwendungs-Engine dreimal so hoch wie die der von CNCF empfohlenen Envoy-Anwendungs-Engine. Offizielle Website der Mail-Gruppe