L'Ingress Kubernetes expliqué : Service, LoadBalancer, et la confusion classique

API Kubernetes Architecture

C'est probablement la notion la plus mal comprise de Kubernetes, parce qu'elle arrive après deux autres qui lui ressemblent. Un Service expose des pods, un LoadBalancer donne une adresse externe, et l'Ingress… fait quoi, au juste ?

Trois façons d'exposer, trois niveaux

Service, LoadBalancer et Ingress : la division du travail

Le Service adresse des pods, le LoadBalancer fournit une adresse externe, l'Ingress mutualise cette adresse entre toutes les applications.

Service (ClusterIP) — une adresse interne stable devant un groupe de pods. Elle survit au remplacement des pods, mais n'est joignable que depuis l'intérieur du cluster. C'est le socle : tout le reste s'appuie dessus.
Service de type LoadBalancer — demande une adresse joignable depuis l'extérieur. Chez un fournisseur cloud, cela crée un équilibreur et une adresse publique ; sur une infrastructure auto-hébergée, il faut quelqu'un pour fournir cette adresse (voir la fiche MetalLB). Le défaut : une adresse par service. À dix applications, dix adresses.
Ingress — un jeu de règles de routage HTTP : « ce nom de domaine, ce chemin → ce service ». Il permet de mutualiser une seule adresse d'entrée entre toutes les applications.

Ingress ≠ Ingress Controller

C'est le point qui bloque tout le monde au début. L'Ingress est un objet Kubernetes : une déclaration d'intention, quelques lignes de YAML. Il ne fait strictement rien par lui-même.

L'Ingress Controller est le programme qui lit ces objets et les applique : c'est un reverse-proxy — Traefik, NGINX, HAProxy, Envoy — qui tourne dans le cluster, surveille les Ingress déclarés et reconfigure son routage en conséquence.

Sans contrôleur installé, un Ingress ne produit aucun effet — l'objet est créé, accepté, et parfaitement inerte. C'est la cause la plus fréquente du « mon Ingress ne marche pas » sur un cluster fraîchement installé. (K3S, lui, installe Traefik d'office.)

À quoi ressemble un Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wiki
  namespace: wikijs
spec:
  ingressClassName: traefik
  rules:
  - host: wiki.cluster.labk3s.ev1
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: wikijs
            port:
              number: 80

Trois éléments à retenir :

host : le routage se fait sur le nom demandé par le client (l'en-tête HTTP Host), pas sur l'adresse IP. C'est ce qui permet à des dizaines de services de partager la même entrée ;
pathType : Prefix ou Exact. Une source de surprises classique quand une application attend une racine précise ;
ingressClassName : quel contrôleur doit prendre en charge cette règle. Indispensable dès qu'il y en a plusieurs.

Le TLS, et le couple avec le DNS

Un Ingress peut porter la terminaison TLS : le certificat est déposé dans un Secret, référencé par l'Ingress, et le contrôleur s'en sert pour servir le nom en HTTPS. C'est là qu'on branche un certificat wildcard, ou un gestionnaire automatique de certificats.

Le duo réellement efficace est celui-ci : un enregistrement DNS wildcard pointant vers l'adresse d'entrée, et un certificat wildcard sur le même domaine. Publier une nouvelle application ne demande alors ni modification DNS, ni nouveau certificat : l'Ingress déclare le nom, et tout fonctionne.

Les pièges habituels

Un Ingress dans le mauvais namespace : l'Ingress et le Service qu'il cible doivent être dans le même espace de noms.
404 du contrôleur : la requête est bien arrivée, mais aucun nom ne correspond — presque toujours un en-tête Host absent ou différent. Test utile : curl -H "Host: mon-app.mondomaine" http://ADRESSE-ENTREE, qui court-circuite le DNS et isole la panne.
502 ou 503 : le routage fonctionne, mais le service derrière ne répond pas — mauvais port, pod non prêt.
Le HTTP non chiffré qui reste accessible : la redirection vers HTTPS se configure au niveau du contrôleur, pas de l'application.

Et la Gateway API ?

L'objet Ingress est volontairement simple, et cette simplicité montre ses limites dès qu'on veut du routage avancé — répartition pondérée, en-têtes, protocoles non HTTP. Chaque contrôleur a comblé le manque à coups d'annotations propriétaires, qui rendent les configurations non portables. La Gateway API est la réponse standardisée à ce problème et prend progressivement le relais. Pour un lab ou une petite infrastructure, l'Ingress reste parfaitement adapté.

Voir la mise en pratique

Cette brique est installée et configurée pas à pas dans mon wiki, section Datacenter / Cluster K3S — la documentation de référence, avec les commandes et leurs sorties :

Et côté blog, l'étape correspondante du lab : Monter un lab Kubernetes chez soi (6) : MetalLB et Traefik, exposer les services.