Kubernetes Gateway API v1.6 stabilise le routage TCP et UDP — les bases de données et la VoIP entrent dans le Gateway standard

3 août 2026. Le blog Kubernetes a officialisé ce matin la graduation de TCPRoute et UDPRoute au statut Standard dans Gateway API v1.6.0. La release elle-même date du 30 juin 2026, mais l’annonce formelle d’aujourd’hui marque la fin d’un processus de stabilisation de dix-huit mois. Le message est simple : les workloads qui ne parlent pas HTTP peuvent désormais utiliser la Gateway API comme les autres, sans recourir à des contournements ou à des CRD propriétaires.

C’est une étape majeure pour l’adoption de la Gateway API comme standard unique de routage dans Kubernetes — et un signal envoyé aux gateway controllers (Istio, Envoy Gateway, Cilium, NGINX) : le support L4 doit être complet et portable.

TCPRoute et UDPRoute : le chaînon manquant du routage standardisé

Jusqu’à Gateway API v1.5, le standard ne couvrait que le trafic HTTP et TLS au niveau L7. Pour les protocoles qui opèrent en dessous — bases de données, files de messages, DNS, VoIP, télémétrie IoT — les équipes avaient deux options, aucune satisfaisante :

• Revenir à un Service Kubernetes classique de type LoadBalancer ou NodePort, perdant tous les bénéfices du modèle Gateway (routage déclaratif, séparation des rôles, politiques de trafic).
• Utiliser une CRD propriétaire du contrôleur Gateway (par exemple TCPRoute chez Istio avant la standardisation), qui ne voyage pas d’un contrôleur à l’autre et verrouille l’infrastructure sur un fournisseur.

TCPRoute et UDPRoute ferment définitivement cette brèche. Désormais, un cluster Kubernetes peut exposer une base de données PostgreSQL, un serveur DNS, un broker MQTT ou un flux RTSP via une Gateway unique, avec les mêmes principes de role-oriented design qui ont fait le succès de HTTPRoute.

Le modèle est d’une simplicité radicale. Un Gateway déclare un listener TCP sur un port :

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: database-gateway
spec:
  gatewayClassName: envoy-gateway
  listeners:
  - name: postgres
    protocol: TCP
    port: 5432
    allowedRoutes:
      kinds:
      - kind: TCPRoute

Un TCPRoute s’attache à ce listener et forwarde le trafic vers un backend :

apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
  name: postgres-route
spec:
  parentRefs:
  - name: database-gateway
    sectionName: postgres
  rules:
  - backendRefs:
    - name: postgres-primary
      port: 5432

UDPRoute suit exactement le même pattern, en remplaçant TCP par UDP dans le listener et UDPRoute dans la route. Le trafic qui arrive sur le port 5432 du Gateway est proxifié vers les endpoints du Service postgres-primary, sans inspection L7, sans TLS termination — exactement ce qu’une base de données attend.

Séparation des API groups expérimentaux

Gateway API v1.6 introduit également une séparation propre entre les API stables et expérimentales. Les ressources expérimentales migrent vers un API group distinct : gateway.networking.x-k8s.io, avec un préfixe X explicite. Les ressources stables restent dans gateway.networking.k8s.io.

Cette séparation est une dette technique remboursée. Dans les versions précédentes, une même ressource pouvait avoir des champs stables et des champs expérimentaux dans le même objet — ce qui créait de la confusion sur ce qui était garanti de survivre aux montées de version. Désormais, un administrateur qui lit un manifeste sait immédiatement si la ressource qu’il déploie est stable (pas de X, pas de x-k8s.io) ou expérimentale.

Le corollaire est que v1alpha2 est déprécié pour TCPRoute et UDPRoute. Les clusters qui utilisaient encore la version alpha doivent migrer vers v1 avant la suppression prévue dans une future release. La migration est mécanique : l’API est identique, seul le groupe et la version changent.

Ce que ça change pour les architectures existantes

Le passage de TCPRoute et UDPRoute en Standard a trois implications concrètes pour les équipes plateforme :

1. Convergence des points d’entrée. Une seule Gateway peut désormais exposer HTTP, HTTPS, TCP et UDP simultanément. Finis les LoadBalancers séparés pour l’API REST et la base de données — tout passe par le même point d’entrée, avec des politiques de trafic unifiées.

2. Portabilité inter-contrôleurs. Un TCPRoute écrit pour Envoy Gateway fonctionne avec Istio, Cilium ou NGINX Gateway Fabric sans modification. C’est le contrat de la Gateway API : l’infrastructure as code devient portable, les contrôleurs deviennent interchangeables.

3. Fin des Services « fourre-tout ». Les équipes qui utilisaient un Service LoadBalancer unique avec plusieurs ports pour exposer à la fois leur API HTTP et leur base de données peuvent désormais utiliser une Gateway unique avec plusieurs listeners — un modèle plus lisible, plus auditable et plus facile à sécuriser.

Verdict

Gateway API v1.6 ne fait pas autant de bruit que la sortie d’un nouveau contrôleur ou d’une fonctionnalité serverless, mais c’est une release de maturité. Elle ferme la dernière grande lacune fonctionnelle du standard — le routage L4 — et établit des frontières propres entre ce qui est stable et ce qui ne l’est pas.

Si vous déployez des workloads non-HTTP sur Kubernetes, votre plan d’action est simple : testez TCPRoute et UDPRoute sur votre contrôleur Gateway actuel en environnement de staging, et planifiez la migration de vos v1alpha2 vers v1 avant que la version alpha ne soit retirée. La Gateway API est désormais le standard complet que la communauté promettait depuis 2022.

Références

• Kubernetes Blog, « Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard », 3 août 2026.
• Gateway API Specification, GEP-2644 (TCPRoute) et GEP-2645 (UDPRoute).
• Kubernetes SIG Network, « Gateway API v1.6.0 Release », 30 juin 2026.