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

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 :

• 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 ?

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 naissent et les obsolètes deviennent obsolètes à chaque version de Kubernetes, et les modifications apportées aux API ont un impact sur 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 – Un changement majeur apporté à Kubernetes ou à ses API peut affecter le bon fonctionnement de vos outils, tels qu'un contrôleur Ingress, et des ressources correspondantes.

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, la version 1 est devenue la seule version de l'API Ingress. Cela est important car, à mesure que l'API Ingress v1 devient « la seule », toutes les versions bêta ( extensions/v1beta1 et networking.k8s.io/v1beta1 ) deviennent obsolètes. Bien que cela soit perturbant pour les organisations qui n’ont pas encore adopté l’API Ingress v1, chez NGINX, nous considérons ce changement comme un bon signe. La sortie de la version bêta de l'API Ingress marque le passage à une API mature et pleinement opérationnelle. Pourquoi ce changement est-il important ? Eh bien, cela se rapporte à la gestion des versions. Disons que vous mettez à niveau un cluster existant vers Kubernetes 1.22, mais que vous continuez à utiliser les ressources liées à Ingress v1beta1 … félicitations, vous avez cassé 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, vous devez immédiatement prendre certaines mesures en fonction de la version pour éviter de casser Kubernetes, vos ressources Ingress ou 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 vous ne l'avez 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 de passer au 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 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 désormais exporter des métriques vers Prometheus et profiter de contrôles de santé actifs , et tout le monde bénéficie des améliorations apportées aux graphiques Helm, des ressources Ingress fusionnables et d'une gestion plus facile des modèles personnalisés (voir Annonce de 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 lançons notre alternative aux ressources Kubernetes Ingress standard, rendant l'exécution de fonctionnalités avancées plus facile et plus fiable.

• Mai ( v1.5.0 ) – Les ressources VirtualServer et VirtualServerRoute (VS/VSR) sont introduites comme nouvelle approche de configuration. VS/VSR sont les premières ressources NGINX Ingress , fournissant un style de configuration natif, sécurisé et indenté qui simplifie la mise en œuvre de l'équilibrage de charge Ingress (voir Annonce de NGINX Ingress Controller pour Kubernetes Release 1.5.0<.htmla>).
• Décembre ( v1.6.0 ) – La documentation est établie sur docs.nginx.com . Les ressources VS/VSR ajoutent une prise en charge plus riche de l’équilibrage de charge et atteignent un niveau de préparation à la production. La prise en charge d'OpenTracing est ajoutée pour une meilleure surveillance et un meilleur débogage des cas d'utilisation, et la possibilité d'exécuter en tant qu'utilisateur non root est ajoutée pour améliorer la sécurité (voir Annonce de NGINX Ingress Controller pour Kubernetes Release 1.6.0 ).

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

Outre de 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 publions l'opérateur NGINX Ingress pour fournir un moyen rapide, simple et certifié de déployer NGINX Ingress Controller dans les environnements OpenShift 4. x . Les ressources NGINX Ingress continuent de croître avec la prise en charge de protocoles supplémentaires, de disjoncteurs et d'une validation et d'une création de rapports améliorées (voir Annonce de NGINX Ingress Controller pour Kubernetes Release 1.7.0 ).
• 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. La personnalisation des ressources NGINX Ingress via des extraits ou des modèles personnalisés est ajoutée, et des fonctionnalités telles que les réécritures d'URI et les listes de contrôle d'accès offrent un contrôle plus précis (voir Annonce de NGINX Ingress Controller pour Kubernetes Release 1.8.0 ).
• Octobre ( v1.9.0 ) – L’intégration avec F5 NGINX Service Mesh permet de gérer le trafic nord-sud et est-ouest dans la même configuration. Des tableaux de bord Grafana ont été ajoutés pour une visualisation facile des données historiques (voir Annonce de la version 1.9.0 de NGINX Ingress Controller ).

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.

• Février ( v1.10.0 ) – L’authentification OpenID Connect (OIDC) est l’ajout majeur, facilitant l’utilisation de l’authentification JWT pour fournir une option d’authentification unique (SSO) robuste (voir Authentification unique simple et robuste avec OpenID Connect et NGINX Ingress Controller ).
• Mars ( v1.11.0 ) – Des améliorations majeures apportées aux stratégies WAF et d’équilibrage de charge offrent une puissance et une flexibilité supplémentaires, notamment des contrôles de santé et des rapports d’état (voir Équilibrage de charge TCP/UDP amélioré et configuration WAF avec NGINX Ingress Controller ).
• Juillet ( v1.12.0 ) – Les points forts de cette version concernent la facilité de déploiement. En plus de l'achat via AWS Container Marketplace, nous permettons d' extraire des images prédéfinies à partir du registre de conteneurs F5 (voir NGINX est disponible sur AWS Marketplace pour les conteneurs ).
• Octobre ( v2.0.3 ) – Bien qu’il ne s’agisse pas d’une étape majeure en termes de fonctionnalités, cette version représente une étape importante pour l’interopérabilité avec l’API Kubernetes et l’évolution de l’objet Ingress. Ce changement signifie que 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.

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 décidé qu'un contrôleur Ingress open source est le bon choix pour vos applications, vous pouvez démarrer rapidement avec le contrôleur Ingress NGINX Open Source basé sur NGINX sur 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.