Ingress (Kubernetes)

L’Ingress est la ressource Kubernetes qui décrit comment le trafic HTTP et HTTPS venant de l’extérieur atteint les services du cluster : quel nom de domaine mène à quel service, sur quel chemin, avec quel certificat TLS. C’est la porte d’entrée web du cluster — là où, hors Kubernetes, on aurait un reverse proxy nginx ou HAProxy configuré à la main.

La ressource ne fait rien sans son controller

Un point déroutant au premier abord : créer un objet Ingress n’a aucun effet en soi. C’est une déclaration d’intention, qu’un Ingress controller — un reverse proxy qui tourne dans le cluster et observe ces objets — traduit en configuration réelle. ingress-nginx, Traefik ou HAProxy Ingress sont les implémentations courantes ; un cluster managé en fournit parfois un, un cluster auto-hébergé n’en a aucun par défaut. Beaucoup de comportements concrets (redirections, timeouts, taille maximale des requêtes, en-têtes) se règlent par annotations propres à chaque controller, ce qui rend les manifests peu portables d’une implémentation à l’autre — c’est la limite que l’API Gateway, son successeur désigné, cherche à corriger.

Ce que l’Ingress centralise

Le routage par nom d’hôte permet de servir plusieurs applications derrière une seule adresse IP publique : app.example.com vers un service, api.example.com vers un autre. La terminaison TLS se fait au même endroit, avec des certificats stockés dans des Secrets Kubernetes — et l’association avec cert-manager automatise leur obtention et leur renouvellement via Let’s Encrypt. Sans Ingress, chaque application exposée exigerait son propre service de type LoadBalancer, donc sa propre adresse IP publique et sa propre configuration TLS.

Ce qui reste à résoudre en amont

L’Ingress controller est lui-même un service qu’il faut exposer. Sur un cloud managé, un LoadBalancer externe est provisionné automatiquement. Sur une infrastructure auto-hébergée, rien n’existe par défaut : il faut amener le trafic jusqu’aux nœuds du cluster et assurer la haute disponibilité de ce point d’entrée — adresse IP virtuelle, VRRP avec keepalived, ou solution comme MetalLB. L’erreur classique consiste à soigner la redondance à l’intérieur du cluster (replicas, anti-affinité) tout en laissant un point d’entrée unique en amont : le jour où il tombe, la haute disponibilité interne ne sert à rien.