BLOG | NGINX

Contrôleur d'entrée NGINX version 2.0 : Ce que vous devez savoir

NGINX-Partie-de-F5-horiz-black-type-RGB
Vignette de Brian Ehlert
Brian Ehlert
Publié le 27 décembre 2021

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

Ce « et alors » est nuancé et nous y répondrons en répondant à trois questions interdépendantes :

Lisez la suite pour obtenir les réponses et écoutez votre plan de bataille lorsque les versions de Kubernetes attaquent le 11 janvier 2022 .

Pourquoi les versions de Kubernetes sont-elles si importantes ?

La réponse à cette question est simple mais compliquée. La gestion de la compatibilité pour Kubernetes est un défi car les opérateurs Kubernetes doivent gérer trois catégories de versionnage :

  1. La plateforme Kubernetes elle-même – À chaque nouvelle version, l’équipe Kubernetes arrête de maintenir une ancienne version. Continuer à utiliser une telle version est problématique pour votre stratégie de gestion des risques et rend le dépannage plus difficile car l’aide de l’équipe Kubernetes n’est plus disponible. À l’heure actuelle, le projet Kubernetes maintient des branches de publication pour les trois versions mineures les plus récentes (1.20, 1.21 et 1.22). Kubernetes 1.19 et versions ultérieures bénéficient d'environ 1 an de support de correctifs, tandis que 1.18 et versions antérieures bénéficient d'environ 9 mois de support de correctifs. (Le délai plus court pour la version 1.18 et les versions antérieures est dû au fait que Kubernetes publiait auparavant quatre versions par an, au lieu des trois actuelles).

  2. Les API Kubernetes – De nouvelles API apparaissent et d'anciennes sont abandonnées à chaque version de Kubernetes, affectant les ressources et outils associés. En mettant à jour votre plateforme Kubernetes, vous devrez peut-être aussi mettre à jour les API.

  3. Les outils que vous avez déployés dans Kubernetes – Une modification majeure de Kubernetes ou de ses API peut compromettre le fonctionnement de vos outils, comme un contrôleur Ingress, ainsi que des ressources associées.

Vous devez donc suivre trois chronologies : une pour Kubernetes, une pour l’API Ingress et une pour NGINX Ingress Controller. Pour éviter de casser Kubernetes, vous devez trouver le point idéal où la version Kubernetes est compatible avec les API et NGINX Ingress Controller. La mise à niveau de l’un des trois composants sans vérifier la compatibilité peut avoir des conséquences dramatiques. Si les trois composants ne sont pas compatibles entre eux… félicitations, vous avez cassé vos applications !

Qu'est-ce que l'API Ingress et pourquoi networking.k8s.io/v1 est-il important ?

L'API Ingress permet à un contrôleur Ingress d'exposer en toute sécurité vos applications Kubernetes. L'API networking.k8s.io/v1 (alias L'API Ingress v1) a été introduite avec Kubernetes 1.19. À cette époque, Kubernetes prenait en charge à la fois les versions v1beta1 et v1 , et présentait automatiquement une version comme l’autre. Cette compatibilité « secrète » des versions d’API vous profite sur le plan opérationnel, mais peut entraver vos efforts de planification.

Avec la sortie de Kubernetes 1.22, v1 est devenue la seule version de l’API Ingress. Cela marque un tournant important, car à mesure que l’API Ingress v1 s’impose comme la référence, toutes les versions bêta (extensions/v1beta1 et networking.k8s.io/v1beta1) sont dépréciées. Même si cela perturbe les organisations qui n’ont pas encore adopté l’API Ingress v1, chez NGINX, nous voyons ce changement comme une avancée positive. La validation de l’API Ingress, qui sort de sa bêta, témoigne de sa maturité et de sa pleine capacité. Alors, pourquoi ce changement est-il essentiel ? Cela revient à la gestion des versions. Supposons que vous mettiez à jour un cluster existant vers Kubernetes 1.22, tout en continuant à utiliser les ressources Ingress en v1beta1… félicitations, vous avez compromis vos ressources Ingress !

Comment NGINX Ingress Controller 2.0 affecte-t-il les clients actuels ?

Étant donné que NGINX Ingress Controller est étroitement lié à l'API Ingress, la sortie de la version 1 a eu un impact significatif sur nous en tant que produit, ainsi que sur vous en tant que clients. C'est pourquoi nous avons fait passer le numéro de version de NGINX Ingress Controller de 1. x à 2. x . Nous avons réarchitecturé NGINX Ingress Controller 2.0 pour tirer parti de l'API Ingress v1, le rendant entièrement compatible avec Kubernetes 1.22.

Si vous utilisez NGINX Ingress Controller, prenez sans délai des mesures adaptées à votre version pour ne pas compromettre Kubernetes, vos ressources Ingress, ni NGINX Ingress Controller.

  • Kubernetes 1.18 et versions antérieures :

    • Assurez-vous d’utiliser NGINX Ingress Controller 1.12 afin de pouvoir profiter de l’ensemble complet de fonctionnalités disponibles. (Lorsque vous effectuez une mise à niveau vers NGINX Ingress Controller 2.0, vous devrez également effectuer une mise à niveau vers Kubernetes 1.19 ou une version ultérieure.)

    • Prévoyez de migrer 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 :

    • 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 ), créez votre plan maintenant. Kubernetes 1.19–1.21 prend en charge toutes les versions actuelles de l'API Ingress (à la fois v1beta1 et v1 ), vous offrant ainsi la possibilité d'effectuer une conversion sur place.

    • Si ce n'est pas déjà fait, déplacez 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’adopter le champ ingressClassName.

      • Consultez notre documentation et nos exemples (accessibles via networking.k8s.io/v1 ainsi que le champ ingressClassName de la ressource Ingress) pour préparer vos mises à jour.

  • Kubernetes 1.22 :

    • Assurez-vous que vous exécutez déjà NGINX Ingress Controller 2.0, car les versions précédentes de NGINX Ingress Controller ne sont pas compatibles avec Kubernetes 1.22 et ne prennent pas en charge l'API Ingress v1.

Une (pas si) brève histoire du contrôleur d'entrée NGINX

Depuis sa première sortie en 2016, NGINX Ingress Controller est passé d'un outil naissant à une puissance pour la mise en réseau Kubernetes. Voici un aperçu de son évolution depuis son lancement jusqu’à aujourd’hui.

2016 ( v0.5.0 )

L'ingénieur NGINX Michael Pleshakov publie la première entrée dans notre référentiel GitHub ( nginxinc/kubernetes-ingress ) , permettant d'utiliser NGINX et F5 NGINX Plus comme contrôleur Kubernetes Ingress (KIC).

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

2017 ( v1.0.0 )

Le projet est prêt pour la production, y compris la prise en charge clé des jetons Web JSON (JWT) dans la version basée sur NGINX Plus .

Lors de la conférence NGINX 2017, Michael Pleshakov démontre ses capacités de production, notamment l'équilibrage de charge avancé, dans Utilisation de NGINX Plus comme contrôleur d'entrée pour l'équilibrage de charge des applications sur Kubernetes .

2018

NGINX Ingress Controller connaît de grandes améliorations dans les domaines de la visibilité, de la facilité d'utilisation et de la flexibilité :

  • Mai ( v1.2.0 ) – Le projet adopte la nouvelle API NGINX Plus et les images nginx-ingress sont déplacées vers le Docker Hub officiel NGINX . Cette version présente la prise en charge de gRPC, des contrôles de santé passifs, des graphiques Helm et de Prometheus.
  • Août (v1.3.0) – Les clients NGINX Plus peuvent maintenant exporter des métriques vers Prometheus et profiter des contrôles de santé actifs. Tous bénéficient aussi des améliorations des graphiques Helm, des ressources Ingress fusionnables, et d’une gestion simplifiée des modèles personnalisés (voir Annonce du NGINX Ingress Controller pour Kubernetes Release 1.3.0).
  • Novembre ( v1.4.0 ) – La prise en charge de TCP/UDP est ajoutée, rendant possible la gestion du trafic de couche 4. D’autres fonctionnalités incluent un développement plus facile d’annotations personnalisées et la prise en charge de l’algorithme d’équilibrage de charge Random with Two Choices (voir Annonce de NGINX Ingress Controller pour Kubernetes Release 1.4.0 ).

Lors de la conférence NGINX 2018, Michael Pleshakov prend la parole pour utiliser NGINX comme contrôleur d'entrée Kubernetes , où il explique comment déployer NGINX Ingress Controller avec Helm, configurer l'équilibrage de charge HTTP et TCP/UDP, surveiller avec Prometheus et résoudre les problèmes.

2019

Nous présentons notre alternative aux ressources Kubernetes Ingress standards, pour vous permettre d’exécuter plus facilement et de manière plus fiable des fonctionnalités avancées.

Dans The Next Generation of NGINX Ingress Controller , Michael Pleshakov revient à NGINX Conf 2019 pour présenter VS/VSR pour des cas d'utilisation incluant les déploiements bleu-vert et les tests A/B.

2020

En plus d’améliorer significativement les ressources NGINX Ingress, nous mettons cette année l’accent sur l’intégration avec les outils de l’écosystème et les produits NGINX.

Dans Secure Production Apps with NGINX and OpenShift , l'ingénieur marketing technique Amir Rawdat montre comment utiliser l'opérateur d'entrée NGINX, exploiter le 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 avec des JWT.

2021

La sécurité est un thème principal, ainsi que davantage d’intégrations d’écosystèmes.

Dans sa session NGINX Sprint 2.0 , Master Microservices with End-to-End Encryption , l'ingénieur logiciel Aidan Carson montre comment sécuriser la périphérie avec NGINX Ingress Controller, configurer 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 de sortie avec mTLS.

Étape suivante : Essayez le contrôleur d'entrée NGINX

Si vous avez choisi un contrôleur Ingress open source pour vos applications, commencez rapidement avec le contrôleur Ingress NGINX basé sur NGINX Open Source dans notre référentiel GitHub.

Pour les déploiements de production à grande échelle, nous espérons que vous essayerez notre contrôleur d'entrée NGINX commercial basé sur NGINX Plus. Il est disponible pour un essai gratuit de 30 jours qui inclut NGINX App Protect.

Lire plus d'articles de blog sur F5 NGINX ›

« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."