Annonce de la version 1.2.0 de NGINX Gateway Fabric

Nous sommes ravis de partager les dernières nouvelles sur NGINX Gateway Fabric, qui est notre implémentation conforme de l'API Kubernetes Gateway. Nous l'avons récemment mis à jour vers la version 1.2.0, avec plusieurs nouvelles fonctionnalités et améliorations intéressantes. Cette version vise à améliorer les capacités de la plateforme et à garantir qu’elle réponde aux demandes de nos utilisateurs. Nous avons inclus le support F5 NGINX Plus et étendu notre surface API pour couvrir les cas d'utilisation les plus demandés. Nous pensons que ces améliorations créeront une meilleure expérience pour tous nos utilisateurs et les aideront à atteindre leurs objectifs plus efficacement.

Figure 1 : Présentation de la conception et de l’architecture de NGINX Gateway Fabric

Aperçu de NGINX Gateway Fabric 1.2.0 :

• Prise en charge de NGINX Plus – NGINX Gateway Fabric prend désormais en charge NGINX Plus pour le plan de données, qui offre une disponibilité améliorée, des mesures détaillées et des tableaux de bord d'observabilité en temps réel.
• BackendTLSPolicy – La vérification TLS permet à NGINX Gateway Fabric de confirmer l’identité de l’application backend, protégeant ainsi contre un éventuel détournement de la connexion par des applications malveillantes. De plus, TLS crypte le trafic au sein du cluster, garantissant une communication sécurisée entre le client et l'application backend.
• URLRewrite – NGINX Gateway Fabric prend désormais en charge les réécritures d’URL dans les objets Route. Grâce à cette fonctionnalité, vous pouvez facilement modifier l’URL de la demande d’origine et la rediriger vers une destination plus appropriée. De cette façon, à mesure que vos applications back-end subissent des modifications d’API, vous pouvez maintenir la cohérence des API que vous exposez à vos clients.
• Télémétrie des produits – La télémétrie des produits étant désormais présente dans NGINX Gateway Fabric, nous pouvons vous aider à améliorer encore l’efficacité opérationnelle de votre infrastructure en apprenant comment vous utilisez le produit dans votre environnement. Nous prévoyons également de partager régulièrement ces informations avec la communauté lors de nos réunions.

Nous examinerons plus en détail les nouvelles fonctionnalités ci-dessous.

Quoi de neuf dans NGINX Gateway Fabric 1.2.0 ?

Prise en charge de NGINX Plus

La version 1.2.0 de NGINX Gateway Fabric a été publiée avec la prise en charge de NGINX Plus, offrant aux utilisateurs de nombreux nouveaux avantages. Avec la nouvelle mise à niveau, les utilisateurs peuvent désormais exploiter les fonctionnalités avancées de NGINX Plus dans leurs déploiements, notamment des métriques Prometheus supplémentaires, des rechargements dynamiques en amont et le tableau de bord NGINX Plus. Cette mise à niveau vous permet également d'obtenir l'assistance directement de NGINX pour votre environnement.

Mesures Prometheus supplémentaires

Lorsque vous utilisez NGINX Plus comme plan de données, des mesures avancées supplémentaires seront exportées parallèlement aux mesures que vous obtiendriez normalement avec NGINX Open Source. Parmi les points forts, citons les mesures relatives aux requêtes http, aux flux, aux connexions et bien d’autres. Pour la liste complète, vous pouvez consulter l'exportateur Prometheus de NGINX pour une liste pratique , mais notez que l'exportateur n'est pas strictement requis pour NGINX Gateway Fabric. Avec n'importe quelle installation de Prometheus ou d'un scraper compatible Prometheus, vous pouvez extraire ces métriques dans votre pile d'observabilité et créer des tableaux de bord et des alertes à l'aide d'une couche cohérente au sein de votre architecture. Les métriques Prometheus sont automatiquement disponibles dans NGINX Gateway Fabric via le port HTTP 9113. Vous pouvez également modifier le port par défaut en mettant à jour le modèle Pod. Si vous recherchez une configuration simple, vous pouvez visiter notre page GitHub pour plus d'informations sur la façon de déployer et de configurer Prometheus pour commencer la collecte. Alternativement, si vous souhaitez simplement afficher les métriques et ignorer la configuration, vous pouvez utiliser le tableau de bord NGINX Plus, expliqué dans la section suivante. Après avoir installé Prometheus dans votre cluster, vous pouvez accéder à son tableau de bord en exécutant la redirection de port en arrière-plan. kubectl -n monitoring port-forward svc/prometheus-server 9090:80

Figure 2 : Graphique Prometheus montrant les connexions NGINX Gateway Fabric acceptées

La configuration ci-dessus fonctionnera même si vous utilisez le NGINX Open Source par défaut comme plan de données ! Cependant, vous ne verrez aucune des mesures supplémentaires fournies par NGINX Plus. À mesure que la taille et la portée de votre cluster augmentent, nous vous recommandons d'examiner comment les métriques NGINX Plus peuvent vous aider à résoudre rapidement vos problèmes de planification de capacité, vos incidents et même vos pannes d'applications back-end.

Rechargements dynamiques en amont

Les rechargements dynamiques en amont, activés automatiquement par NGINX Gateway Fabric lors de l'installation avec NGINX Plus, permettent à NGINX Gateway Fabric d'effectuer des mises à jour des configurations NGINX sans rechargement NGINX. Traditionnellement, lorsqu'un rechargement NGINX se produit, les connexions existantes sont gérées par les anciens processus de travail tandis que les travailleurs nouvellement configurés gèrent les nouveaux. Lorsque toutes les anciennes connexions sont terminées, les anciens travailleurs sont arrêtés et NGINX continue avec uniquement les travailleurs nouvellement configurés. De cette façon, les modifications de configuration sont gérées avec élégance, même dans NGINX Open Source. Cependant, lorsque NGINX est soumis à une charge élevée, la maintenance des anciens et des nouveaux travailleurs peut créer une surcharge de ressources qui peut entraîner des problèmes, en particulier si vous essayez d'exécuter NGINX Gateway Fabric de la manière la plus allégée possible. Les rechargements dynamiques en amont proposés dans NGINX Plus contournent ce problème en fournissant un point de terminaison d'API pour les modifications de configuration que NGINX Gateway Fabric utilisera automatiquement s'il est présent, réduisant ainsi le besoin de ressources supplémentaires pour gérer les anciens et les nouveaux travailleurs pendant le processus de rechargement. À mesure que vous commencerez à apporter des modifications plus fréquentes à NGINX Gateway Fabric, les rechargements se produiront plus fréquemment. Si vous êtes curieux de savoir à quelle fréquence ou quand les rechargements se produisent dans votre installation actuelle de NGF, vous pouvez consulter la métrique Prometheus nginx_gateway_fabric_nginx_reloads_total . Pour une analyse complète et approfondie du problème, consultez l'article de Nick Shadrin ici ! Voici un exemple de métrique dans un environnement avec deux déploiements de NGINX Gateway Fabric dans le tableau de bord Prometheus :

Figure 3 : Graphique Prometheus montrant le total des rechargements de la structure de la passerelle NGINX

Tableau de bord NGINX Plus

Comme mentionné précédemment, si vous recherchez un moyen rapide d'afficher les métriques NGINX Plus sans installation Prometheus ou pile d'observabilité, le tableau de bord NGINX Plus vous offre une surveillance en temps réel des métriques de performances que vous pouvez utiliser pour résoudre les incidents et garder un œil sur la capacité des ressources. Le tableau de bord vous offre différentes vues pour toutes les métriques que NGINX Plus fournit immédiatement et est facilement accessible sur un port interne. Si vous souhaitez avoir un aperçu rapide des fonctionnalités du tableau de bord, consultez notre site de démonstration du tableau de bord sur demo.nginx.com . Pour accéder au tableau de bord NGINX Plus sur votre installation NGINX Gateway Fabric, vous pouvez transférer les connexions vers le port 8765 sur votre machine locale via la redirection de port : kubectl port-forward -n nginx-gateway 8765:8765 Ensuite, ouvrez votre navigateur préféré et saisissez http://localhost:8765/dashboard.html dans la barre d'adresse.

Figure 4 : Présentation du tableau de bord NGINX Plus

Politique de BackendTLSPolicy

Cette version est désormais accompagnée du support tant attendu de BackendTLSPolicy . BackendTLSPolicy introduit une communication TLS chiffrée entre NGINX Gateway Fabric et l'application, améliorant considérablement la sécurité du canal de communication. Voici un exemple qui montre comment appliquer la politique en spécifiant des paramètres tels que les chiffrements et les protocoles TLS lors de la validation des certificats de serveur par rapport à une autorité de certification (CA) de confiance. La BackendTLSPolicy permet aux utilisateurs de sécuriser leur trafic entre NGF et leurs backends. Vous pouvez également définir la version TLS minimale et les suites de chiffrement. Cela protège contre les applications malveillantes qui détournent la connexion et crypte le trafic au sein du cluster. Pour configurer la terminaison TLS du backend, créez d’abord un ConfigMap avec la certification CA que vous souhaitez utiliser. Pour obtenir de l'aide sur la gestion des certificats Kubernetes internes, consultez ce guide .

gentil: ConfigMap
apiVersion : v1
métadonnées :
nom : backend-cert
données :
ca.crt : 
< -----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
>

Ensuite, nous créons le BackendTLSPolicy, qui cible notre service d’application sécurisée et fait référence au ConfigMap créé à l’étape précédente :

apiVersion : passerelle.networking.k8s.io/v1alpha2
type : BackendTLSPolicy
métadonnées :
nom : backend-tls
spécification :
targetRef :
groupe : ''
genre : Service
nom : secure-app
espace de noms : default
tls :
caCertRefs :
- nom : backend-cert
groupe : ''
type : ConfigMap
nom d'hôte : secure-app.example.com

Réécriture d'URL

Avec un filtre URLRewrite, vous pouvez modifier l'URL d'origine d'une requête entrante et la rediriger vers une URL différente sans aucun impact sur les performances. Cela est particulièrement utile lorsque vos applications back-end modifient leur API exposée, mais que vous souhaitez maintenir la compatibilité descendante pour vos clients existants. Vous pouvez également utiliser cette fonctionnalité pour exposer une URL d’API cohérente à vos clients tout en redirigeant les requêtes vers différentes applications avec différentes URL d’API, fournissant ainsi une API « d’expérience » qui combine les fonctionnalités de plusieurs API différentes pour la commodité et les performances de vos clients. Pour commencer, créons une passerelle pour la structure de passerelle NGINX. Cela nous permettra de définir des écouteurs HTTP et de configurer le port 80 pour des performances optimales.

apiVersion : passerelle.networking.k8s.io/v1
type : Passerelle
métadonnées :
nom : café
spécification :
gatewayClassName : nginx
écouteurs :
- nom : http
port : 80
protocole : HTTP

Créons une ressource HTTPRoute et configurons des filtres de requête pour réécrire toutes les requêtes de /coffee vers /beans. Nous pouvons également fournir un point de terminaison /latte qui est réécrit pour inclure le préfixe /latte à gérer par le backend (« /latte/126 » devient « /126 »).

apiVersion : passerelle.networking.k8s.io/v1
type : HTTPRoute
métadonnées :
nom : café
spécification :
parentRefs :
- nom : café
sectionName : http
noms d'hôte :
- "cafe.example.com"
règles :
- correspondances :
- chemin :
type : PathPrefix
valeur : /café
filtres :
- type : URLRewrite
urlRewrite :
chemin :
type : ReplaceFullPath
replaceFullPath: /beans
backendRefs:
- nom: café
port: 80
- correspondances :
- chemin :
type : PathPrefix
valeur : /latte
filtres :
- type : URLRewrite
urlRewrite :
chemin :
type : ReplacePrefixMatch
replacePrefixMatch: /
backendRefs:
- nom : café
port : 80

La fonctionnalité de réécriture HTTP permet de garantir la flexibilité entre les points de terminaison côté client et la manière dont ils sont mappés avec le backend. Il permet également la redirection du trafic d'une URL vers une autre, ce qui est particulièrement utile lors de la migration de contenu vers un nouveau site Web ou du trafic API. Bien que NGINX Gateway Fabric prenne en charge les réécritures basées sur les chemins, il ne prend actuellement pas en charge les redirections basées sur les chemins. Faites-nous savoir si c'est une fonctionnalité dont vous avez besoin pour votre environnement.

Télémétrie des produits

Nous avons décidé d'inclure la télémétrie du produit comme mécanisme de collecte passive de commentaires dans le cadre de la version 1.2. Cette fonctionnalité collectera une variété de mesures de votre environnement et les enverra à notre plateforme de collecte de données toutes les 24 heures. Aucune information personnelle identifiable n'est collectée et vous pouvez consulter la liste complète de ce qui est collecté ici . Nous nous engageons à fournir une transparence totale autour de notre fonctionnalité de télémétrie. Bien que nous documentions chaque champ que nous collectons et que vous puissiez valider ce que nous collectons par notre code, vous avez toujours la possibilité de le désactiver complètement. Nous prévoyons de revoir régulièrement les observations intéressantes basées sur les statistiques que nous recueillons auprès de la communauté lors de nos réunions communautaires , alors assurez-vous de passer nous voir !

Ressources

Pour le journal des modifications complet de NGINX Gateway Fabric 1.2.0, consultez les notes de publication . Pour essayer NGINX Gateway Fabric pour Kubernetes avec NGINX Plus, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation . Si vous souhaitez vous impliquer, voir ce qui va suivre ou voir le code source de NGINX Gateway Fabric, consultez notre référentiel sur GitHub ! Nous avons des réunions communautaires bimensuelles le lundi à 9h00 (heure du Pacifique) / 17h00 (heure GMT). Le lien de la réunion, les mises à jour, l'ordre du jour et les notes se trouvent sur le calendrier des réunions NGINX Gateway Fabric . Des liens sont également toujours disponibles à partir de notre fichier readme GitHub.