Annonce de la sortie de NGINX Gateway Fabric 1.2.0

Akash AnanthanarayananResponsable marketing technique | F5 NGINX

Mike StefaniakChef de produit senior | F5 NGINX

Nous sommes ravis de vous présenter les dernières actualités de NGINX Gateway Fabric, notre implémentation conforme de l’API Gateway de Kubernetes. Nous l’avons récemment mis à jour vers la version 1.2.0, qui apporte plusieurs nouvelles fonctionnalités et améliorations particulièrement intéressantes. Cette version vise à renforcer les capacités de la plateforme et à répondre aux attentes de nos utilisateurs. Nous avons ajouté la prise en charge de F5 NGINX Plus et étendu la couverture de notre API afin de répondre aux cas d’usage les plus demandés. Nous sommes convaincus que ces améliorations offriront une meilleure expérience à tous nos utilisateurs et les aideront à atteindre leurs objectifs plus efficacement.

Figure 1 : vue d’ensemble 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, offrant ainsi une disponibilité accrue, des métriques 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, la protégeant ainsi contre un éventuel détournement de la connexion par des applications malveillantes. De plus, TLS chiffre 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 la réécriture d’URL dans les objets Route. Grâce à cette fonctionnalité, vous pouvez facilement modifier l’URL de la requête d’origine et la rediriger vers une destination plus appropriée. Ainsi, lorsque les API de vos applications backend évoluent, vous pouvez préserver la cohérence des API que vous exposez à vos clients.
• Télémétrie du produit – Grâce à la télémétrie du produit désormais intégrée à NGINX Gateway Fabric, nous pouvons contribuer à améliorer davantage l’efficacité opérationnelle de votre infrastructure en analysant la manière dont 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 allons examiner plus en détail les nouvelles fonctionnalités ci-dessous.

Quelles sont les nouveautés de NGINX Gateway Fabric 1.2.0 ?

Prise en charge de NGINX Plus

NGINX Gateway Fabric version 1.2.0 est désormais disponible avec la prise en charge de NGINX Plus, offrant ainsi de nombreux nouveaux avantages aux utilisateurs. Grâce à cette mise à niveau, les utilisateurs peuvent désormais tirer parti des fonctionnalités avancées de NGINX Plus dans leurs déploiements, notamment des métriques Prometheus supplémentaires, le rechargement dynamique des serveurs en amont et le tableau de bord NGINX Plus. Cette mise à niveau vous permet également de bénéficier d’une assistance directe de NGINX pour votre environnement.

Métriques Prometheus supplémentaires

Lorsque vous utilisez NGINX Plus comme plan de données, des métriques avancées supplémentaires sont exportées en plus de celles que vous obtenez habituellement avec NGINX Open Source. Elles comprennent notamment des métriques relatives aux requêtes HTTP, aux flux, aux connexions et bien plus encore. Pour consulter la liste complète, vous pouvez vous reporter à l’exportateur Prometheus de NGINX, qui fournit une liste pratique. Notez toutefois que cet exportateur n’est pas strictement nécessaire pour NGINX Gateway Fabric. Toute installation de Prometheus ou d’un collecteur compatible avec Prometheus vous permet de récupérer ces métriques dans votre pile d’observabilité, puis de 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 de pod. Si vous recherchez une configuration simple, consultez notre page GitHub pour savoir comment déployer et configurer Prometheus afin de commencer la collecte. Si vous souhaitez simplement consulter les métriques sans effectuer cette configuration, vous pouvez utiliser le tableau de bord NGINX Plus, présenté dans la section suivante. Après avoir installé Prometheus dans votre cluster, vous pouvez accéder à son tableau de bord en exécutant une redirection de port en arrière-plan. kubectl -n monitoring port-forward svc/prometheus-server 9090:80

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

La configuration ci-dessus fonctionnera également même si vous utilisez la version par défaut de NGINX Open Source comme plan de données. Toutefois, vous ne bénéficierez d’aucune des métriques 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 de NGINX Plus peuvent vous aider à résoudre rapidement vos problèmes de planification de capacité, vos incidents et même les défaillances des applications backend.

Rechargements dynamiques des serveurs en amont

Les rechargements dynamiques des serveurs en amont, activés automatiquement par NGINX Gateway Fabric lorsqu’il est installé avec NGINX Plus, permettent à NGINX Gateway Fabric de mettre à jour les configurations NGINX sans recharger NGINX. Traditionnellement, lors d’un rechargement de NGINX, les connexions existantes sont prises en charge par les anciens processus de travail, tandis que les processus nouvellement configurés gèrent les nouvelles connexions. Une fois toutes les anciennes connexions terminées, les anciens processus de travail sont arrêtés et NGINX poursuit son exécution uniquement avec les processus nouvellement configurés. Ainsi, les modifications de configuration sont appliquées sans interruption, même dans NGINX Open Source. Toutefois, lorsque NGINX est soumis à une charge élevée, le maintien simultané des anciens et des nouveaux processus de travail peut entraîner une consommation supplémentaire de ressources susceptible de poser problème, en particulier si vous cherchez à exécuter NGINX Gateway Fabric avec une empreinte aussi réduite que possible. Les rechargements dynamiques des serveurs en amont proposés dans NGINX Plus permettent d’éviter ce problème grâce à un point de terminaison d’API dédié aux modifications de configuration, que NGINX Gateway Fabric utilise automatiquement lorsqu’il est disponible. Cela réduit les ressources supplémentaires nécessaires pour gérer les anciens et les nouveaux processus de travail pendant le rechargement. À mesure que vous apporterez plus fréquemment des modifications à NGINX Gateway Fabric, les rechargements deviendront eux aussi plus fréquents. Pour savoir à quelle fréquence ou à quels moments des rechargements ont lieu 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 cette métrique dans un environnement comportant deux déploiements de NGINX Gateway Fabric, affichée dans le tableau de bord Prometheus :

Figure 3 : graphique Prometheus montrant le nombre total de rechargements de NGINX Gateway Fabric

Tableau de bord NGINX Plus

Comme indiqué précédemment, si vous cherchez un moyen rapide de consulter les métriques de NGINX Plus sans installer Prometheus ni déployer une pile d’observabilité, le tableau de bord de NGINX Plus vous permet de surveiller en temps réel les métriques de performances afin de résoudre les incidents et de suivre la capacité des ressources. Le tableau de bord propose d’emblée différentes vues pour toutes les métriques fournies par NGINX Plus et est facilement accessible via un port interne. Pour découvrir rapidement les fonctionnalités du tableau de bord, consultez notre site de démonstration à l’adresse demo.nginx.com. Pour accéder au tableau de bord de NGINX Plus dans votre installation de NGINX Gateway Fabric, vous pouvez rediriger les connexions vers le port 8765 de votre machine locale à l’aide d’une redirection de port : kubectl port-forward -n nginx-gateway 8765:8765 Ouvrez ensuite le navigateur de votre choix et saisissez http://localhost:8765/dashboard.html dans la barre d’adresse.

Figure 4 : vue d’ensemble du tableau de bord NGINX Plus

BackendTLSPolicy

Cette version prend désormais en charge la fonctionnalité très attendue BackendTLSPolicy. La BackendTLSPolicy introduit une communication TLS chiffrée entre NGINX Gateway Fabric et l’application, ce qui renforce considérablement la sécurité du canal de communication. Voici un exemple montrant comment appliquer cette politique en définissant des paramètres tels que les suites de chiffrement et les protocoles TLS lors de la validation des certificats de serveur auprès d’une autorité de certification (CA) de confiance. La BackendTLSPolicy permet aux utilisateurs de sécuriser le trafic entre NGF et leurs backends. Vous pouvez également définir la version minimale de TLS et les suites de chiffrement. Cela empêche les applications malveillantes de détourner la connexion et chiffre le trafic au sein du cluster. Pour configurer la terminaison TLS côté backend, commencez par créer une ConfigMap contenant le certificat de l’autorité de certification que vous souhaitez utiliser. Pour obtenir de l’aide sur la gestion des certificats internes de Kubernetes, consultez ce guide.

kind: ConfigMap
apiVersion: v1
metadata:
  name: backend-cert
data:
  ca.crt: 
         < -----BEGIN CERTIFICATE-----
	   -----END CERTIFICATE-----
          >

Ensuite, nous créons la BackendTLSPolicy, qui cible notre service secure-app et fait référence à la ConfigMap créée à l’étape précédente :

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendTLSPolicy
metadata:
  name: backend-tls
spec:
  targetRef:
    group: ''
    kind: Service
    name: secure-app
    namespace: default
  tls:
    caCertRefs:
    - name: backend-cert
      group: ''
      kind: ConfigMap
    hostname: 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 autre URL sans aucun impact sur les performances. Cette fonctionnalité est particulièrement utile lorsque vos applications backend modifient l’API qu’elles exposent, mais que vous souhaitez préserver la rétrocompatibilité pour vos clients existants. Vous pouvez également l’utiliser pour proposer à vos clients une URL d’API cohérente tout en redirigeant les requêtes vers différentes applications dotées d’URL d’API distinctes. Vous fournissez ainsi une API « d’expérience » qui combine les fonctionnalités de plusieurs API afin d’améliorer la simplicité d’utilisation et les performances pour vos clients. Pour commencer, créons une passerelle pour NGINX Gateway Fabric. Nous pourrons ainsi définir des écouteurs HTTP et configurer le port 80 afin d’obtenir des performances optimales.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cafe
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP

Créons une ressource HTTPRoute et configurons des filtres de requête afin de réécrire toutes les requêtes vers /coffee en /beans. Nous pouvons également fournir un point de terminaison /latte qui est réécrit de façon à supprimer le préfixe /latte avant le traitement par le backend (« /latte/126 » devient « /126 »).

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: coffee
spec:
  parentRefs:
  - name: cafe
    sectionName: http
  hostnames:
  - "cafe.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplaceFullPath
          replaceFullPath: /beans
    backendRefs:
    - name: coffee
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /latte
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - name: coffee
      port: 80

La fonctionnalité de réécriture HTTP offre davantage de flexibilité entre les points de terminaison côté client et leur mise en correspondance avec le backend. Elle permet également de rediriger le 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 de la migration du trafic d’une API. Bien que NGINX Gateway Fabric prenne en charge les réécritures basées sur le chemin, il ne prend actuellement pas en charge les redirections basées sur le chemin. Faites-le-nous savoir si vous avez besoin de cette fonctionnalité dans votre environnement.

Télémétrie du produit

Nous avons décidé d’inclure la télémétrie produit dans la version 1.2 afin de recueillir passivement des retours. Cette fonctionnalité collectera diverses métriques issues de votre environnement et les enverra toutes les 24 heures à notre plateforme de collecte de données. Aucune donnée à caractère personnel n’est collectée, et vous pouvez consulter la liste complète des données recueillies ici. Nous nous engageons à faire preuve d’une transparence totale concernant notre fonctionnalité de télémétrie. Nous documenterons chaque champ collecté et vous pourrez vérifier dans notre code les données que nous recueillons, mais vous aurez toujours la possibilité de désactiver complètement cette fonctionnalité. Nous prévoyons d’examiner régulièrement avec la communauté les observations intéressantes tirées des statistiques collectées lors de nos réunions communautaires, alors n’hésitez pas à venir y participer !

Ressources

Pour consulter le journal complet des modifications de NGINX Gateway Fabric 1.2.0, reportez-vous aux notes de version. Pour essayer NGINX Gateway Fabric pour Kubernetes avec NGINX Plus, commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation. Si vous souhaitez contribuer, découvrir les prochaines nouveautés ou consulter le code source de NGINX Gateway Fabric, rendez-vous sur notre dépôt GitHub ! Nos réunions communautaires ont lieu un lundi sur deux à 9 h, heure du Pacifique (17 h GMT). Le lien de la réunion, les actualités, l’ordre du jour et les comptes rendus sont disponibles dans le calendrier des réunions de NGINX Gateway Fabric. Les liens sont également toujours disponibles dans le fichier README de notre dépôt GitHub.

À propos des auteurs

Akash AnanthanarayananResponsable marketing technique | F5 NGINX

Autres articles de Akash Ananthanarayanan

Mike StefaniakChef de produit senior | F5 NGINX

Autres articles de Mike Stefaniak