NGINX Ingress Controller version 2.0 : ce qu’il faut savoir

Brian EhlertDirecteur de la gestion des produits

En octobre, nous avons lancé la version 2.0 de F5 NGINX Ingress Controller (nginxinc/kubernetes-ingress), qui prend désormais en charge Kubernetes 1.22 et la version 1 de l’API Ingress (networking.k8s.io/v1). Vous vous demandez peut-être : « Et alors ?

La réponse à cette question est nuancée, et nous allons l’apporter en répondant à trois questions interdépendantes :

• Pourquoi les versions de Kubernetes sont-elles si importantes ?
• Qu’est-ce que l’API Ingress et pourquoi la mise à niveau vers networking.k8s.io/v1 est-elle importante ?
• Quel est l’impact de NGINX Ingress Controller 2.0 sur les clients actuels ?

Poursuivez votre lecture pour découvrir les réponses et suivez Votre plan de bataille face aux attaques des versions de Kubernetes le 11 janvier 2022.

Pourquoi les versions de Kubernetes sont-elles si importantes ?

La réponse à cette question est à la fois simple et complexe. La gestion de la compatibilité de Kubernetes est délicate, car les opérateurs Kubernetes doivent gérer trois catégories de versions :

1. La plateforme Kubernetes elle-même – À chaque nouvelle version, l’équipe Kubernetes cesse d’assurer la maintenance d’une version plus ancienne. Continuer à utiliser une telle version pose problème pour votre stratégie de gestion des risques et complique le dépannage, car l’assistance de l’équipe Kubernetes n’est plus disponible. À l’heure actuelle, le projet Kubernetes maintient les branches des trois versions mineures les plus récentes (1.20, 1.21 et 1.22). Kubernetes 1.19 et les versions ultérieures bénéficient d’environ un an de prise en charge des correctifs, tandis que la version 1.18 et les versions antérieures bénéficiaient d’environ neuf mois de prise en charge des correctifs. (Cette durée plus courte pour la version 1.18 et les versions antérieures s’explique par le fait que Kubernetes publiait auparavant quatre versions par an, contre trois actuellement).
2. Les API Kubernetes – À chaque nouvelle version de Kubernetes, de nouvelles API voient le jour et les API obsolètes sont dépréciées. Ces changements affectent les ressources et les outils correspondants. Lorsque vous mettez à niveau votre plateforme Kubernetes, vous devrez peut-être également mettre à niveau les API.
3. Les outils que vous avez déployés dans Kubernetes – Une modification majeure de Kubernetes ou de ses API peut empêcher vos outils – tels qu’un contrôleur Ingress – et les ressources correspondantes de continuer à fonctionner correctement.

Vous devez donc suivre trois calendriers : un pour Kubernetes, un pour l’API Ingress et un pour NGINX Ingress Controller. Pour éviter de perturber Kubernetes, vous devez trouver le juste équilibre, c’est-à-dire une version de Kubernetes compatible avec les API et NGINX Ingress Controller. La mise à niveau de l’un de ces trois composants sans vérifier leur compatibilité peut avoir des conséquences désastreuses. Si les trois composants ne sont pas compatibles entre eux… félicitations, vous avez rendu vos applications inutilisables !

Qu’est-ce que l’API Ingress et pourquoi networking.k8s.io/v1 est-elle importante ?

L’API Ingress permet à un contrôleur Ingress d’exposer vos applications Kubernetes en toute sécurité. L’API networking.k8s.io/v1 (également appelée API Ingress v1) a été introduite avec Kubernetes 1.19. À l’époque, Kubernetes prenait en charge à la fois v1beta1 et v1 et présentait automatiquement une version comme l’autre. Cette compatibilité « en coulisses » entre les versions de l’API facilite vos opérations, mais peut compliquer vos efforts de planification.

Avec la sortie de Kubernetes 1.22, v1 est devenue la seule version de l’API Ingress. Ce changement est important, car l’API Ingress v1 devenant la version de référence, toutes les versions bêta (extensions/v1beta1 et networking.k8s.io/v1beta1) sont désormais obsolètes. Bien que cela perturbe les organisations qui n’ont pas encore adopté l’API Ingress v1, chez NGINX, nous considérons ce changement comme un signe positif. La sortie de la phase bêta de l’API Ingress marque son passage au statut d’API mature et pleinement aboutie. Mais pourquoi ce changement est-il important ? Cela nous ramène à la gestion des versions. Imaginons que vous mettiez à niveau un cluster existant vers Kubernetes 1.22, tout en continuant à utiliser des ressources Ingress en v1beta1… félicitations, vous venez de rendre vos ressources Ingress inutilisables !

Quel est l’impact de NGINX Ingress Controller 2.0 sur les clients actuels ?

NGINX Ingress Controller étant étroitement lié à l’API Ingress, la sortie de la version v1 a eu des répercussions importantes sur notre produit, mais aussi sur vous, nos clients. C’est pourquoi nous avons fait passer le numéro de version de NGINX Ingress Controller de 1.x à 2.x. Nous avons repensé l’architecture de NGINX Ingress Controller 2.0 afin d’exploiter l’API Ingress v1 et de le rendre entièrement compatible avec Kubernetes 1.22.

Si vous utilisez NGINX Ingress Controller, vous devez immédiatement prendre certaines mesures en fonction de la version afin d’éviter de perturber le fonctionnement de Kubernetes, de vos ressources Ingress ou de NGINX Ingress Controller :

• Kubernetes 1.18 et versions antérieures :
  • Assurez-vous d’utiliser NGINX Ingress Controller 1.12 afin de bénéficier de l’ensemble de fonctionnalités le plus complet disponible. (Lorsque vous passerez à NGINX Ingress Controller 2.0, vous devrez également passer à Kubernetes 1.19 ou version ultérieure.)
  • Planifiez la migration vers une version plus récente de Kubernetes (et de NGINX Ingress Controller) dans les mois à venir, car Kubernetes 1.18 ne sera plus pris en charge après la prochaine version de Kubernetes.
• Kubernetes 1.19–1.21 :
  • Effectuez la mise à niveau vers NGINX Ingress Controller 2.0.
  • Si vous n’avez pas encore migré vos ressources liées à Ingress vers networking.k8s.io/v1 (consultez les notes de version de NGINX Ingress Controller 2.0), préparez dès maintenant votre plan de migration. Kubernetes 1.19 à 1.21 prend en charge toutes les versions actuelles de l’API Ingress (les versions v1beta1 et v1), ce qui vous permet d’effectuer la conversion sur place.
  • Si ce n’est pas déjà fait, migrez immédiatement vos ressources Ingress et IngressClass vers networking.k8s.io/v1.
    • Si vous utilisez l’annotation obsolète « kubernetes.io/ingress.class » dans vos ressources Ingress, nous vous recommandons d’utiliser plutôt le champ « ingressClassName ».
    • Utilisez notre documentation et nos exemples (disponibles avec networking.k8s.io/v1 et le champ ingressClassName de la ressource Ingress) pour planifier vos mises à jour.
• Kubernetes 1.22 :
  • Assurez-vous que vous utilisez déjà NGINX Ingress Controller 2.0, car les versions antérieures de NGINX Ingress Controller ne sont pas compatibles avec Kubernetes 1.22 et ne prennent pas en charge l’API Ingress v1.

Une histoire (pas si) brève du contrôleur Ingress NGINX

Depuis sa première version en 2016, NGINX Ingress Controller est passé d’un outil émergent à une solution incontournable pour la mise en réseau de Kubernetes. Voici un aperçu de son évolution, de son lancement à aujourd’hui.

2016 (v0.5.0)

L’ingénieur NGINX Michael Pleshakov publie la première contribution dans notre dépôt GitHub (nginxinc/kubernetes-ingress), permettant ainsi d’utiliser NGINX et F5 NGINX Plus comme contrôleur Ingress Kubernetes (KIC).

NGINX Ingress Controller fait sa première apparition publique lors de la KubeCon EU 2016. Regardez l’enregistrement : Jour 1, Création d’une solution avancée d’équilibrage de charge pour Kubernetes avec NGINX ; KubeCon EU 2016.

2017 (v1.0.0)

Le projet est désormais prêt pour la production, avec notamment une prise en charge essentielle des jetons Web JSON (JWT) dans la version basée sur NGINX Plus.

Lors de la NGINX Conf 2017, Michael Pleshakov présente les capacités de production, notamment l’équilibrage de charge avancé, dans « Utiliser NGINX Plus comme contrôleur Ingress pour équilibrer la charge des applications sur Kubernetes ».

2018

NGINX Ingress Controller bénéficie d’améliorations majeures en matière de visibilité, de facilité d’utilisation et de flexibilité :

• Mai (v1.2.0) – Le projet adopte la nouvelle API NGINX Plus et les images nginx-ingress sont transférées vers le dépôt officiel NGINX Docker Hub. Cette version inaugure la prise en charge de gRPC, des contrôles d’intégrité passifs, des charts Helm et de Prometheus.
• Août (v1.3.0) – Les clients de NGINX Plus peuvent désormais exporter des métriques vers Prometheus et tirer parti des contrôles d’intégrité actifs, tandis que tous les utilisateurs bénéficient d’améliorations apportées aux charts Helm, aux ressources Ingress fusionnables et à la gestion simplifiée des modèles personnalisés (voir Annonce de la version 1.3.0 de NGINX Ingress Controller pour Kubernetes).
• Novembre (v1.4.0) – La prise en charge de TCP/UDP est ajoutée, permettant ainsi la gestion du trafic de couche 4. Parmi les autres fonctionnalités figurent la simplification du développement d’annotations personnalisées et la prise en charge de l’algorithme d’équilibrage de charge « Random with Two Choices » (voir Annonce de la version 1.4.0 de NGINX Ingress Controller pour Kubernetes).

Lors de la NGINX Conf 2018, Michael Pleshakov monte sur scène pour présenter « Utiliser NGINX comme contrôleur Ingress Kubernetes », où il explique comment déployer NGINX Ingress Controller avec Helm, configurer l’équilibrage de charge HTTP et TCP/UDP, effectuer la supervision avec Prometheus et résoudre les problèmes.

2019

Nous lançons notre alternative aux ressources Ingress standard de Kubernetes, qui permet de mettre en œuvre des fonctionnalités avancées plus facilement et de manière plus fiable.

• Mai (v1.5.0) – Les ressources VirtualServer et VirtualServerRoute (VS/VSR) sont introduites comme une nouvelle approche de configuration. VS/VSR sont les premières ressources Ingress NGINX, offrant un style de configuration natif, avec typage sécurisé et indentation, qui simplifie la mise en œuvre de l’équilibrage de charge Ingress (voir Annonce de la version 1.5.0 de NGINX Ingress Controller pour Kubernetes<.htmla>).
• Décembre (v1.6.0) – La documentation est publiée sur docs.nginx.com. Les ressources VS/VSR offrent une prise en charge plus complète de l’équilibrage de charge et sont désormais prêtes pour la production. La prise en charge d’OpenTracing est ajoutée pour améliorer la supervision et le débogage, ainsi que la possibilité de s’exécuter en tant qu’utilisateur non-root afin de renforcer la sécurité (voir Annonce de la version 1.6.0 de NGINX Ingress Controller pour Kubernetes).

Dans « La nouvelle génération de NGINX Ingress Controller », Michael Pleshakov revient à la NGINX Conf 2019 pour présenter l’utilisation de VS/VSR dans différents cas, notamment les déploiements bleu-vert et les tests A/B.

2020

Outre les nombreuses améliorations apportées aux ressources NGINX Ingress, le thème principal de cette année est l’intégration avec les outils de l’écosystème et les produits NGINX.

• Avril (v1.7.0) – Nous lançons NGINX Ingress Operator afin d’offrir un moyen rapide, simple et certifié de déployer NGINX Ingress Controller dans les environnements OpenShift 4.x. Les ressources NGINX Ingress continuent de s’enrichir avec la prise en charge de protocoles supplémentaires et de disjoncteurs, ainsi qu’une amélioration de la validation et des rapports (voir Annonce de la version 1.7.0 de NGINX Ingress Controller pour Kubernetes).
• Juillet (v1.8.0) – L’intégration avec F5 NGINX App Protect WAF permet aux clients de déployer un WAF léger et flexible dans le même conteneur que le contrôleur Ingress. Il est désormais possible de personnaliser les ressources NGINX Ingress à l’aide d’extraits de configuration ou de modèles personnalisés, tandis que des fonctionnalités telles que la réécriture d’URI et les listes de contrôle d’accès offrent un contrôle plus précis (voir Annonce de la version 1.8.0 de NGINX Ingress Controller pour Kubernetes).
• Octobre (v1.9.0) – L’intégration à F5 NGINX Service Mesh permet de gérer le trafic nord-sud et est-ouest dans une même configuration. Des tableaux de bord Grafana sont ajoutés pour faciliter la visualisation des données historiques (voir Annonce de la version 1.9.0 de NGINX Ingress Controller).

Dans « Sécuriser les applications de production avec NGINX et OpenShift », Amir Rawdat, ingénieur en marketing technique, explique comment utiliser l’opérateur NGINX Ingress, tirer parti du contrôle d’accès basé sur les rôles (RBAC) pour le provisionnement interfonctionnel, sécuriser les applications conteneurisées avec NGINX App Protect et valider les clients à l’aide de JWT.

2021

La sécurité est un thème central, tout comme le renforcement des intégrations avec l’écosystème.

• Février (v1.10.0) – L’ajout majeur est l’authentification OpenID Connect (OIDC), qui facilite l’utilisation de l’authentification JWT afin de fournir une solution robuste d’authentification unique (SSO) (voir « Une authentification unique simple et robuste avec OpenID Connect et NGINX Ingress Controller »).
• Mars (v1.11.0) – Des améliorations majeures apportées au WAF et aux stratégies d’équilibrage de charge offrent davantage de puissance et de flexibilité, notamment grâce aux contrôles d’intégrité et aux rapports d’état (voir « Amélioration de l’équilibrage de charge TCP/UDP et de la configuration du WAF avec NGINX Ingress Controller »).
• Juillet (v1.12.0) – Cette version met avant tout l’accent sur la facilité de déploiement. Outre l’achat via AWS Container Marketplace, il est désormais possible d’extraire des images précompilées depuis F5 Container Registry (voir « NGINX est disponible dans AWS Marketplace for Containers »).
• Octobre (v2.0.3) – Bien qu’elle ne constitue pas une avancée majeure en matière de fonctionnalités, cette version marque une étape importante pour l’interopérabilité avec l’API Kubernetes et l’évolution de l’objet Ingress. Grâce à ce changement, NGINX Ingress Controller 2.0 (et versions ultérieures) est compatible avec Kubernetes 1.19 et versions ultérieures. NGINX Ingress Controller 2.0 est également la seule version que vous pouvez déployer avec Kubernetes 1.22 et versions ultérieures.

Lors de sa session NGINX Sprint 2.0, « Maîtriser les microservices grâce au chiffrement de bout en bout », l’ingénieur logiciel Aidan Carson explique comment sécuriser la périphérie avec NGINX Ingress Controller, mettre en place un contrôle d’accès sécurisé entre les services avec NGINX Service Mesh et utiliser les deux produits pour sécuriser le trafic sortant avec le protocole mTLS.

Étape suivante : essayez NGINX Ingress Controller

Si vous avez décidé qu’un contrôleur Ingress open source est le bon choix pour vos applications, vous pouvez rapidement commencer à utiliser NGINX Ingress Controller, basé sur NGINX Open Source, depuis notre dépôt GitHub.

Pour les déploiements de production à grande échelle, nous vous invitons à essayer notre contrôleur Ingress NGINX commercial basé sur NGINX Plus. Vous pouvez bénéficier d’un essai gratuit de 30 jours incluant NGINX App Protect.

À propos de l’auteur

Brian EhlertDirecteur de la gestion des produits

Autres articles de Brian Ehlert