Pourquoi migrer d'Ingress vers la Gateway API avec Kgateway en 2026 ?

Comme vous le savez, on est en plein dans une phase charnière pour nos infrastructures Kubernetes. Le vent tourne, et les vieilles habitudes qu'on a prises avec l'Ingress Controller (ce bon vieux NGINX qu'on traîne depuis des années) sont sur le point d'être bousculées. Et spoiler alert : c'est une excellente nouvelle.

On a passé les dernières semaines à poncer le sujet, à retourner la documentation de la CNCF et à benchmarker les différentes solutions. Le verdict est tombé, et il est sans appel. Nous allons adopter la Gateway API comme nouveau standard d'exposition pour tous nos clients startups, et l'implémentation technique qui a remporté nos cœurs (et nos tests de charge), c'est Kgateway.

Dans cet article, je vais vous détailler tout le cheminement qui nous a menés à cette conclusion. On va parler de la fin de la dette technique liée aux annotations NGINX, de la mise en place d'une vraie gouvernance multi-tenant et surtout, on va voir comment Kgateway nous permet de stabiliser nos environnements tout en offrant une flexibilité de routage qu'on n'avait jamais réussi à atteindre proprement jusqu'ici.

Installez-vous, prenez un café, c'est parti pour une plongée en eau profonde dans le futur de notre networking K8s.

Le constat amer : L'Ingress API est un cul-de-sac technologique

Soyons lucides : l'Ingress API est encore aujourd'hui la méthode par défaut que tout le monde utilise. On définit un host, un path, un backend, et ça fonctionne immédiatement. C'est cette apparente simplicité qui a fait son succès pour les cas d'usage classiques, mais c'est précisément là que le piège se referme dès que les besoins deviennent un tant soit peu complexes.

Et la complexité, c'est justement notre quotidien. Entre le multi-tenant, les stratégies de canary release, l'authentification fine et l'explosion des demandes autour des LLM (Large Language Models), nos clients attendent désormais bien plus qu'une simple route statique. C'est là que l'Ingress API montre ses limites structurelles : elle n'est tout simplement plus dimensionnée pour porter de telles ambitions techniques.

Pourquoi on ne peut plus continuer comme ça

Le problème majeur, c'est que l'Ingress API n'évolue plus. Kubernetes a officiellement gelé ses fonctionnalités. C'est devenu une API "legacy" qui survit sous assistance respiratoire, un constat partagé par les experts sur l'obsolescence programmée de NGINX Ingress.

Le défaut de conception originel est d'avoir tout mis dans une seule ressource. Le développeur qui veut exposer son API doit définir la route, mais il a aussi potentiellement accès à la configuration TLS ou aux annotations du Load Balancer. C'est un cauchemar de gouvernance. Pour compenser le manque de fonctionnalités natives (comme le traffic splitting ou les rewrites complexes), chaque contrôleur (NGINX, HAProxy, Traefik) a inventé ses propres annotations.

Résultat ? On se retrouve avec des fichiers YAML illisibles, bourrés d'annotations propriétaires qui créent un vendor lock-in massif. Migrer d'un contrôleur à un autre demande de réécrire tous les manifests. C'est de la dette technique pure. De plus, l'Ingress ne gère nativement que le HTTP/HTTPS. Dès qu'un client veut exposer une base de données en TCP ou un service de streaming en UDP, on doit bidouiller avec des ConfigMaps ou des Services de type LoadBalancer, ce qui casse complètement l'unification de notre modèle réseau.

La Gateway API : Une révolution, pas une évolution

La Gateway API n'est pas une "version 2" de l'Ingress. C'est une architecture totalement repensée, "Role-Oriented", qui transforme notre approche de l'infogérance Kubernetes. L'idée de génie derrière cette API, c'est d'avoir découplé les responsabilités, marquant une rupture nette avec l'ancien modèle comme l'explique ce comparatif entre Ingress et la Gateway API.

Le nouveau modèle de responsabilités partagées

Fini le temps où l'Infra et les Devs se marchaient sur les pieds dans le même fichier YAML. La Gateway API introduces trois niveaux de ressources distincts qui mappent parfaitement avec notre organisation interne.

La GatewayClassC'est le niveau "Plateforme". C'est ici qu'on définit qui va gérer le trafic. Dans notre cas, ce sera Kgateway. C'est une ressource cluster-wide. Voyez ça comme une StorageClass : on définit quel type de contrôleur est disponible, et c'est tout. C'est l'équipe de Run Log'in Line qui pilote cette couche structurante pour l'ensemble du cluster.

La GatewayC'est le cœur de notre métier d'infogérant. La ressource Gateway définit le point d'entrée réseau : les ports (80, 443, etc.), les protocoles et surtout la configuration TLS (les certificats wildcards, par exemple). C'est le contrat réseau que nous exposons aux équipes applicatives. Nous gardons le contrôle total sur où le trafic entre et comment il est sécurisé à la frontière.

Les Routes (HTTPRoute, TLSRoute, etc.)C'est là que la magie opère pour les développeurs. Ils créent des ressources HTTPRoute qui appartiennent à leur namespace. Ils y définissent leurs règles de matching (path, headers, query params) et vers quel Service Kubernetes le trafic doit aller. Mais le plus beau, c'est qu'ils doivent explicitement "s'attacher" à une Gateway existante.

Une gouvernance enfin robuste

Ce découpage nous offre une gouvernance native incroyable. Avec l'Ingress, c'était "tout ou rien". Avec la Gateway API, nous pouvons configurer la Gateway pour n'accepter que les routes provenant de certains namespaces spécifiques, ou valider les routes via des sélecteurs de labels.

La sécurité devient enfin déclarative et, surtout, sanctuarisée. On ne croise plus les doigts en espérant qu'un développeur n'ait pas écrasé une annotation de sécurité critique par mégarde — un scénario qu'on a vécu beaucoup trop souvent et qui reste extrêmement incidentogène pour nos environnements de production. Désormais, nous définissons le cadre immuable via la Gateway, et les applications viennent s'y greffer via les Routes sans aucune possibilité d'altérer la politique globale de sécurité. C'est un saut qualitatif majeur pour la stabilité de nos clients SaaS multi-tenant, où une simple erreur de configuration locale ne peut plus compromettre l'intégrité de l'exposition globale.

Pourquoi Kgateway ? L'analyse de l'équipe

C'est bien beau d'avoir une nouvelle API standardisée, mais il faut une implémentation (un contrôleur) pour la faire tourner. Le marché est vaste : Istio, Cilium, Contour, Envoy Gateway... Alors pourquoi avons-nous jeté notre dévolu sur Kgateway (anciennement Gloo Gateway) ?

Un moteur Envoy ultra-performant sous le capot

Kgateway est basé sur Envoy Proxy. Pour ceux qui ont dormi au fond de la classe ces 5 dernières années, Envoy est devenu le standard de fait pour le data plane cloud-native. Contrairement à NGINX qui a été conçu à l'ère des serveurs monolithiques et qui nécessite souvent des reloads de processus coûteux pour changer de configuration, Envoy est conçu pour la dynamicité.

Kgateway exploite cette puissance en fournissant un "Control Plane" léger mais robuste qui traduit les ressources Gateway API en configuration xDS pour Envoy. Les benchmarks et les retours d'expérience montrent que Kgateway gère beaucoup mieux les mises à jour de routes fréquentes (le "churn") que les contrôleurs basés sur NGINX, ce qui est crucial dans nos environnements CI/CD où les déploiements sont continus.

Kgateway vs Istio : Le positionnement stratégique

C'était le gros débat en interne : "Pourquoi ne pas juste utiliser Istio pour tout ?". Istio fait tout, non ? C'est vrai, Istio est une bête de course pour le Service Mesh (trafic Est-Ouest). Mais utiliser Istio comme Ingress Controller (Nord-Sud) est souvent "overkill" et complexe à maintenir si on n'a pas besoin du mesh complet tout de suite.

Voici un tableau récapitulatif pour comprendre comment Kgateway se positionne dans notre stack par rapport aux autres briques, illustrant notre méthodologie de sélection.

Kgateway se positionne comme le "best of breed" pour le trafic Nord-Sud (entrée du cluster). Il est plus riche fonctionnellement qu'un simple Ingress NGINX, mais plus focalisé et léger qu'un Istio complet.

De plus, Kgateway a récemment été donné à la CNCF (Cloud Native Computing Foundation) par Solo.io. C'est un point critique pour notre stratégie à long terme : cela garantit que le projet est "vendor-neutral" et bénéficie d'une véritable gouvernance communautaire. On a tous vu les remous récents et les incertitudes autour de la registry Bitnami suite aux rachats successifs, ou les changements de licence brutaux chez d'autres piliers de l'open source. On ne peut plus se permettre de bâtir nos fondations sur des solutions dont le modèle peut pivoter du jour au lendemain. Avec la CNCF, on s'assure que Kgateway reste un bien commun, nous protégeant contre les stratégies de monétisation agressives ou les restrictions d'accès imprévues qui pourraient mettre en péril la stabilité de nos clients.

L'atout stratégique : Kgateway comme passerelle IA (AI Gateway)

Au-delà de sa robustesse réseau et de sa conformité aux nouveaux standards, Kgateway se distingue par une fonctionnalité qui devient cruciale pour notre écosystème : ses capacités d'AI Gateway. Ce n'est pas l'unique raison de notre choix, mais c'est un avantage compétitif indéniable alors que nos clients startups intègrent massivement des LLM (Large Language Models) dans leurs architectures.

Kgateway ne se contente pas de router du trafic HTTP classique, il propose des fonctionnalités natives d'AI Gateway pour unifier les flux vers les modèles d'IA au niveau de l'infrastructure, apportant une couche de contrôle, de sécurité et d'observabilité qui nous manquait cruellement jusqu'ici.

Sécuriser et piloter la consommation des LLM

L'approche habituelle consiste à injecter des clés API directement dans le code ou les secrets des Pods, avec très peu de visibilité sur les coûts ou l'usage réel. En positionnant Kgateway en amont des appels vers OpenAI ou Anthropic, nous centralisons l'authentification et pouvons appliquer des politiques de Rate Limiting spécifiques à l'IA.

Cela nous permet, par exemple, de limiter le nombre de tokens consommés par minute pour un client donné, une stratégie efficace pour réduire les coûts Kubernetes et éviter les explosions de facturation liées à une erreur de développement ou à un usage imprévu.

Gouvernance des données et Prompt Guards

La sécurité des données est le point de vigilance numéro un. Kgateway permet d'implémenter des "Prompt Guards" directement au niveau de la gateway. Nous pouvons ainsi détecter et filtrer les informations sensibles (PII - Personally Identifiable Information) avant qu'elles ne quittent le cluster.

Cette capacité à analyser et masquer des motifs (emails, numéros de cartes) dans les requêtes sortantes offre à nos clients une infrastructure "AI-Ready" nativement sécurisée, sans qu'ils aient à réinventer la roue dans chaque microservice.

Avec Kgateway, nous pouvons configurer une route qui intercepte les appels vers les fournisseurs de LLM. Kgateway gère l'authentification centralisée et peut appliquer des politiques de Rate Limiting spécifiques à l'IA. Par exemple, on peut limiter le nombre de tokens par minute pour éviter que la facture ne s'envole à cause d'une boucle infinie dans le code d'un stagiaire.

Le plan de bataille pour la migration

Convaincre, c'est bien. Exécuter, c'est mieux. La transition d'Ingress vers Gateway API ne se fera pas en un claquement de doigts, mais il existe désormais des guides pratiques pour migrer sereinement vers la Gateway API.

Outils de migration automatisée

La communauté Kubernetes, et spécifiquement l'équipe de Kgateway, a développé des outils comme ingress2gateway. Cet utilitaire est capable de lire nos ressources Ingress existantes (même celles bourrées d'annotations NGINX spécifiques) et de générer les ressources Gateway API (Gateway + HTTPRoutes) correspondantes.

Nous allons utiliser cet outil pour générer une base de migration pour chaque client. L'idée n'est pas d'appliquer bêtement le résultat, mais de s'en servir pour auditer l'existant et refactoriser au propre. C'est l'occasion de supprimer des années de "fix temporaires" qui sont devenus permanents.

La stratégie du "Double Run"

Nous n'allons pas couper NGINX du jour au lendemain. La beauté de Kubernetes, c'est que nous pouvons faire tourner Kgateway en parallèle de NGINX Ingress sur le même cluster.

1. On déploie Kgateway et la GatewayClass.
2. On crée les Gateways et Routes pour un service pilote.
3. On change le DNS pour pointer vers le LoadBalancer de Kgateway (ou on utilise un weighted DNS record pour basculer progressivement).
4. Une fois validé, on décommissionne l'Ingress pour ce service.

Cette approche réduit le risque à quasi zéro. Si ça casse, on remet le DNS sur l'ancien Ingress.

Comparatif Technique Approfondi

Pour ceux qui veulent de la data brute, voici un résumé de notre benchmark technique. Nous avons comparé notre implémentation actuelle (NGINX), l'option "Full Istio", et notre cible Kgateway.

Les critères choisis sont ceux qui impactent le plus notre quotidien : la facilité de configuration des protocoles non-HTTP, la gestion des extensions (WAF, Rate Limit), et l'observabilité.

Ce tableau met en évidence pourquoi l'Ingress NGINX est en fin de vie pour nous. La gestion du TCP/UDP "via ConfigMap global" est une aberration en multi-tenant (un client pourrait casser la config de tout le monde). Kgateway traite le TCP/UDP comme des citoyens de première classe avec TCPRoute et UDPRoute, isolés par namespace.

De plus, la capacité de Kgateway à router vers des "Upstreams" qui ne sont pas des Pods Kubernetes (comme une fonction AWS Lambda ou un bucket S3 statique) ouvre des possibilités d'architecture hybride que nous n'avions pas avant sans bricolage intense.

Impact sur notre quotidien (Infra) et celui des Devs

Concrètement, qu'est-ce que ça change pour nous demain matin ?

Pour l'équipe Infra :Nous reprenons le contrôle. Nous ne sommes plus les concierges qui nettoient les annotations YAML invalides. Nous fournissons des GatewayClasses et des Gateways pré-configurées, sécurisées (TLS durci, WAF activé). Nous pouvons dormir sur nos deux oreilles en sachant que les développeurs ne peuvent pas accidentellement exposer le port 22 ou désactiver le SSL parce qu'ils sont limités à ce que la Gateway autorise via les allowedRoutes.

Pour les équipes Applicatives :Au début, ils vont râler. C'est normal, on change leur fromage. Ils vont devoir apprendre à écrire des HTTPRoute au lieu d'Ingress. Mais très vite, ils vont voir les avantages : ils pourront faire du A/B testing (Traffic Splitting 90%/10%) avec trois lignes de YAML standards, sans avoir à nous demander d'installer un plugin obscur. Ils pourront réécrire leurs en-têtes de requête proprement. Ils gagnent en autonomie sur le routage avancé, ce qui est le but ultime du DevOps.

Sécurité : Le concept de "Blast Radius" réduit

J'insiste sur ce point car c'est un argument de vente majeur pour nos clients fintech et santé. Avec l'Ingress Controller classique, une erreur de syntaxe dans une annotation Lua mal gérée pouvait parfois faire planter le contrôleur pour tout le cluster. Le "blast radius" (rayon d'impact) était total.

Avec Kgateway et le modèle Gateway API, les configurations sont beaucoup plus cloisonnées. Une HTTPRoute invalide dans le namespace A n'impacte pas la Gateway ni les routes du namespace B. Le contrôleur rejette simplement la configuration invalide et remonte un statut d'erreur clair sur la ressource concernée (via le champ status), sans affecter le trafic en cours. C'est ce niveau de résilience qu'on doit viser.

Conclusion et vision

La migration vers la Gateway API avec Kgateway n'est pas juste un "upgrade technique". C'est un réalignement stratégique de notre offre d'infogérance.

Nous passons d'un modèle "best effort" basé sur des conventions fragiles à un modèle "contractuel" fort, standardisé par Kubernetes. Kgateway nous apporte la performance d'Envoy, la flexibilité pour l'IA, et une roadmap claire vers le Service Mesh avec Ambient.

En résumé :

1. Ingress est mort, vive la Gateway API.
2. Kgateway est notre champion pour sa performance brute et ses fonctionnalités IA natives.
3. L'Infra reprend le lead sur la gouvernance réseau, tout en donnant plus de pouvoir aux devs sur le routage.

La prochaine étape pour vous ? Lire la documentation officielle de la Gateway API si ce n'est pas déjà fait, et commencer à jouer avec le cluster de lab où j'ai pré-déployé Kgateway. On attaque les premières migrations clients le mois prochain.

Préparez-vous, ça va être une belle aventure technique !