Cilium et l’API Gateway : ce qui change vraiment par rapport à Ingress
Comparaison pratique entre les ressources Ingress et l’API Gateway sous Cilium, et critères de décision pour migrer ou attendre.
3 min de lecture
L’API Gateway est présentée comme le successeur d’Ingress. C’est vrai sur le papier. En exploitation, la question utile n’est pas « est-ce mieux ? » mais « qu’est-ce que cela change dans mon quotidien ? ».
Le problème que résout l’API Gateway
La ressource Ingress a une faiblesse structurelle : elle est trop pauvre pour les besoins réels, ce que chaque implémentation a compensé par des annotations propriétaires.
Résultat : un manifeste Ingress n’est pas portable. Migrer d’un contrôleur à un autre revient à réécrire toutes les annotations, sans qu’aucun outil ne puisse vérifier la correspondance.
L’API Gateway remplace ces annotations par des champs typés. Ce qui était une chaîne de caractères libre devient une structure validée par le serveur d’API.
La séparation des responsabilités
C’est le changement le plus important, et il est organisationnel autant que technique.
Gateway décrit le point d’entrée : ports, protocoles, certificats. C’est le
domaine de l’équipe qui exploite la plateforme.
HTTPRoute décrit le routage d’un service. C’est le domaine de l’équipe qui
livre ce service.
Avec Ingress, ces deux préoccupations cohabitent dans le même objet. Donner à une équipe le droit de modifier son routage revenait à lui donner le droit de toucher à la configuration TLS d’entrée.
Ce que Cilium apporte
Cilium implémente l’API Gateway directement dans son plan de données. Il n’y a pas de mandataire supplémentaire à déployer et à superviser : le composant qui fait déjà le réseau des pods fait aussi l’entrée nord-sud.
Un pod en moins dans le chemin critique, c’est une latence en moins et un composant en moins à mettre à jour.
Ce qui coince encore
Toutes les fonctionnalités ne sont pas au même niveau de maturité. Le routage HTTP est stable ; les extensions de politique le sont beaucoup moins et varient d’une implémentation à l’autre — ce qui rejoue précisément le problème de portabilité que l’API Gateway prétend résoudre.
L’outillage périphérique accuse par ailleurs un retard : plusieurs générateurs de manifestes et opérateurs ne produisent encore que des ressources Ingress.
Mon critère de décision
Pour une plateforme neuve, l’API Gateway est le choix par défaut. Le coût d’apprentissage est réel mais se paie une fois.
Pour une plateforme existante qui fonctionne, la migration n’a pas d’urgence. Ingress n’est pas déprécié et ne va pas disparaître. Migrer pour migrer, c’est prendre un risque d’exploitation sans contrepartie.
Le déclencheur légitime est le besoin de déléguer le routage à des équipes sans leur ouvrir la configuration d’entrée. C’est là que le modèle apporte quelque chose qu’Ingress ne sait pas faire proprement.