Traefik 3.6 : Ajout du support Knative, Gateway API

Je présente ici la version Traefik 3.6, qui introduit une série d’améliorations pour simplifier le routage, renforcer l’intégration Kubernetes et faciliter les environnements hybrides. Trois évolutions se démarquent : le multi-layer routing, le support Knative, et la compatibilité complète Gateway API 1.4. Dans ce billet, j’explique ce que chacune apporte concrètement et comment je les active pas à pas.

Multi-layer routing

Le multi-layer routing permet d’enchaîner plusieurs étapes décisionnelles avant d’atteindre le service final. Au lieu de multiplier les routers pour la moindre logique, Traefik propose désormais une approche structurée où chaque couche joue un rôle précis. On peut ainsi définir une couche d’authentification, une couche de contrôle d’accès, puis une couche de routage applicatif.

Ce que ça apporte : une configuration plus modulaire et lisible, moins de duplication, et une séparation claire des responsabilités (authentification, contrôles, routage). C’est particulièrement utile en multi-tenant et pour appliquer des politiques transverses.

Exemple d’enchaînement minimal :

# Exemple de configuration Traefik avec routage multi-couches
http:
  routers:
    main:
      rule: Host(`api.example.com`)
      service: auth@internal
      middlewares:
        - auth-check
      childRouters:
        - route-app

  routers:
    route-app:
      rule: PathPrefix(`/v1`)
      service: app-service

Cette organisation rend la configuration plus intelligible, surtout lorsqu’on gère des dizaines de services et de pipelines différents. Elle facilite également la maintenance en distinguant clairement les rôles de chaque étape.

Support natif Knative

Avec Traefik 3.6, je peux router nativement vers des services Knative, sans plugins ni contournements. Le proxy sait communiquer avec les workloads serverless, capables de s’arrêter automatiquement et de redémarrer à la demande.

Ce que ça apporte : un pont simple entre microservices « classiques » et fonctions serverless, une meilleure élasticité (scale-to-zero) et un coût maîtrisé en environnement évènementiel. Je gagne en cohérence de plateforme sans multiplier les composants.

Déclaration d’un service Knative :

# Exemple minimal d’un service Knative côté cluster
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: demo-knative
spec:
  template:
    spec:
      containers:
        - image: ghcr.io/example/demo:latest

Cette intégration intéresse particulièrement les plateformes multi-cloud et les architectures orientées événements.

Compatibilité Gateway API 1.4

La Gateway API devient un standard incontournable pour configurer la partie réseau d’un cluster Kubernetes. Avec la version 3.6, Traefik adopte pleinement la spécification 1.4, couvrant HTTPRoute, GatewayClass et Gateway.

Ce que ça apporte : un langage commun entre clusters et contrôleurs, une meilleure gouvernance des flux (séparation réseau/application), et une standardisation qui réduit le coût d’onboarding et les écarts de configuration.

Exemple de HTTPRoute :

# Exemple d’HTTPRoute conforme Gateway API 1.4
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
spec:
  parentRefs:
    - name: traefik-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /app
      backendRefs:
        - name: app-svc
          port: 80

Cette standardisation accélère l’onboarding des nouvelles équipes et facilite

les migrations multi-clusters.

Pourquoi ces nouveautés transforment le quotidien des équipes

Ces fonctionnalités simplifient mon travail lorsque je dois jongler entre VM, conteneurs, microservices et workloads serverless.

• Multi-layer routing : moins de duplication, flux plus clairs, pipelines sécurisables par couches.
• Knative : intégration propre du serverless avec scale-to-zero et coûts contenus.
• Gateway API : cadre standardisé, réduction des écarts entre clusters, configuration plus gouvernable.

Résultat : un reverse proxy plus lisible, conforme aux standards actuels et adapté aux architectures modernes.

Activer et configurer les nouvelles fonctionnalités

Activer le multi-layer routing

Dans la configuration statique :

# Activer l’option expérimentale côté configuration statique
experimental:
  multiLayerRouting: true

Cette option permet d’utiliser les childRouters, principaux éléments du nouveau pipeline de routage.

Exemple de pipeline complet

On peut créer un pipeline avec une étape de validation interne, suivie du routage applicatif :

# Pipeline de routage : validation interne puis service applicatif
http:
  routers:
    entry:
      rule: Host(`dashboard.example.com`)
      middlewares:
        - check-plan
      childRouters:
        - route-dashboard

  routers:
    route-dashboard:
      rule: PathPrefix(`/ui`)
      service: dashboard-svc

Activer Knative côté cluster

Aucune configuration spécifique n’est nécessaire côté Traefik si le provider Kubernetes est actif. Il suffit de créer un service Knative ; Traefik détectera automatiquement les routes correspondantes.

Déployer la Gateway API

Pour basculer progressivement sur la Gateway API, on commence par déclarer une GatewayClass :

# Déclaration de la GatewayClass contrôlée par Traefik
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: traefik
spec:
  controllerName: traefik.io/gateway-controller

Ensuite, on crée la Gateway et les HTTPRoute nécessaires. Cela permet une meilleure visibilité des flux et une séparation nette entre réseau et application.

Migration depuis une version antérieure

Avant toute mise à jour, il est recommandé de parcourir le guide officiel disponible sur la documentation Traefik ↗. Certains comportements changent, notamment :

• la gestion des routers combinés
• les règles de priorisation
• l’intégration avec Kubernetes Ingress
• certains types de middlewares

Pour les environnements critiques, il est prudent de tester la configuration en environnement de staging. Un audit des CRDs est également conseillé afin d’éviter les incompatibilités.

Bonnes pratiques avec Traefik 3.6

• adopter la Gateway API progressivement en parallèle des Ingress
• activer les logs en mode debug pour vérifier l’exécution des couches de routage
• documenter les pipelines multi-layer pour éviter les divergences
• vérifier régulièrement les CRDs après chaque mise à jour du cluster

Conclusion

Avec Traefik 3.6, les perspectives s’élargissent pour les architectures hybrides :

• le multi-layer routing ouvre la voie à des pipelines de routage modulaires, où chaque couche (authentification, contrôle, applicatif) reste indépendante et maintenable ;
• le support Knative permet d’intégrer le serverless directement dans la chaîne de routage, avec une élasticité native et un scale-to-zero transparent ;
• la compatibilité Gateway API 1.4 aligne Traefik sur le standard Kubernetes émergent, facilitant la portabilité et la gouvernance multi-clusters.

Ces évolutions renforcent la position de Traefik comme reverse proxy unifié pour les plateformes modernes, qu’elles reposent sur des VM, des conteneurs ou des fonctions serverless.

Plus d’infos sur Traefik

J’ai un guide complet sur Traefik que vous pouvez consulter pour approfondir vos connaissances et maîtriser toutes les fonctionnalités avancées. Je vais le mettre à jour régulièrement pour intégrer les nouveautés.