OpenNJet KIC V2.0 est disponible !

[Shenzhen] Yuanchuanghui : 17h26, la salle des fêtes vous attend.

NGINX évolue vers le cloud natif, tout dans OpenNJet

Aperçu

OpenNJet KIC (Kubernetes Ingress Controller) est basé sur les caractéristiques dynamiques et la mise en œuvre hautes performances du proxy OpenNJet. Compensez les lacunes de nginx dans les scénarios cloud natifs. Fournit de riches fonctionnalités de gestion du trafic, telles que l'emplacement dynamique, le routage hôte/chemin, l'équilibrage de charge, l'amont dynamique, la publication Canary, la terminaison TLS/SNI, TCP/UDP, WebSocket, etc.

Principales caractéristiques de cette version :

Prend en charge le traitement de partitionnement Ingress/VS CR
Prise en charge de l'intégration avec ADC
Prise en charge des opérations d'en-tête HTTP
Prise en charge du proxy TCP
Prise en charge des espaces de noms croisés
Prise en charge du proxy WebSocket
Prise en charge du proxy UDP
Prise en charge dynamique NJet VS/Accesslog
Prise en charge du contrôle de santé actif TCP
Prise en charge de l'ajustement dynamique du nombre de processus de travail

Cet article fournit une brève introduction à ces nouvelles fonctionnalités.

Le schéma d'architecture est le suivant :

Aperçu des nouvelles fonctionnalités

Traitement du partage Ingress/VS CR

Il existe des KIC spéciaux pour traiter différentes ressources Ingress/VS. Il s'agit du mécanisme de partitionnement KIC.

Différentes ressources Ingress/VS sont identifiées par ingressClass. Les ressources Ingress peuvent être identifiées par l'annotation kubernetes.io/ingress.class ou spec.ingressClassName, et les ressources VS peuvent être identifiées par spec.ingressClassName.

Notez que chaque KIC dans ce mécanisme de partitionnement est appelé un type de KIC et correspond à IngressClass un à un. Dans un cluster k8s, s'il existe plusieurs KIC Njet, plusieurs objets IngressClass doivent être créés. Chaque type de KIC peut avoir plusieurs copies (correspondant à plusieurs pods dans l'architecture k8s).

Le mécanisme de partitionnement fait que chaque KIC dispose de ses propres ressources Ingress/VS qui l'intéressent, plutôt que de toutes les ressources Ingress/VS du cluster k8s. Il vise à résoudre le problème selon lequel un seul type de KIC ne peut pas résister à la pression d’une configuration complète.

Intégrer avec ADC

Une fois KIC intégré à ADC, ADC peut servir de LB frontal de KIC, gérant le trafic client via ADC et, finalement, équilibrant la charge vers les services KIC. KIC a rempli les fonctions suivantes :

Enregistrement du nom de domaine ADC : KIC enregistre auprès de l'ADC les noms de domaine des services du cluster k8s gérés par KIC, tels que les services gérés via l'entrée k8s et vs CR. Cette fonction permet aux clients d'effectuer des requêtes directement via des noms de domaine (le serveur DNS de l'ADC doit être configuré comme serveur DNS par défaut).
Enregistrement ADC SlbPool : KIC enregistre le pool d'applications (nodeIP+nodePort) associé au service KIC auprès de l'ADC. Cette fonction permet à l'ADC d'acheminer vers le service KIC.
Enregistrement ADC VS : KIC enregistre un VS avec ADC et l'associe au pool d'applications créé lors de la deuxième étape. Cette fonction permet au client d'accéder directement au VS, afin qu'ADC puisse servir de LB frontal de KIC.

Le VIP dans ADC VS correspond au nom de domaine du service géré par KIC.
Le VIP dans ADC VS est une adresse IP de réseau public, directement accessible aux clients externes.

Structure globale

Graphique de scène :

Schéma d'architecture d'interaction :

Manipulation de l'en-tête HTTP

L'opération d'en-tête OpenNJet KIC peut modifier l'en-tête de demande du client et opérer sur l'en-tête de réponse du service mandaté. Y compris les en-têtes définis par l'utilisateur et les en-têtes définis dans la spécification HTTP.

mandataire TCP

Le proxy TCP KIC peut proxy les services TCP en amont. Le proxy TCP fournit des capacités d'équilibrage de charge. Le proxy TCP est implémenté de manière entièrement dynamique et ne nécessite pas qu'OpenNJet effectue une opération de rechargement.

Le service TCP proxy aura son propre port d'écoute. Plus il y a de services proxy, plus il y a de ports à écouter. Dans l'implémentation traditionnelle de Nginx, chaque nouvelle écoute nécessite une configuration de rechargement. Afin de résoudre le problème de rechargement, nous utilisons la redirection de port. . La méthode implémente le proxy du service TCP. La conception spécifique est la suivante :

La configuration du flux OpenNJet pré-écoute un port 12003 (le port surveillé par le service proxy TCP sera redirigé vers 12003).
KIC génère des règles iptables via l'API définie par le client et redirige le port de service TCP demandé vers le port 12003 via les règles iptables.
Le « port de service TCP » auquel le flux OpenNJet accède via le client correspond à celui configuré en amont par le client à l'avance via l'API. Ce processus est mis en correspondance via la carte de flux.
Le flux OpenNJet envoie la demande du client au serveur en amont qui correspond avec succès (l'équilibrage de charge est implémenté par le flux lua).

Les règles iptables et les mises à jour du contenu de la carte sont mises à jour dynamiquement à l'aide de l'API, évitant ainsi les opérations de rechargement.

La configuration d'OpenNJet est implémentée comme suit :

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

Le port demandé par le client est toujours le port de l'écouteur dans TransportServer.
Le port ne peut pas être utilisé par le service proxy car il sera utilisé en interne par KIC. La description est décrite dans le tableau suivant :

port	illustrer
80	http proxy
443	proxy https
12001	Plan de contrôle OpenNJet
12002	TCP Lua en amont
12003	Port proxy TCP
12004	Port proxy UDP
8080	stub_status et http lua en amont
8081	Port de préparation du pod KIC

À travers les espaces de noms

L'entrée intégrée des K8 ne peut gérer que le routage des services dans le même ns et ne peut pas effectuer d'opérations entre ns. La fonctionnalité de configuration entre espaces de noms résout cette limitation.

En plus d'Ingress prenant en charge la configuration entre espaces de noms, VS prend également en charge la configuration entre ns. Les utilisateurs peuvent choisir en fonction de leurs propres circonstances.

Ingress implémente cette fonction à travers différents types Ingress. Ingress lui-même n'a aucune notion de type. Nous l'exprimons en ajoutant l'annotation "njet.org.cn/mergeable-ingress-type". Les annotations peuvent prendre les valeurs du tableau suivant :

valeur	illustrer	Remarque
maître	Entrée principale	un
serviteur	DepuisEntrée	Peut être multiple, associé à l'entrée principale via l'hôte

Le maître et le serviteur du même hôte peuvent être dans le même ns ou dans des ns différents.

En plus de la configuration cross-ns, vous pouvez choisir cette fonction Lorsqu'un hôte dispose d'un grand nombre de chemins et que la maintenance d'une seule Ingress est compliquée, vous pouvez également choisir cette fonction pour gérer les chemins.

VS CR a la même fonction qu'Ingress, mais la méthode d'implémentation est différente. VS CR effectue une configuration cross-ns en référençant une ressource de sous-routage. La sous-route est une chaîne au format ns/name, qui est utilisée pour représenter VSR. ressources VSR est un K8s CR, un nouveau CR introduit pour cette fonctionnalité.

Proxy WebSocket

WebSocket est un protocole de couche application indépendant basé sur TCP et un protocole de communication full-duplex. Sa seule relation avec HTTP est que sa prise de contact est interprétée par le serveur HTTP comme une demande de mise à niveau HTTP. Lorsque la prise de contact se termine, cela n'a rien à voir avec HTTP. Le protocole comporte deux parties : la prise de contact et le transfert de données. La phase de prise de contact est illustrée dans la figure ci-dessous :

Ingress implémente cette fonction en ajoutant des annotations, que nous exprimons en ajoutant l'annotation "njet.org.cn/websocket-services".

Nom de l'annotation	format de valeur	décrire
njet.org.cn/websocket-services	service,service2 (noms de services séparés par des virgules)	Prise en charge des Websockets

VS ne nécessite aucune configuration.

proxy UDP

Le proxy KIC UDP peut proxy les services UDP en amont. Le proxy UDP fournit des capacités d'équilibrage de charge. Le proxy UDP est implémenté de manière entièrement dynamique et ne nécessite pas qu'OpenNJet effectue une opération de rechargement.

L'implémentation du proxy de service UDP est fondamentalement la même que celle du proxy de service TCP, sauf que la configuration du flux OpenNJet pré-écoute un port 12004 (le port surveillé par le service proxy UDP sera redirigé vers 12004), tandis que TCP pré-écoute un port 12003. Pour des instructions détaillées, reportez-vous à Proxy TCP.

La configuration d'OpenNJet est implémentée comme suit :

map $njtmesh_port \$stream_upstream_udp {
}

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

VS NJet dynamique

Par rapport à la première version, nous avons modifié l'approche à serveur unique et à emplacements multiples pour obtenir une correspondance d'en-tête d'hôte HTTP et une correspondance de chemin avec l'approche à serveurs multiples et à emplacements multiples. Nous avons utilisé le nom de serveur standard nginx pour implémenter la correspondance d'en-tête d'hôte, mais. Mise à jour dynamique de la configuration Oui, aucune opération de rechargement n'est requise. La deuxième version n'ajoute pas de fonctionnalités supplémentaires pour Ingress et VirtualServer.

Journal d'accès dynamique

La fonction KIC Accesslog vous permet d'appliquer les politiques de journal d'accès (y compris l'état du commutateur et le chemin du fichier journal d'accès) individuellement à une application donnée. Les paramètres globaux peuvent également être définis via njet-config ConfigMap, mais « l'application de la stratégie de journal d'accès individuellement à une application » a une priorité plus élevée.

Bilan de santé proactif TCP

Pour les ressources du serveur de transport, il est pris en charge pour configurer un port TCP. La vérification de l'état active détectera si le port TCP écoute normalement selon l'intervalle de vérification configuré, et le backend sera en ligne et hors ligne en fonction des résultats de la vérification.

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

Les instructions de configuration sont les suivantes :

Champ	décrire	taper	Est-ce obligatoire ?
activer	S'il faut activer la vérification de l'état, par défaut false	booléen	Non
intervalle	L'intervalle entre les contrôles. La valeur par défaut est 5	chaîne	Non
échoue	Après quelques échecs, vous serez considéré comme hors ligne. Par défaut 1 fois	entier	Non
passe	Il sera envisagé en ligne après plusieurs succès. Par défaut 1 fois	entier	Non
port	Le port où se trouve le service de contrôle sanitaire	entier	Non
temps mort	Expiration du délai de connexion pour le contrôle de santé	chaîne	Non

Ajustement dynamique du numéro de processus de travail

Prend en charge la configuration du nombre de processus de travail des instances njet via les ressources ConfigMap. Une fois les éléments de configuration dans ConfigMap mis à jour, le nombre de processus de travail sera modifié dynamiquement.

Éléments de configuration	illustrer	Type de champ	valeur par défaut	Remarque
processus de travail	Nombre de processus Worker (valeurs autorisées 1 à 512)	Chaîne	La valeur par défaut est le nombre de processus générés automatiquement par auto en fonction du nombre de cœurs de processeur.

Lien de référence

Manuel d'utilisation d'OpenNJetKIC

Adresse du code source OpenNJet KIC

Le moteur d'application NJet offre des capacités uniques de chargement de configuration dynamique d'exécution grâce à la reconstruction du noyau et constitue une nouvelle génération de moteur d'application Web hautes performances . NJet dispose de capacités de traitement de plan de données hautes performances et planifie plusieurs fonctions auxiliaires telles que le clustering, la haute disponibilité, les contrôles de santé actifs et les API déclaratives via le cadre de service copilote unique CoPilot de NJet pour faciliter l'expansion des fonctions et isoler les paires de fonctions de gestion/contrôle dues. Compte tenu de l'impact sur le plan des données, les performances du moteur d'application NJet dépassent trois fois celles du moteur d'application Envoy recommandé par la CNCF. Site officiel du groupe de messagerie