Après avoir étudié les répartiteurs de charge managés des grands fournisseurs Cloud (AWS ALB/NLB, GCP Cloud Load Balancing et Azure Load Balancer / App Gateway), descendons d’un cran dans l’architecture : une fois que le trafic franchit le Load Balancer L4/L7 du Cloud Provider, qui distribue les requêtes HTTP/gRPC à l’intérieur du cluster Kubernetes ou de l’hôte Docker ?

Écrit en Go et pensé dès le premier jour pour les infrastructures éphémères, Traefik Proxy s’est imposé comme le routeur périphérique (Edge Router) Cloud-Native de référence.

1. Pourquoi Traefik a révolutionné le Reverse Proxy en 2023

Contrairement aux serveurs web historiques (NGINX, Apache, HAProxy) conçus à une époque où les adresses IP des serveurs back-ends étaient statiques et où chaque modification imposait de réécrire un fichier texte puis de recharger le processus (nginx -s reload), Traefik interroge directement l’API de votre orchestrateur (Kubernetes API Server, Docker Engine, Consul, Nomad) en temps réel :

Ses trois piliers architecturaux en production

1. Séparation stricte Configuration Statique vs Dynamique :
   • La configuration statique (ports d’écoute EntryPoints, fournisseurs d’API, télémétrie Prometheus/OpenTelemetry, résolveurs ACME Let’s Encrypt) est chargée au démarrage ;
   • La configuration dynamique (routes, certificats TLS, middlewares de sécurité, poids de canary release) change à chaud en zéro milliseconde d’interruption, sans jamais recharger de processus worker.
2. Chaînage déclaratif de Middlewares : limitation de débit (Rate Limiting), injection d’en-têtes de sécurité HSTS/CSP, circuit-breaker, compression Zstd/Brotli et délégation d’authentification Zero-Trust (ForwardAuth vers Authentik, Authelia ou OAuth2-Proxy).
3. CRD IngressRoute typées : là où l’objet Ingress standard de Kubernetes obligeait à empiler des dizaines d’annotations non validées et illisibles, Traefik propose des ressources Kubernetes typées (IngressRoute, IngressRouteTCP, IngressRouteUDP, Middleware, TLSOption).

2. MàJ 2026 Fin de vie d’Ingress-NGINX et pourquoi migrer en urgence

C’est le séisme majeur de l’écosystème Kubernetes entre 2025 et 2026 : le groupe de travail Kubernetes SIG-Network et le comité de sécurité Kubernetes ont acté la mise en retraite définitive (Retirement / End-of-Life) du contrôleur communautaire kubernetes/ingress-nginx (après le gel fonctionnel d’InGate).

Pourquoi ingress-nginx a-t-il été arrêté ?

1. Dette architecturale insurmontable : ingress-nginx reposait sur un modèle fragile consistant à concaténer un gigantesque fichier nginx.conf via des templates Go à partir d’annotations libres, puis à déclencher un nginx -s reload dans le conteneur à chaque changement de route. Sur des clusters à fort trafic WebSocket ou gRPC, ces rechargements provoquaient des fuites de processus workers zombies et des pics de latence.
2. Surface d’attaque critique (CVE en série sur les annotations) : parce que les annotations (nginx.ingress.kubernetes.io/configuration-snippet, server-snippet, auth-snippet) permettaient d’injecter des directives NGINX ou du code Lua arbitraires, toute personne disposant du droit de créer un objet Ingress pouvait exécuter du code dans le pod du contrôleur et exfiltrer l’intégralité des Secrets TLS de tous les namespaces du cluster (ex: série de vulnérabilités critiques jusqu’à IngressNightmare CVE-2025-1974).
3. Convergence vers le standard officiel Gateway API : Kubernetes a gelé l’API Ingress v1 historique au profit de Kubernetes Gateway API (GatewayClass, Gateway, HTTPRoute, GRPCRoute), qui sépare proprement les rôles RBAC entre l’équipe Plateforme/SRE (qui gère la Gateway et les certificats) et les équipes Développeurs (qui déclarent leurs HTTPRoute dans leur namespace sans pouvoir injecter de configuration globale).

Plan de migration sans coupure vers Traefik v3+ (Dual-Stack Ingress & Gateway API)

La force de Traefik v3 pour sortir d’ingress-nginx en urgence est son moteur de compatibilité native :

1. Étape 1 (Drop-in replacement immédiat) : En activant le provider kubernetesIngressNginx dans Traefik v3, Traefik interprète directement vos objets Ingress existants et la majorité des annotations nginx.ingress.kubernetes.io/* sans réécrire tous vos manifestes le premier jour.
2. Étape 2 (Bascule sur Kubernetes Gateway API) : Activez le provider kubernetesGateway dans le chart Helm de Traefik et remplacez progressivement vos Ingress par des ressources standardisées HTTPRoute :

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-production-route
  namespace: prod-apps
spec:
  parentRefs:
    - name: traefik-gateway
      namespace: traefik-system
  hostnames:
    - "api.mon-domaine.fr"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v2
      backendRefs:
        - name: api-v2-stable
          port: 8080
          weight: 90
        - name: api-v2-canary
          port: 8080
          weight: 10

En combinant un Load Balancer Cloud L4 en amont (AWS NLB, GCP Network LB ou Azure Standard LB) en mode externalTrafficPolicy: Local avec Traefik v3 + Gateway API en couche 7, vous éliminez définitivement la dette de sécurité d’ingress-nginx tout en adoptant un standard portable inter-cloud.