Annonce de NGINX Plus R16

Liam CrillyDirecteur senior de la gestion des produits

[ngx_snippet name=’table-style-blog’]
Nous avons le plaisir d’annoncer la disponibilité de NGINX Plus Release 16 (R16). Cette version constitue l’une des avancées les plus importantes dans la concrétisation de la vision technique de NGINX. Avec R16, NGINX Plus fait désormais office de couche unique et élastique pour les flux entrants et sortants de toutes vos applications. Vous pouvez ainsi regrouper les fonctionnalités d’un équilibreur de charge, d’une passerelle API et d’un WAF au sein d’un seul progiciel compatible avec tous les clouds.

De nombreuses entreprises avec lesquelles nous échangeons aujourd’hui disposent de chacun de ces composants, mais ceux-ci proviennent souvent de fournisseurs différents. Cela augmente les coûts et la complexité, car les équipes d’exploitation doivent gérer chaque solution ponctuelle séparément. Cela réduit également les performances et la fiabilité, puisque chaque étape supplémentaire accroît la latence et multiplie les points de défaillance.

Grâce aux nouvelles fonctionnalités de NGINX Plus R16, vous pouvez commencer à consolider et à simplifier votre infrastructure afin de mettre en place une couche d’entrée/sortie élastique pour les applications traditionnelles comme modernes. NGINX Plus R16 intègre de nouvelles fonctionnalités de clustering, un équilibrage de charge UDP amélioré et une protection contre les attaques DDoS, ce qui en fait une solution de remplacement plus complète pour le matériel F5 BIG-IP coûteux et les autres infrastructures d’équilibrage de charge. La nouvelle prise en charge de la limitation globale du débit fait également de NGINX Plus une alternative légère à de nombreuses solutions de passerelle API. Enfin, la nouvelle prise en charge de l’algorithme d’équilibrage de charge « Random with Two Choices » fait de NGINX Plus le choix idéal pour équilibrer le trafic des microservices dans des environnements à grande échelle 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 du débit adaptée aux clusters – Dans NGINX Plus R15 nous avons introduit le module de partage d’état, qui permet de synchroniser les données au sein d’un cluster NGINX Plus. Dans cette version, le partage d’état est étendu à la fonctionnalité de limitation du débit, ce qui vous permet de définir des limites de débit globales pour un cluster NGINX Plus. La limitation globale du débit est une fonctionnalité importante pour les passerelles d’API et constitue un cas d’usage extrêmement répandu de NGINX Plus.
• Magasin clé-valeur compatible avec les clusters – Dans NGINX Plus R13, nous avons introduit un magasin clé-valeur qui peut être utilisé, par exemple, pour créer une liste dynamique d’adresses IP interdites ou gérer les redirections HTTP. Dans cette version, le magasin clé-valeur peut désormais être synchronisé à l’échelle d’un cluster et inclut un nouveau paramètre timeout, qui permet de supprimer automatiquement des paires clé-valeur individuelles. Grâce à la nouvelle prise en charge de la synchronisation, le magasin clé-valeur peut désormais être utilisé pour assurer une atténuation dynamique des attaques DDoS, 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 de la mise en cluster des équilibreurs de charge, il est important d’utiliser un algorithme d’équilibrage de charge qui ne surcharge pas involontairement certains serveurs backend. L’équilibrage de charge aléatoire avec deux choix est extrêmement efficace pour les clusters à grande échelle et deviendra la méthode par défaut dans la prochaine version de NGINX Ingress Controller for 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 première implémentation é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 provenant du client, ce qui nous permet de prendre en charge des protocoles UDP plus complexes tels qu’OpenVPN, la voix sur IP (VoIP) et l’infrastructure de postes de travail virtuels (VDI).
• Prise en charge d’AWS PrivateLink – AWS PrivateLink est la technologie d’Amazon permettant de créer des tunnels VPN sécurisés vers un cloud privé virtuel. Avec cette version, vous pouvez désormais authentifier, acheminer et répartir le trafic, ainsi qu’optimiser la circulation des flux au sein d’un centre de données AWS PrivateLink. Cette fonctionnalité repose sur la nouvelle prise en charge du protocole PROXY v2.

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

Lors du développement de NGINX Plus R16, nous avons également apporté plusieurs améliorations importantes au contrôleur Ingress NGINX officiel pour Kubernetes, l’un des principaux cas d’usage de NGINX Plus.

Découvrez-en davantage sur NGINX Plus R16 et sur tout ce qui concerne NGINX à la NGINX Conf 2018. Des sessions dédiées, des démonstrations et des experts seront à votre disposition pour explorer en détail toutes les nouvelles fonctionnalités.

Modifications importantes du comportement

• Les API Upstream Conf et Status, remplacées et rendues obsolètes par l’API unifiée de NGINX Plus, 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 de serveurs en amont et le suivi des métriques, en remplacement des API Upstream Conf et Status qui assuraient auparavant ces fonctions. Comme annoncé à l’époque, les API obsolètes sont restées disponibles et prises en charge pendant une période prolongée, désormais révolue. Si votre configuration comprend 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 afin de migrer vers la nouvelle API NGINX Plus, consultez le guide de transition sur notre blog ou contactez notre équipe d’assistance.
• Fin de la prise en charge des versions de systèmes d’exploitation arrivées 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 plateformes 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 afin d’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 la version R13, mais n’est plus pris en charge ni maintenu par NGINX, Inc.

Présentation détaillée des nouvelles fonctionnalités

Limitation du débit adaptée aux 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 de session sticky‑learn. NGINX Plus R16 étend le partage d’état à la fonctionnalité de limitation du débit. Lorsqu’il est déployé dans un cluster, NGINX Plus peut désormais appliquer une limite de débit uniforme aux requêtes entrantes, quel que soit le nœud membre du cluster qui les reçoit. Communément appelée limitation globale du débit, l’application d’une limite de débit uniforme à l’échelle d’un cluster est particulièrement pertinente pour les cas d’utilisation de passerelles d’API, car elle permet de fournir des API conformément à un accord de niveau de service (SLA) empêchant les clients de dépasser une limite de débit spécifiée.

Le partage d’état de NGINX Plus ne nécessite ni n’utilise de nœud principal : tous les nœuds sont homologues et échangent des données selon une topologie entièrement maillée. Un cluster NGINX Plus avec partage d’état doit répondre à trois exigences :

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

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;
    }
}

La directive « zone_sync » permet de synchroniser les zones de mémoire partagée au sein d'un cluster. La directive « zone_sync_server » identifie les autres instances NGINX Plus du cluster. NGINX Plus prend en charge la découverte de services DNS, ce qui permet d'identifier les nœuds du cluster par leur nom d'hôte et d'utiliser ainsi une configuration identique sur tous les nœuds. Notez qu'il s'agit d'une configuration minimale, dépourvue des contrôles de sécurité nécessaires à un déploiement en production. Pour plus de détails, consultez l'annonce de NGINX Plus R15 et la documentation de référence du module « zone_sync ».

Une fois cette configuration mise en place sur tous les nœuds, il suffit d’ajouter le nouveau paramètre sync à la directive limit_req_zone pour appliquer des limites de débit à l’ensemble d’un cluster. Avec la configuration suivante, NGINX Plus impose à chaque client une limite de 100 requêtes par seconde, en fonction de son adresse IP.

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;
    }
}

En outre, la solution de clustering avec partage d’état est indépendante de la solution de haute disponibilité basée sur keepalived‑based high‑availability solution, qui assure la résilience du réseau. Par conséquent, contrairement à cette dernière, un cluster avec partage d’état peut s’étendre sur plusieurs sites physiques.

Magasin clé-valeur compatible avec les clusters

NGINX Plus R13 a introduit un magasin clé-valeur léger en mémoire sous la forme d’un module NGINX natif. Ce module est fourni avec NGINX Plus, ce qui permet de configurer des solutions nécessitant un stockage simple de données sans installer de composants logiciels supplémentaires. En outre, le magasin clé-valeur est géré par l’API NGINX Plus, ce qui permet de créer, de modifier et de supprimer des entrées via une interface REST.

Les cas d’usage du magasin clé-valeur de NGINX Plus incluent la mise sur liste de blocage dynamique d’adresses IP, la limitation dynamique de la bande passante, ainsi que la mise en cache des jetons d’authentification.

Avec NGINX Plus R16, le magasin clé-valeur prend désormais en charge les clusters, de sorte que les entrées sont synchronisées sur tous les nœuds d’un cluster. Cela signifie que les solutions utilisant le magasin clé-valeur de NGINX Plus peuvent être déployées dans tous types d’environnements en cluster : actif-passif, actif-actif, mais aussi largement distribués.

Comme pour les autres fonctionnalités compatibles avec les clusters, il suffit, pour configurer la synchronisation du magasin clé-valeur, d’ajouter le paramètre « sync » à la directive « keyval_zone » pour un cluster déjà configuré pour le partage d’état (à l’aide des directives « zone_sync » et « zone_sync_server »).

Le magasin clé-valeur permet désormais également de définir un délai d’expiration pour chaque paire clé-valeur qui y est ajoutée. Ces entrées expirent automatiquement et sont supprimées du magasin clé-valeur une fois le délai spécifié écoulé. Le paramètre timeout est obligatoire lors de la configuration d’un magasin clé-valeur synchronisé.

Utilisation du magasin clé-valeur de NGINX Plus pour une protection dynamique contre les attaques DDoS

Vous pouvez combiner les nouvelles fonctionnalités de mise en cluster de NGINX Plus afin de 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 réparti sur un réseau étendu, le trafic malveillant peut atteindre n’importe laquelle de ces instances. Cette solution utilise une limitation de débit synchronisée et un magasin clé-valeur synchronisé pour répondre de manière dynamique aux attaques DDoS et en atténuer les effets, comme suit.

• Une limitation du débit tenant compte du cluster détecte 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 clé-valeur de type « sin bin » via un appel à l’API NGINX Plus. Le « sin bin » est synchronisé sur l’ensemble du cluster.
• Les requêtes ultérieures provenant de clients placés dans la liste de blocage sont soumises à une très faible limite de bande passante, 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 requêtes, car cela n’indique pas clairement au client qu’une mesure d’atténuation des attaques DDoS est en place.
• Au bout de dix minutes, le client est automatiquement retiré de la liste noire.

La configuration suivante présente une mise en œuvre simplifiée de cette solution dynamique d’atténuation des attaques DDoS.

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
    }
}

Équilibrage de charge aléatoire avec deux choix

Il est de plus en plus courant que les environnements de mise à disposition d’applications et d’API utilisent une couche d’équilibrage de charge évolutive ou distribuée pour recevoir les requêtes des clients et les transmettre à un environnement applicatif partagé. Lorsque plusieurs équilibreurs de charge transmettent des requêtes au même ensemble de serveurs backend, il est important d’utiliser une méthode d’équilibrage de charge qui ne surcharge pas involontairement certains de ces serveurs.

Les clusters NGINX Plus déployés dans une configuration active-active, ainsi que les environnements distribués comportant plusieurs points d’entrée, sont des scénarios courants susceptibles de mettre à l’épreuve les méthodes traditionnelles d’équilibrage de charge, car chaque équilibreur de charge ne peut pas avoir une connaissance complète de toutes les requêtes envoyées aux serveurs backend.

L’équilibrage de charge au sein d’un cluster conteneurisé présente les mêmes caractéristiques qu’un déploiement actif-actif à grande échelle. Les contrôleurs Ingress Kubernetes déployés dans un ReplicaSet comprenant plusieurs instances de la ressource Ingress doivent eux aussi relever le défi d’une répartition efficace de la charge entre les pods qui fournissent chacun des services du cluster.

Topologies de cluster bénéficiant de l’équilibrage de charge aléatoire à deux choix

La variabilité de la charge de travail a une incidence considérable sur l’efficacité de l’équilibrage de charge distribué. Lorsque chaque requête impose la même charge au serveur backend, mesurer la rapidité avec laquelle chaque serveur a répondu aux requêtes précédentes permet de déterminer efficacement où envoyer la requête suivante. NGINX Plus propose en exclusivité la méthode d’équilibrage de charge « Temps de réponse minimal », qui repose précisément sur ce principe. Toutefois, lorsque la charge du serveur backend est variable (par exemple, parce qu’elle comprend à la fois des opérations de lecture et d’écriture), les performances passées constituent un mauvais indicateur des performances futures.

La façon la plus simple de répartir la charge dans un environnement distribué consiste à choisir un serveur backend au hasard. Au fil du temps, la charge finit par s’équilibrer, mais cette approche rudimentaire risque d’entraîner ponctuellement des pics de trafic sur certains serveurs.

Une variante simple de l’équilibrage de charge aléatoire, dont il est toutefois prouvé qu’elle améliore la répartition de la charge, consiste à sélectionner au hasard deux serveurs backend, puis à envoyer la requête à celui dont la charge est la plus faible. Comparer deux choix aléatoires permet d’éviter une mauvaise décision d’équilibrage de charge, même si la décision prise n’est pas optimale. En évitant le serveur backend le plus chargé, chaque équilibreur de charge peut fonctionner indépendamment tout en évitant d’envoyer des pics de trafic vers certains serveurs backend. Cette méthode offre ainsi les avantages et l’efficacité de calcul de l’équilibrage de charge aléatoire, tout en assurant une répartition de la charge manifestement meilleure.

NGINX Plus R16 introduit deux nouvelles méthodes d’équilibrage de charge, Random et Random with Two Choices. Pour cette dernière, vous pouvez également préciser la métrique de charge que NGINX Plus doit comparer afin de déterminer lequel des deux serveurs backend sélectionnés reçoit la requête. Le tableau suivant répertorie les métriques disponibles.

* Toutes les métriques temporelles sont disponibles exclusivement avec NGINX Plus

L’extrait suivant présente un exemple simple de configuration de répartition de charge « Random with Two Choices » 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; # Choose the quicker response time from two random choices
}

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

Notez que la méthode « Aléatoire avec deux choix » convient uniquement aux environnements distribués dans lesquels plusieurs répartiteurs de charge transmettent des requêtes au même ensemble de serveurs back-end. Ne l’utilisez pas lorsque NGINX Plus est déployé sur un seul hôte ou dans une configuration active-passive. Dans ces cas, l’unique répartiteur de charge dispose d’une vue complète de toutes les requêtes, et les méthodes Round Robin, Moins de connexions et Temps minimal donnent les meilleurs résultats.

Équilibrage de charge UDP amélioré

NGINX Plus R9 a introduit la prise en charge de la mise en proxy et de l’équilibrage de charge du trafic UDP, permettant à NGINX Plus de se placer devant des applications UDP courantes telles que DNS, syslog, NTP et RADIUS afin d’assurer la haute disponibilité et l’é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 permet d’utiliser un proxy et de répartir la charge pour des applications UDP plus complexes. Il peut notamment s’agir d’OpenVPN, de la VoIP, de solutions de bureau virtuel et de sessions DTLS (Datagram Transport Layer Security). En outre, le traitement de toutes les applications UDP par NGINX Plus, qu’elles soient simples ou complexes, est également nettement plus rapide.

NGINX Plus est le seul équilibreur de charge logiciel capable de répartir la charge de quatre des protocoles Web les plus populaires – UDP, TCP, HTTP et HTTP/2 – sur une même instance et simultanément.

Prise en charge du protocole PROXY v2

NGINX Plus R16 prend désormais en charge l’en-tête du protocole PROXY v2 (PPv2), ainsi que l’inspection des valeurs personnalisées de type-longueur-valeur (TLV) dans cet 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 les informations de connexion aux serveurs en amont situés derrière un autre ensemble de proxys de couche 7 ou de dispositifs NAT. Il 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 s’appuyer sur l’injection d’en-têtes 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

L’un des cas d’utilisation de l’en-tête PPv2 concerne les connexions relayées par le Network Load Balancer (NLB) d’Amazon, qui peuvent sembler provenir d’une adresse IP privée sur l’équilibreur de charge. Le NLB fait précéder chaque connexion d’un en-tête PPv2 qui indique l’adresse IP source réelle et le port de la connexion du client. La source réelle peut être obtenue à partir de la variable $proxy_protocol_addr, et vous pouvez utiliser le module realip pour remplacer les variables sources internes de NGINX par 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 vers un cloud privé virtuel (VPC). Elle est couramment utilisée pour publier un service fournisseur (exécuté dans le VPC fournisseur) et le mettre à la disposition d’un ou de 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 connaître l’origine de chaque connexion, mais l’adresse IP source figurant dans l’en-tête PPv2 n’est pratiquement d’aucune utilité, car elle correspond à une adresse interne non routable dans le VPC client. Le NLB AWS PrivateLink ajoute l’ID du VPC source à l’en-tête à l’aide de l’enregistrement TLV PPv2 0xEA.

NGINX Plus peut inspecter les enregistrements TLV PPv2 et extraire l’ID du 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 nouveautés de NGINX Plus R16

Jetons de session opaques OpenID Connect

L’implémentation de référence OpenID Connect de NGINX Plus 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. Il est stocké dans le magasin clé-valeur de NGINX Plus et remplacé par une chaîne aléatoire envoyée au client. Lorsque le client présente cette chaîne aléatoire, elle est échangée contre le JWT, qui est ensuite validé. Ce cas d’utilisation, auparavant au stade de prototype ou expérimental, est désormais adapté à la production, car les entrées du magasin clé-valeur peuvent maintenant avoir un délai d’expiration et être synchronisées au sein d’un cluster.

Module dynamique de session chiffrée

Le module communautaire Encrypted Session prend en charge le chiffrement et le déchiffrement des variables NGINX à l’aide d’AES‑256 avec MAC. Il est désormais disponible dans le dépôt NGINX Plus en tant que module dynamique pris en charge pour NGINX Plus.

Améliorations du module JavaScript NGINX

Les modules JavaScript NGINX de la version R16 comprennent plusieurs extensions élargissant la prise en charge du langage JavaScript. Le module HTTP JavaScript a été simplifié afin qu’un objet unique (r) permette désormais d’accéder aux attributs de requête et de réponse associés à chaque requête. Auparavant, il existait des objets distincts pour la requête (req) et la réponse (res). Cette simplification harmonise le module HTTP JavaScript avec le module Stream JavaScript, qui dispose d’un objet de session unique (s). Cette modification est entièrement rétrocompatible : le code JavaScript existant continuera de fonctionner tel quel. Nous vous recommandons toutefois de modifier votre code JavaScript existant afin de tirer parti de cette simplification, et de l’adopter également dans le code que vous écrirez à l’avenir.

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

• Méthodes de chaîne de caractères : 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 détaillée dans le journal des modifications.

Nouvelle variable « $ssl_preread_protocol »

La nouvelle variable « $ssl_preread_protocol » permet de distinguer SSL/TLS des autres protocoles lors du transfert du trafic à l’aide d’un proxy TCP (flux). Cette variable contient la version la plus récente du protocole SSL/TLS prise en charge par le client. Cela peut être utile pour contourner les restrictions d’un pare-feu, par exemple en exécutant des services SSL/TLS et SSH sur le même port.

Pour plus de détails, consultez l’article « Exécuter des protocoles SSL et non-SSL sur un même port » sur notre blog.

Améliorations du contrôleur Ingress Kubernetes

NGINX Plus peut gérer le trafic dans un large éventail d’environnements, notamment en tant que équilibreur de charge Ingress pour Kubernetes. NGINX développe une solution de contrôleur Ingress qui configure automatiquement NGINX Plus, et cette intégration bénéficie d’une prise en charge complète pour tous les abonnés à NGINX Plus. (Tous les utilisateurs de NGINX Open Source et les clients de NGINX Plus peuvent trouver l’implémentation open source sur GitHub, et des versions officielles sont publiées périodiquement.)

NGINX Plus peut assurer la terminaison SSL, le routage et l’équilibrage de charge du trafic Kubernetes

Lors du développement de NGINX Plus R16, plusieurs améliorations importantes ont été apportées au contrôleur Ingress NGINX officiel pour Kubernetes :

• 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 charts Helm simplifie l’installation et la gestion du contrôleur Ingress.
• Prise en charge de l’équilibrage de charge du trafic gRPC assure une haute disponibilité et une grande évolutivité aux applications basées sur gPRC. (Ajouté dans la version 1.2.0.)
• Les contrôles d’intégrité actifs des pods Kubernetes détectent rapidement les défaillances des pods et les problèmes de connectivité réseau.
• Configuration mutualisable et multilocataire permettant de séparer les responsabilités : les équipes peuvent gérer indépendamment différents chemins d’accès d’une même application web, tandis que l’équipe d’exploitation conserve le contrôle du point d’écoute frontal et de la configuration SSL.
• Authentification JWT granulaire, définie pour chaque chemin, offre un contrôle plus précis de l’authentification pour les applications riches.
• La gestion directe des modèles de configuration facilite grandement le développement et le test de modifications personnalisées de 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, ce qui permet aux utilisateurs d’accéder à toutes les fonctionnalités de 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’article « Annonce de la version 1.3.0 de NGINX Ingress Controller pour Kubernetes » sur notre blog.

Mettez à niveau ou essayez NGINX Plus

NGINX Plus R16 inclut des fonctionnalités de clustering supplémentaires, une limitation globale du débit, un nouvel algorithme d’équilibrage de charge et plusieurs corrections de bugs. Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à la version R16 dès que possible. Vous bénéficierez ainsi de plusieurs corrections et améliorations, et cela permettra à NGINX, Inc. de mieux vous aider lorsque vous aurez besoin d’ouvrir 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 encore essayé NGINX Plus, nous vous invitons à le faire : pour accélérer vos sites web, équilibrer la charge et assurer la diffusion de vos applications, ou pour l’utiliser comme serveur web entièrement pris en charge, doté d’API avancées de surveillance et de gestion. Vous pouvez commencer gratuitement dès aujourd’hui grâce à un essai gratuit de 30 jours. Découvrez par vous-même comment NGINX Plus peut vous aider à déployer vos applications et à les faire évoluer.

À propos de l’auteur

Liam CrillyDirecteur senior de la gestion des produits

Autres articles de Liam Crilly