Une ressource Ingress ne route aucun trafic par elle-même : elle décrit des règles que quelque chose doit traduire en configuration réelle. Ce quelque chose, l’Ingress Controller, doit être installé séparément, et le choix entre les deux options les plus courantes, nginx-ingress et Traefik, se joue sur un modèle de configuration, pas sur des performances brutes comparables dans l’immense majorité des cas.

nginx-ingress : une ressource Kubernetes, une configuration nginx

nginx-ingress traduit chaque ressource Ingress en configuration nginx classique, régénérée et rechargée à chaque changement. Le modèle de configuration reste celui de nginx, exposé via des annotations sur la ressource Kubernetes :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "50m"
    nginx.ingress.kubernetes.io/rate-limit: "100"
spec:
  ingressClassName: nginx
  rules:
    - host: api.exemple.com

L’avantage : une équipe déjà familière avec nginx retrouve un vocabulaire connu, et la maturité du projet (le plus déployé historiquement) signifie une documentation abondante pour presque chaque cas limite. La limite structurelle : chaque changement de configuration déclenche un rechargement nginx qui peut, sous fort trafic et beaucoup de règles, provoquer de brèves coupures de connexions en cours.

Traefik : configuration native Kubernetes, rechargement à chaud

Traefik part d’un principe différent : la configuration se fait nativement via des Custom Resources Kubernetes (IngressRoute), avec un rechargement à chaud qui ne redémarre aucun processus.

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: api-route
spec:
  routes:
    - match: Host(`api.exemple.com`)
      kind: Rule
      services:
        - name: api-service
          port: 80
      middlewares:
        - name: rate-limit

Le rechargement à chaud élimine le risque de coupure lors d’un changement de règle, un avantage réel sur un cluster avec des déploiements fréquents. Le compromis : les IngressRoute sont une extension propriétaire à Traefik, pas la ressource Ingress standard, ce qui réduit la portabilité si l’équipe veut un jour changer de contrôleur sans tout réécrire.

Le vrai critère : la fréquence des changements, pas la marque

Un cluster où les règles de routage changent rarement (quelques déploiements par semaine) ne ressent jamais la limite de nginx-ingress : le rechargement est trop peu fréquent pour que son coût compte. Un cluster avec des déploiements très fréquents, des environnements de preview créés et détruits en continu (couvert dans l’article sur les environnements éphémères par PR), ressent directement le bénéfice du rechargement à chaud de Traefik, parce que le nombre de changements de configuration devient lui-même significatif.

Ce qui ne dépend pas du choix

Les deux contrôleurs s’appuient sur MetalLB de la même façon dans un contexte on-premise : l’Ingress Controller tourne derrière un Service LoadBalancer, que ce soit nginx-ingress ou Traefik qui l’exploite. Le choix du contrôleur ne change rien à la couche réseau qui l’expose au monde extérieur.

À retenir

nginx-ingress et Traefik répondent au même besoin par deux modèles opposés : configuration par annotations sur une ressource standard contre Custom Resources natives avec rechargement à chaud. Le critère de choix est la fréquence réelle des changements de règles de routage, pas une préférence de marque ou une comparaison de performance brute rarement pertinente en pratique. Ce choix, comme celui du service de LoadBalancer qui l’expose, se pose tôt dans une migration Kubernetes.