Traefik (prononcé « traffic ») est un reverse proxy et load balancer open source pensé dès le départ pour les environnements modernes : conteneurs, microservices, Kubernetes, cloud hybride, etc. Développé en Go par Emile Vauge et publié pour la première fois en 2016, il est aujourd’hui porté par la société Traefik Labs et distribué sous licence MIT.
L’idée centrale : au lieu d’un proxy « figé » qu’on doit reconfigurer à la main à chaque nouveau service, Traefik s’appuie sur la découverte de services (service discovery) pour se reconfigurer automatiquement en interrogeant vos orchestrateurs (Docker, Kubernetes, Consul, etc.).
1. Qu’est-ce que Traefik concrètement ?
Traefik est à la fois :
un reverse proxy HTTP/TCP/UDP
un load balancer
un Ingress Controller Kubernetes
et, de plus en plus, une API Gateway pour exposer et sécuriser vos API.
Il sait gérer de nombreux protocoles modernes : HTTP/1.1, HTTP/2, HTTP/3, WebSocket, gRPC, mais aussi des flux TCP et UDP « bruts ».
Côté intégration, Traefik se connecte directement aux API de vos « providers » :
Orchestrateurs / runtimes : Docker, Docker Swarm, Kubernetes, Nomad, Amazon ECS, Rancher, etc.
KV / registries : Consul, etcd, Redis, etc.
Il lit l’état de ces systèmes (conteneurs déployés, labels, services, endpoints…) et adapte en temps réel ses règles de routage.
2. Les grands concepts de Traefik
Traefik v2+ repose sur quatre briques principales :
EntryPoints
Les ports d’entrée (ex.
:80,:443) sur lesquels Traefik écoute.On y définit souvent HTTP, HTTPS, TCP, etc.
Routers
Ils décident comment router une requête en fonction de critères (host, path, headers, méthodes, etc.).
Exemple :
Host(“blog.example.com”) && PathPrefix(/api)→ envoie la requête vers un service précis.
Middlewares
Des briques intermédiaires pour transformer ou sécuriser la requête :
redirections HTTP→HTTPS
ajout d’en-têtes de sécurité
authentification (Basic, Digest, etc.)
rate limiting, IP whitelist, rewrite d’URL…
Services
Les backends vers lesquels le trafic est envoyé : liste d’instances avec load balancing (round robin, pondération…).
Ce modèle découplé EntryPoint → Router → Middleware → Service rend la configuration très flexible tout en restant lisible.
3. Configuration statique vs dynamique
Traefik distingue deux types de configuration :
Configuration statique
Définie au démarrage (fichier YAML/TOML, CLI, variables d’environnement).
Sert à préciser :
les EntryPoints (ports, TLS ou non)
les providers (Docker, Kubernetes, fichiers, etc.)
les options globales (logs, métriques, ACME, plugins…).
Configuration dynamique
Arrive ensuite via les providers (Docker, K8s, fichiers dynamiques…).
C’est là que l’on déclare les Routers, Middlewares et Services.
Traefik surveille en continu ces sources et se reconfigure automatiquement dès qu’un conteneur arrive, disparaît, change de label, etc.
Résultat : plus besoin de redémarrer le reverse proxy à chaque nouveau service — un gros gain pour les environnements très dynamiques.
4. Intégration avec Docker et Kubernetes
Avec Docker
En mode Docker, Traefik interroge l’API Docker pour découvrir les conteneurs et lit leurs labels pour générer les règles de routage.
Exemple de logique (simplifiée) :
Un conteneur expose un port 8080.
On lui ajoute des labels du type
traefik.http.routers.monsvc.rule=Host(“app.example.com”)".Traefik détecte le conteneur et les labels → crée un Router
monsvcautomatiquement → routage OK.
Traefik gère en plus : HTTPS, redirections, sticky sessions, middlewares, etc. directement via ces labels.
Avec Kubernetes
Dans Kubernetes, Traefik joue le rôle d’Ingress Controller, et plus récemment supporte également la Gateway API.
On définit le routage via :
des objets Ingress (ou Gateway/HTTPRoute avec la Gateway API),
des annotations ou CRD spécifiques à Traefik pour les middlewares, TLS, etc.
Traefik se connecte à l’API K8s, observe les objets, et s’adapte sans redémarrage, ce qui colle parfaitement au modèle Kubernetes.
5. Gestion automatique du HTTPS et des certificats
C’est un des gros arguments en faveur de Traefik : la gestion automatisée de TLS/SSL via ACME (Let’s Encrypt, par exemple).
Traefik sait :
obtenir automatiquement des certificats pour vos domaines,
les renouveler sans intervention,
gérer le SNI et plusieurs certificats,
faire la terminaison TLS (TLS termination) et parler ensuite en HTTP simple avec vos backends.
Pour un admin ou un devops, ça signifie souvent : plus de cron scripts maison ni de certbot partout, le proxy s’en occupe.
6. Observabilité, sécurité et extensions
Les versions récentes de Traefik (v3.x) insistent beaucoup sur l’observabilité et l’extensibilité :
Métriques : export vers Prometheus, Datadog, InfluxDB, etc.
Traces : support OpenTelemetry.
Dashboard web : vue temps réel des routers, middlewares, services, erreurs.
Plugins & WASM : possibilité d’ajouter des middlewares personnalisés (plugins Go ou WebAssembly).
Sécurité :
WAF (dans certaines éditions),
middlewares d’authent,
rate limiting,
filtres IP.
Cette combinaison en fait un candidat naturel pour jouer le rôle d’API Gateway devant vos microservices.
7. Traefik vs Nginx / HAProxy / Envoy
Traefik ne remplace pas forcément tous les autres, mais il est positionné différemment :
Traefik
Très fort sur les environnements cloud-native (Docker, K8s).
Configuration dynamique par service discovery.
Gestion native de Let’s Encrypt, HTTP/2/3, gRPC, websockets.
Nginx / Apache
Très puissants, ultra répandus, excellents comme serveurs web classiques.
Configs souvent plus verbeuses et plus statiques (même si on peut les rendre dynamiques avec d’autres outils).
HAProxy
Référence en matière de performance brute TCP/HTTP.
Config plus « bas niveau », moins axée sur l’auto-découverte des services.
Envoy
Proxy L7 très puissant, souvent utilisé comme brique de base des service meshes (Istio, etc.).
Si votre priorité est la simplicité d’exploitation d’un parc de microservices ou d’un homelab multi-conteneurs avec du HTTPS automatique, Traefik est très souvent le meilleur compromis.
8. Quelques cas d’usage typiques
1. Homelab / auto-hébergement
Une seule instance de Traefik en frontal sur votre serveur (ou cluster).
Plusieurs services derrière (Nextcloud, WordPress, Git, etc.), chacun dans son conteneur.
Un domaine ou plusieurs sous-domaines (ex.
cloud.mondomaine.fr,git.mondomaine.fr).Certificats Let’s Encrypt automatiquement gérés.
2. Plateforme microservices en Kubernetes
Traefik comme Ingress Controller.
Routes par namespace, par API, par version.
Middlewares pour limiter le trafic, ajouter des headers de sécurité, gérer l’auth.
3. API Gateway pour applications SaaS
Un Traefik (ou un cluster) en frontal de dizaines de services.
Routage basé sur le host, le path, les headers (multi-tenant, versioning d’API).
Intégration avec des systèmes d’observabilité, WAF, etc.
9. Avantages et limites
Points forts
Cloud-native par design : Docker / K8s / Consul, etc. en première classe.
Configuration dynamique très naturelle dans les environnements en mouvement constant.
HTTPS automatisé avec Let’s Encrypt.
Dashboard intégré et bonnes capacités d’observabilité.
Licence MIT et écosystème de plugins.
Points à garder en tête
La logique EntryPoint/Router/Middleware/Service peut être déroutante pour quelqu’un habitué à une config « monolithique » façon Nginx.
Pour des cas ultra spécifiques de tuning bas niveau ou de performance « extrême », HAProxy ou Envoy restent parfois préférés (à évaluer au cas par cas).
10. Conclusion
Traefik s’est imposé en quelques années comme un standard moderne pour le routage et le load balancing dans les environnements cloud-native. Sa force tient à sa capacité à écouter votre infrastructure (Docker, Kubernetes, Consul, etc.) et à se reconfigurer tout seul, tout en vous offrant un panel complet de fonctionnalités : HTTPS automatisé, middlewares, observabilité, plugins, support de HTTP/3, API Gateway, etc.
Que ce soit pour un homelab bien propre, une stack Docker de dev, ou une plateforme microservices en production, Traefik mérite clairement une place dans la boîte à outils de tout admin système / devops d’aujourd’hui.
