Annonce de NGINX Plus R16

[ngx_snippet name='table-style-blog']
Nous sommes heureux d'annoncer que NGINX Plus Release 16 (R16) est désormais disponible. La sortie d’aujourd’hui est l’une des plus importantes pour faire progresser la vision technique de NGINX. Avec R16, NGINX Plus fonctionne désormais comme un niveau d’entrée et de sortie unique et élastique pour toutes vos applications. Cela signifie que vous pouvez consolider les fonctionnalités d'un équilibreur de charge, d'une passerelle API et d'un WAF dans un seul progiciel qui couvre n'importe quel cloud.

De nombreuses entreprises avec lesquelles nous parlons aujourd’hui possèdent chacun de ces composants, mais souvent de fournisseurs différents. Cela augmente les coûts et la complexité car les équipes opérationnelles doivent gérer chaque solution ponctuelle séparément. Cela réduit également les performances et la fiabilité, car chaque saut supplémentaire ajoute une latence supplémentaire et des points de défaillance.

Avec les nouvelles fonctionnalités de NGINX Plus R16, vous pouvez commencer à consolider et à simplifier votre infrastructure, en évoluant vers l'architecture d'une couche d'entrée/sortie élastique pour les applications héritées et modernes. NGINX Plus R16 inclut de nouvelles fonctionnalités de clustering, un équilibrage de charge UDP amélioré et une atténuation DDoS qui en font un remplacement plus complet du matériel coûteux F5 BIG-IP et d'autres infrastructures d'équilibrage de charge. La nouvelle prise en charge de la limitation de débit globale fait de NGINX Plus une alternative légère à de nombreuses solutions de passerelle API. Enfin, la nouvelle prise en charge de l'équilibrage de charge aléatoire avec deux choix fait de NGINX Plus le choix idéal pour équilibrer la charge du trafic des microservices dans des environnements évolutifs ou distribués, tels que Kubernetes.

Résumé des nouvelles fonctionnalités de NGINX Plus R16

Les nouvelles fonctionnalités de NGINX Plus R16 incluent :

• Limitation de débit prenant en compte le cluster – Dans NGINX Plus R15, nous avons introduit le module de partage d’état , permettant de synchroniser les données sur un cluster NGINX Plus. Dans cette version, le partage d'état est étendu à la fonctionnalité de limitation de débit , vous permettant de spécifier des limites de débit globales sur un cluster NGINX Plus. La limitation du débit global est une fonctionnalité importante pour les passerelles API et constitue un cas d'utilisation extrêmement populaire pour NGINX Plus.
• Magasin de clés-valeurs prenant en charge les clusters – Dans NGINX Plus R13, nous avons introduit un magasin de clés-valeurs qui peut être utilisé, par exemple, pour créer une liste de refus d'adresses IP dynamiques ou gérer les redirections HTTP . Dans cette version, le magasin clé-valeur peut désormais être synchronisé sur un cluster et inclut un nouveau paramètre de délai d'expiration , afin que les paires clé-valeur individuelles puissent être automatiquement supprimées. Avec la nouvelle prise en charge de la synchronisation, le magasin clé-valeur peut désormais être utilisé pour fournir une atténuation DDoS dynamique , distribuer des jetons de session authentifiés ou créer un cache de contenu distribué (CDN).
• Équilibrage de charge aléatoire avec deux choix – Lors du clustering d’équilibreurs de charge, il est important d’utiliser un algorithme d’équilibrage de charge qui ne surcharge pas par inadvertance les serveurs principaux individuels. L'équilibrage de charge aléatoire avec deux choix est extrêmement efficace pour les clusters mis à l'échelle et sera la méthode par défaut dans la prochaine version de NGINX Ingress Controller pour Kubernetes.
• Équilibrage de charge UDP amélioré – Dans NGINX Plus R9, nous avons introduit pour la première fois l’équilibrage de charge UDP. Cette implémentation initiale était limitée aux applications UDP qui attendent un seul paquet UDP du client pour chaque interaction avec le serveur (comme DNS et RADIUS). NGINX Plus R16 peut gérer plusieurs paquets UDP du client, ce qui nous permet de prendre en charge des protocoles UDP plus complexes tels que OpenVPN, la voix sur IP (VoIP) et l'infrastructure de bureau virtuel (VDI).
• Prise en charge d'AWS PrivateLink – AWS PrivateLink est la technologie d'Amazon permettant de créer des tunnels VPN sécurisés dans un cloud privé virtuel. Avec cette version, vous pouvez désormais authentifier, acheminer, équilibrer la charge du trafic et optimiser la circulation du trafic au sein d'un centre de données AWS PrivateLink. Cette fonctionnalité s'appuie sur le nouveau support du protocole PROXY v2 .

Les améliorations supplémentaires incluent la prise en charge des jetons de session opaques OpenID Connect, le module dynamique de session cryptée, les mises à jour du module JavaScript NGINX et bien plus encore. NGINX Plus R16 est basé sur NGINX Open Source 1.15.2 et inclut toutes les fonctionnalités de la version open source.

Au cours du développement de NGINX Plus R16 , nous avons également ajouté un certain nombre d' améliorations significatives au contrôleur d'entrée officiel NGINX pour Kubernetes, un cas d'utilisation important pour NGINX Plus.

Apprenez-en plus sur NGINX Plus R16 et tout ce qui concerne NGINX à NGINX Conf 2018 . Nous aurons des sessions dédiées, des démonstrations et des experts à votre disposition pour approfondir toutes les nouvelles fonctionnalités.

Changements importants dans le comportement

• Les API Upstream Conf et Status, remplacées et obsolètes par l' API NGINX Plus unifiée, ont été supprimées. En août 2017, NGINX Plus R13 a introduit la toute nouvelle API NGINX Plus pour la reconfiguration dynamique des groupes en amont et des mesures de surveillance, remplaçant les API Upstream Conf et Status qui implémentaient auparavant ces fonctions. Comme annoncé à l'époque , les API obsolètes ont continué à être disponibles et prises en charge pendant une période significative, qui est désormais terminée. Si votre configuration inclut les directives upstream_conf et/ou status , vous devez les remplacer par la directive api dans le cadre de la mise à niveau vers R16.

  Pour obtenir des conseils et de l'aide sur la migration vers la nouvelle API NGINX Plus , veuillez consulter le guide de transition sur notre blog ou contacter notre équipe d'assistance.

• Arrêt du support pour les versions de système d’exploitation en fin de vie : NGINX Plus n’est plus pris en charge sur Ubuntu 17.10 (Artful) , FreeBSD 10.3 ou FreeBSD 11.0.

  Pour plus d'informations sur les plates-formes prises en charge, consultez les spécifications techniques de NGINX Plus et des modules dynamiques .

• Le plug-in NGINX New Relic a été mis à jour pour utiliser la nouvelle API NGINX Plus et est désormais un projet open source. Le plug-in mis à jour fonctionne avec toutes les versions de NGINX Plus à partir de R13, mais n'est plus pris en charge ni maintenu par NGINX, Inc.

Nouvelles fonctionnalités en détail

Limitation de débit tenant compte des clusters

NGINX Plus R15 a introduit le module zone_sync qui permet de partager l'état d'exécution entre tous les nœuds NGINX Plus d'un cluster.

La première fonctionnalité synchronisée était la persistance des sessions sticky-learn . NGINX Plus R16 étend le partage d'état à la fonction de limitation de débit . Lorsqu'il est déployé dans un cluster, NGINX Plus peut désormais appliquer une limite de débit cohérente aux requêtes entrantes, quel que soit le nœud membre du cluster auquel la requête arrive. Communément appelée limitation de débit globale , l'application d'une limite de débit cohérente sur un cluster est particulièrement pertinente pour les cas d'utilisation de passerelle API, fournissant des API selon un accord de niveau de service (SLA) qui empêche les clients de dépasser une limite de débit spécifiée.

Le partage d'état NGINX Plus ne nécessite ni n'utilise de nœud principal : tous les nœuds sont homologues et échangent des données dans une topologie en maillage complet. Un cluster de partage d’état NGINX Plus doit répondre à trois exigences :

• Connectivité réseau entre tous les nœuds du cluster
• Horloges synchronisées
• Configuration sur chaque nœud qui active le module zone_sync , comme dans l'extrait suivant.

flux { résolveur 10.0.0.53 valide=20s; serveur { écoute 10.0.0.1:9000; zone_sync ; zone_sync_server nginx-cluster.example.com:9000 résoudre; } }

La directive zone_sync permet la synchronisation des zones de mémoire partagée dans un cluster. La directive zone_sync_server identifie les autres instances NGINX Plus dans le cluster. NGINX Plus prend en charge la découverte de services DNS afin que les nœuds de cluster puissent être identifiés par nom d'hôte, rendant la configuration identique sur tous les nœuds. Notez qu'il s'agit d'une configuration minimale, sans les contrôles de sécurité nécessaires au déploiement en production. Pour plus de détails, consultez l' annonce NGINX Plus R15 et la documentation de référence du module zone_sync .

Une fois cette configuration en place sur tous les nœuds, les limites de débit peuvent être appliquées à un cluster simplement en ajoutant le nouveau paramètre de synchronisation à la directive limit_req_zone . Avec la configuration suivante, NGINX Plus impose une limite de débit de 100 requêtes par seconde à chaque client, en fonction de l'adresse IP du client.

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync ; # Serveur compatible cluster { listen 80; location / { limit_req zone=per_ip; # Appliquer la limite de débit ici proxy_pass http://my_backend; } }

De plus, la solution de clustering de partage d’état est indépendante de la solution de haute disponibilité basée sur Keepalived pour la résilience du réseau. Par conséquent, contrairement à cette solution, un cluster de partage d’état peut s’étendre sur plusieurs emplacements physiques.

Magasin de clés-valeurs prenant en compte les clusters

NGINX Plus R13 a introduit un magasin clé-valeur léger en mémoire en tant que module NGINX natif. Ce module est fourni avec NGINX Plus, permettant de configurer des solutions nécessitant un stockage de base de données simple sans installer de composants logiciels supplémentaires. De plus, le magasin clé-valeur est contrôlé via l' API NGINX Plus afin que les entrées puissent être créées, modifiées et supprimées via une interface REST.

Les cas d’utilisation du magasin clé-valeur NGINX Plus incluent la liste de refus d’adresses IP dynamiques , la limitation dynamique de la bande passante et la mise en cache des jetons d’authentification .

Avec NGINX Plus R16, le magasin clé-valeur est désormais compatible avec les clusters afin que les entrées soient synchronisées sur tous les nœuds d'un cluster. Cela signifie que les solutions utilisant le magasin clé-valeur NGINX Plus peuvent être déployées dans tous les types d’environnements en cluster : actifs-passifs, actifs-actifs et également largement distribués.

En ce qui concerne les autres fonctionnalités prenant en charge les clusters, vous configurez la synchronisation du magasin clé-valeur en ajoutant simplement le paramètre sync à la directive keyval_zone pour un cluster qui a déjà été configuré pour le partage d’état (avec les directives zone_sync et zone_sync_server ).

Le magasin clé-valeur a également été étendu avec la possibilité de définir une valeur de délai d'expiration pour chaque paire clé-valeur ajoutée au magasin clé-valeur. Ces entrées expirent automatiquement et sont supprimées du magasin de clés-valeurs lorsque le délai d’expiration spécifié s’écoule. Le paramètre timeout est obligatoire lors de la configuration d’un magasin clé-valeur synchronisé.

Utilisation du magasin de clés-valeurs NGINX Plus pour la protection DDoS dynamique

Vous pouvez combiner les nouvelles fonctionnalités de clustering de NGINX Plus pour créer une solution sophistiquée de protection contre les attaques DDoS. Lorsqu'un pool d'instances NGINX Plus est déployé dans un cluster actif-actif ou distribué sur un réseau étendu, le trafic malveillant peut arriver sur n'importe laquelle de ces instances. Cette solution utilise une limite de débit synchronisée et un magasin clé-valeur synchronisé pour répondre dynamiquement aux attaques DDoS et atténuer leur effet, comme suit.

• Une limite de débit prenant en compte le cluster intercepte les clients qui envoient plus de 100 requêtes par seconde, quel que soit le nœud NGINX Plus qui reçoit la requête.
• Lorsqu'un client dépasse la limite de débit, son adresse IP est ajoutée à un magasin de clés-valeurs « sin bin » en effectuant un appel à l' API NGINX Plus . Le sin bin est synchronisé sur l'ensemble du cluster.
• Les demandes supplémentaires des clients dans la corbeille sont soumises à une limite de bande passante très faible, quel que soit le nœud NGINX Plus qui les reçoit. Il est préférable de limiter la bande passante plutôt que de rejeter purement et simplement les demandes, car cela ne signale pas clairement au client que l’atténuation DDoS est en vigueur.
• Après dix minutes, le client est automatiquement retiré de la corbeille de péchés.

La configuration suivante montre une implémentation simplifiée de cette solution d’atténuation DDoS dynamique.

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync; # Limite de débit sensible au clusterlimit_req_status 429;

keyval_zone zone=sinbin:1M timeout=600 sync; # "sin bin" sensible au cluster avec 
# TTL de 10 minutes
keyval $remote_addr $in_sinbin zone=sinbin; # Remplissez $in_sinbin avec 
# adresses IP client correspondantes

serveur {
écoute 80;
emplacement / {
si ($in_sinbin) {
définir $limit_rate 50; # Limiter la bande passante des mauvais clients
}

limit_req zone=per_ip; # Appliquer la limite de débit ici
error_page 429 = @send_to_sinbin; # Les clients excédentaires sont déplacés vers 
# cet emplacement
proxy_pass http://my_backend;
}

location @send_to_sinbin {
rewrite ^ /api/3/http/keyvals/sinbin break; # Définir l'URI de la
# clé-valeur "sin bin"
proxy_method POST;
proxy_set_body '{"$remote_addr":"1"}';
proxy_pass http://127.0.0.1:80;
}

location /api/ {
api write=on;
# directives pour contrôler l'accès à l'API
}
}

Aléatoire avec deux choix d'équilibrage de charge

Il est de plus en plus courant que les environnements de distribution d’applications et d’API utilisent un niveau d’équilibrage de charge évolutif ou distribué pour recevoir les demandes des clients et les transmettre à un environnement d’application partagé. Lorsque plusieurs équilibreurs de charge transmettent des requêtes au même ensemble de serveurs principaux, il est important d’utiliser une méthode d’équilibrage de charge qui ne surcharge pas par inadvertance les serveurs principaux individuels.

Les clusters NGINX Plus déployés dans une configuration active-active ou dans des environnements distribués avec plusieurs points d'entrée sont des scénarios courants qui peuvent remettre en cause les méthodes d'équilibrage de charge traditionnelles, car chaque équilibreur de charge ne peut pas avoir une connaissance complète de toutes les demandes envoyées aux serveurs principaux.

L’équilibrage de charge au sein d’un cluster conteneurisé présente les mêmes caractéristiques qu’un déploiement actif-actif évolutif. Les contrôleurs Kubernetes Ingress déployés dans un ensemble de réplicas avec plusieurs instances de la ressource Ingress sont également confrontés au défi de savoir comment répartir efficacement la charge sur les pods fournissant chacun des services du cluster.

La variance de la charge de travail a un impact énorme sur l’efficacité de l’équilibrage de charge distribué. Lorsque chaque requête impose la même charge sur le serveur principal, mesurer la rapidité avec laquelle chaque serveur a répondu aux requêtes précédentes est un moyen efficace de décider où envoyer la requête suivante. La méthode d'équilibrage de charge Least Time , exclusive à NGINX Plus, fait exactement cela. Mais lorsque la charge sur le serveur backend est variable (parce qu’elle inclut à la fois des opérations de lecture et d’écriture, par exemple), les performances passées sont un mauvais indicateur des performances futures.

Le moyen le plus simple d’équilibrer la charge dans un environnement distribué est de choisir un serveur back-end au hasard. Au fil du temps, la charge s’équilibre, mais il s’agit d’une approche grossière susceptible d’envoyer des pics de trafic vers des serveurs individuels de temps à autre.

Une variante simple de l'équilibrage de charge aléatoire, mais dont il est prouvé qu'elle améliore la répartition de la charge, consiste à sélectionner deux serveurs back-end au hasard, puis à envoyer la requête à celui qui a la charge la plus faible. L’objectif de la comparaison de deux choix aléatoires est d’éviter de prendre une mauvaise décision d’équilibrage de charge, même si la décision prise n’est pas optimale. En évitant le serveur backend avec la charge la plus importante, chaque équilibreur de charge peut fonctionner indépendamment tout en évitant d'envoyer des pics de trafic aux serveurs backend individuels. Par conséquent, cette méthode présente les avantages et l’efficacité de calcul de l’équilibrage de charge aléatoire, mais avec une répartition de charge manifestement meilleure.

NGINX Plus R16 introduit deux nouvelles méthodes d’équilibrage de charge, aléatoire et aléatoire avec deux choix. Pour ce dernier, vous pouvez spécifier en outre quelle métrique d’indication de charge NGINX Plus compare pour décider lequel des deux backends sélectionnés reçoit la demande. Le tableau suivant répertorie les mesures disponibles.

* Toutes les mesures temporelles sont exclusives à NGINX Plus

L'extrait suivant montre un exemple simple de configuration d'équilibrage de charge aléatoire avec deux choix avec la directive 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; # Choisissez le temps de réponse le plus rapide parmi deux choix aléatoires } server { listen 80; location / { proxy_pass http://my_backend; # Équilibrage de charge vers le groupe en amont } }

Notez que la méthode Aléatoire avec deux choix convient uniquement aux environnements distribués dans lesquels plusieurs équilibreurs de charge transmettent des requêtes au même ensemble de backends. Ne l’utilisez pas lorsque NGINX Plus est déployé sur un seul hôte ou dans un déploiement actif-passif. Dans ces cas, l'équilibreur de charge unique dispose d'une vue complète de toutes les demandes, et les méthodes Round Robin, Least Connections et Least Time donnent les meilleurs résultats.

Équilibrage de charge UDP amélioré

NGINX Plus R9 a introduit la prise en charge du proxy et de l'équilibrage de charge du trafic UDP , permettant à NGINX Plus de se placer devant les applications UDP populaires telles que DNS, Syslog, NTP et RADIUS pour fournir une haute disponibilité et une évolutivité des serveurs d'applications. L’implémentation initiale était limitée aux applications UDP qui attendent un seul paquet UDP du client pour chaque interaction avec le serveur.

Avec NGINX Plus R16 , plusieurs paquets entrants sont pris en charge, ce qui signifie que des applications UDP plus complexes peuvent être proxy et équilibrées en charge. Il s’agit notamment d’OpenVPN, de VoIP, de solutions de bureau virtuel et de sessions Datagram Transport Layer Security (DTLS). De plus, la gestion par NGINX Plus de toutes les applications UDP, simples ou complexes, est également nettement plus rapide.

NGINX Plus est le seul équilibreur de charge logiciel qui équilibre la charge de quatre des protocoles Web les plus populaires – UDP, TCP, HTTP et HTTP/2 – sur la même instance et en même temps.

Prise en charge du protocole PROXY v2

NGINX Plus R16 ajoute la prise en charge de l' en-tête du protocole PROXY v2 (PPv2) et la possibilité d'inspecter les valeurs type-longueur-valeur (TLV) personnalisées dans l'en-tête.

Le protocole PROXY est utilisé par les proxys de couche 7 tels que NGINX Plus et les équilibreurs de charge d'Amazon pour transmettre des informations de connexion aux serveurs en amont situés derrière un autre ensemble de proxys de couche 7 ou de périphériques NAT. Cela est nécessaire car certaines informations de connexion, telles que l'adresse IP source et le port, peuvent être perdues lorsque les proxys relaient les connexions, et il n'est pas toujours possible de compter sur l'injection d'en-tête HTTP pour transmettre ces informations. Les versions précédentes de NGINX Plus prenaient en charge l'en-tête PPv1 ; NGINX Plus R16 ajoute la prise en charge de l'en-tête PPv2.

Utilisation de PPv2 avec Amazon Network Load Balancer

Un cas d'utilisation de l'en-tête PPv2 concerne les connexions relayées par l'équilibreur de charge réseau (NLB) d'Amazon, qui peuvent sembler provenir d'une adresse IP privée sur l'équilibreur de charge. NLB préfixe chaque connexion avec un en-tête PPv2 qui identifie la véritable adresse IP source et le port de la connexion du client. La véritable source peut être obtenue à partir de la variable $proxy_protocol_addr , et vous pouvez utiliser le module realip pour écraser les variables source internes de NGINX avec les valeurs de l'en-tête PPv2.

Utilisation de PPv2 avec AWS PrivateLink

AWS PrivateLink est la technologie d'Amazon permettant de créer des tunnels VPN sécurisés dans un cloud privé virtuel (VPC). Il est couramment utilisé pour publier un service fournisseur (exécuté dans le VPC fournisseur) et le rendre disponible à un ou plusieurs VPC clients. Les connexions au service fournisseur proviennent d’un NLB exécuté dans le VPC fournisseur.

Dans de nombreux cas, le service fournisseur doit savoir d'où provient chaque connexion, mais l'adresse IP source dans l'en-tête PPv2 n'a pratiquement aucune signification, correspondant à une adresse interne non routable dans le VPC client. AWS PrivateLink NLB ajoute l' ID VPC source à l'en-tête à l'aide de l'enregistrement TLV PPv2 0xEA .

NGINX Plus peut inspecter les enregistrements PPv2 TLV et extraire l'ID VPC source pour les connexions AWS PrivateLink à l'aide de la variable $proxy_protocol_tlv_0xEA . Cela permet d'authentifier, d'acheminer et de contrôler le trafic dans un centre de données AWS PrivateLink.

Autres nouvelles fonctionnalités de NGINX Plus R16

Jetons de session opaques OpenID Connect

L' implémentation de référence NGINX Plus OpenID Connect a été étendue pour prendre en charge les jetons de session opaques. Dans ce cas d’utilisation, le jeton d’identité JWT n’est pas envoyé au client. Au lieu de cela, il est stocké dans le magasin de clés-valeurs NGINX Plus et une chaîne aléatoire est envoyée à sa place. Lorsque le client présente la chaîne aléatoire, elle est échangée contre le JWT et validée. Ce cas d’utilisation a été mis à niveau du prototype/de l’expérimental au niveau de production, maintenant que les entrées dans le magasin clé-valeur peuvent avoir une valeur de délai d’expiration et être synchronisées sur un cluster.

Module dynamique de session cryptée

Le module communautaire Encrypted Session fournit une prise en charge du chiffrement et du déchiffrement des variables NGINX basées sur AES-256 avec MAC. Il est désormais disponible dans le référentiel NGINX Plus en tant que module dynamique pris en charge pour NGINX Plus .

Améliorations du module JavaScript NGINX

Les modules JavaScript NGINX de R16 incluent un certain nombre d'extensions à la portée de la prise en charge du langage JavaScript. Le module JavaScript HTTP a été simplifié de sorte qu'un seul objet ( r ) accède désormais aux attributs de requête et de réponse associés à chaque requête. Auparavant, il existait des objets de requête ( req ) et de réponse ( res ) distincts. Cette simplification rend le module JavaScript HTTP cohérent avec le module JavaScript Stream qui possède un seul objet session( s ). Cette modification est entièrement rétrocompatible (le code JavaScript existant continuera de fonctionner tel quel), mais nous vous recommandons de modifier le code JavaScript existant pour profiter de cette simplification, ainsi que de l’utiliser dans le code que vous écrirez à l’avenir.

La prise en charge du langage JavaScript inclut désormais :

• Méthodes de chaîne : bytesFrom () , padStart() et padEnd()
• Méthodes supplémentaires : getrandom() et getentropy()
• Littéraux binaires

La liste complète des modifications apportées au module JavaScript est documentée dans le journal des modifications .

Nouvelle variable $ssl_preread_protocol

La nouvelle variable $ssl_preread_protocol vous permet de faire la distinction entre SSL/TLS et d'autres protocoles lors du transfert de trafic à l'aide d'un proxy TCP (flux). La variable contient la version la plus élevée du protocole SSL/TLS prise en charge par le client. Ceci est utile si vous souhaitez éviter les restrictions du pare-feu en (par exemple) exécutant les services SSL/TLS et SSH sur le même port.

Pour plus de détails, consultez Exécution de protocoles SSL et non SSL sur le même port sur notre blog.

Améliorations du contrôleur d'entrée Kubernetes

NGINX Plus peut gérer le trafic dans une large gamme d'environnements, et l'un des cas d'utilisation importants est celui d'un équilibreur de charge d'entrée pour Kubernetes . NGINX développe une solution de contrôleur Ingress qui configure automatiquement NGINX Plus, et cette intégration est entièrement prise en charge pour tous les abonnés NGINX Plus. (Tous les utilisateurs de NGINX Open Source et les clients NGINX Plus peuvent trouver l' implémentation open source sur GitHub, et des versions officielles sont publiées périodiquement.)

Au cours du développement de NGINX Plus R16 , un certain nombre d'améliorations importantes ont été ajoutées au contrôleur d'entrée officiel NGINX pour Kubernetes :

• La prise en charge de Prometheus permet aux utilisateurs d'exporter les métriques NGINX et NGINX Plus directement vers Prometheus sur Kubernetes.
• La prise en charge des graphiques Helm simplifie l'installation et la gestion du contrôleur Ingress.
• La prise en charge de l’équilibrage de charge du trafic gRPC offre une haute disponibilité et une évolutivité pour les applications basées sur gPRC. (Ajouté dans la version 1.2.0.)
• Les contrôles de santé actifs des pods Kubernetes détectent rapidement les défaillances des pods et de la connectivité réseau.
• La configuration multi-locataire et fusionnable permet de séparer les préoccupations, permettant aux équipes de gérer indépendamment différents chemins de la même application Web, tandis que les opérations conservent le contrôle de l'écouteur frontal et de la configuration SSL.
• L’authentification JWT à granularité fine , par chemin, offre un contrôle plus approfondi sur l’authentification pour les applications riches.
• La gestion directe des modèles de configuration facilite grandement le développement et le test des modifications personnalisées apportées à la configuration NGINX.

NGINX Ingress Controller peut être étendu davantage à l'aide de ConfigMaps (pour intégrer la configuration NGINX) ou en modifiant les modèles de base , permettant aux utilisateurs d'accéder à toutes les fonctionnalités NGINX lorsqu'ils créent des politiques de gestion du trafic pour leurs applications exécutées sur Kubernetes.

Pour plus de détails, consultez l'annonce de NGINX Ingress Controller pour Kubernetes Release 1.3.0 sur notre blog.

Mettre à niveau ou essayer NGINX Plus

NGINX Plus R16 inclut des fonctionnalités de clustering supplémentaires, une limitation de débit globale, un nouvel algorithme d'équilibrage de charge et plusieurs corrections de bogues . Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers R16 dès que possible. Vous bénéficierez d'un certain nombre de correctifs et d'améliorations, et cela aidera NGINX, Inc. à vous aider lorsque vous aurez besoin de créer un ticket d'assistance.

Veuillez examiner attentivement les nouvelles fonctionnalités et les changements de comportement décrits dans cet article de blog avant de procéder à la mise à niveau.

Si vous n'avez pas essayé NGINX Plus , nous vous encourageons à l'essayer - pour l'accélération Web, l'équilibrage de charge et la diffusion d'applications, ou en tant que serveur Web entièrement pris en charge avec des API de surveillance et de gestion améliorées. Vous pouvez commencer gratuitement dès aujourd’hui avec un essai gratuit de 30 jours . Découvrez par vous-même comment NGINX Plus peut vous aider à fournir et à faire évoluer vos applications.