Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Depuis plusieurs mois, la communauté Kubernetes s'agite autour de Geteway API, et de différentes annonces de dépréciation des Ingress. On nous vente les mérites de la Gaeway API. On nous explique comment déclarer les Gateway, et les routes. Mais rarement on répond aux questions du monde réel.

Mon constat

À force d’en discuter, je me suis rendu compte qu'il y avait quelques sujets qui n'étaient pas clairs pour tout le monde.

Par exemple :

• Oui, on peut faire cohabiter Ingress, et Gateway API.
• Oui, il y a des produits qui fournissent à la foi Ingress, et GateWay API.
• Non, les Ingress ne vont pas disparaitre (du moins cela n'a pas encore été annoncé).
• Non, la totalité des templates Helm ne supporte pas Gateway API (cela risque de prendre un peu de temps avant que la communauté ne change ses habitudes… et ce, même pour les projets maintenus par de grands éditeurs).
• Non, tous les contrôleurs ne supportent pas tout Gateway API.

En pratique

Personnellement, j'ai opté pour une démarche s'inscrivant dans le temps (oui, désolé, je ne maintiens plus de cluster pro, juste mes clusters pour mes usages personnels, RKE2 /AKS). Ne pouvant passer un temps fou à gérer la bascule, et ne pouvant la faire en une foi, j'ai opté pour une démarche par itérations sur plusieurs mois. La totalité des applications reste disponible durant toute la durée des opérations.

1. Installer un cluster de test pour valider la cohabitation Ingress / Gateway API, et choisir l'outil idéal (le nouveau contrôleur d'Ingress dans un premier temps).
2. Tester, tester, tester (galérer, galérer, galérer jusqu'à trouver le contrôleur d'Ingress qui fait aussi très bien de la Gateway API).
3. Installer la solution miracle sur le cluster de production.
4. Basculer les Ingress existants vers le nouveau contrôleur d'Ingress.
5. Supprimer l'ancien contrôleur d'Ingress.
6. Déclarer une, ou plusieurs Gateway.
7. Basculer progressivement les applications d'Ingress vers HttpRoute (utiliser une solution GitOps comme Argo CD, pour se simplifier la vie).
8. Identifier les templates Helm qui ne supportent pas Gateway API. Supprimer les Ingress intégrés aux templates, et déclarer des Ingress custom (là encore GitOps "est ton ami"). Personnaliser les Ingress si besoin (pour l'authentification par exemple), puis les remplacer par des routes.

Dans mon cas, j'ai choisi Traefik. Venant de Haproxy, je n'étais pas concerné par la problématique de dépréciation de nginx. Mais j'ai préféré Traefk pour une raison simple : contrairement aux autres contrôleurs d'Iingress qui privilégient les annotations, Trafik sait utiliser des CRD (middleware). Ces middlewares peuvent être utilisés avec Ingress, et Gateway API. Autre avantage, les middlewares peuvent être partagés entre Ingress, et namspaces. J'ai donc créé quelques middlewares pour inclure une authentification, et pour personnaliser quelques entêtes HTTP.

Après avoir compris comment convertir une annotation du contrôleur d'Ingress précédent vers le middleware, il n'y avait plus rien à faire. Horsmis binder les middlewares vers mes nouveaux Ingress. Lors de la migration, le middleware était conservé, et associé à la nouvelle route. Seul l'Ingress disparaissait.

Conclusion

Il y a certainement d'autres approches possibles. Celle-ci me semble intéressante, car elle privilégie la stabilité, la sécurité, et la confiance. À aucun moment on ne peut ressentir l'impression d'avoir une épée de Damoclès au-dessus de soi. À aucun moment, on ne court le risque de perdre une fonctionnalité qui n'est pas encore supportée par Gateway API. Plus important encore, à aucun moment on ne reste avec un contrôleur d'Ingress déprécié en production.