L’API Gateway Kubernetes v1.6 hisse TCPRoute et UDPRoute au standard et sépare les APIs expérimentales
TCPRoute et UDPRoute passent en canal Standard dans Gateway API v1.6, comblant le dernier trou noir pour les bases de données, le DNS et la VoIP sur Kubernetes. La nouvelle ressource XBackend et la séparation du groupe API expérimental redessinent la feuille de route du réseau cloud-native.
3 août 2026 — La communauté SIG Network de Kubernetes a annoncé la sortie de Gateway API v1.6.0, effective depuis le 30 juin 2026. Deux ressources passent en canal Standard avec l’API v1 : TCPRoute et UDPRoute. Jusqu’ici, seules les routes HTTP et TLS bénéficiaient d’une stabilité garantie ; le routage de couche 4 brute — bases de données, DNS, VoIP, gaming, télémétrie IoT — devait se contenter de Services Kubernetes classiques ou de CRD propriétaires liées à un contrôleur Gateway spécifique. Cette version change la donne pour toutes les équipes plateforme qui veulent un plan de contrôle réseau unifié.
TCPRoute et UDPRoute : le standard que le L4 attendait
Le problème était connu depuis la v1.0 de Gateway API : le modèle de routage standard ne couvrait que HTTP et TLS. Une base PostgreSQL, un résolveur CoreDNS interne, un serveur Minecraft ou un relais MQTT — tout ce qui parle un protocole brut sur TCP ou UDP — n’avait aucun moyen portable de se brancher sur une Gateway.
TCPRoute et UDPRoute ferment ce trou. Les deux ressources routent le trafic vers des backends sur la base du protocole et du port, sans aucune inspection de la couche 7. Leur graduation en canal Standard signifie que les contrôleurs conformes (NGINX Gateway Fabric, Traefik Proxy, GKE Gateway, kgateway, Airlock Microgateway, Agentgateway) garantissent un comportement identique, quel que soit l’implémenteur.
Le modèle est simple. Une Gateway déclare un listener TCP :
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: db-gateway
spec:
gatewayClassName: nginx
listeners:
- name: postgres
protocol: TCP
port: 5432
allowedRoutes:
kinds:
- kind: TCPRouteUne TCPRoute s’attache à ce listener et forwarde le trafic vers le Service backend :
apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
name: postgres-route
spec:
parentRefs:
- name: db-gateway
sectionName: postgres
rules:
- backendRefs:
- name: postgres-primary
port: 5432UDPRoute suit exactement le même patron — remplacez le protocole du listener par UDP et le kind par UDPRoute. Le trafic arrivant sur le port 5432 de la Gateway est proxyfié vers les endpoints de postgres-primary.
Ce que ça change pour les équipes plateforme. Avant la v1.6, exposer une base de données hors du cluster passait soit par un Service de type LoadBalancer (un par base, facturé au prix fort chez les hyperscalers), soit par une CRD spécifique au contrôleur (non portable). Désormais, une seule Gateway peut agréger les listeners TCP et UDP aux côtés des routes HTTP et TLS existantes — un seul point d’entrée, un seul certificat TLS quand le protocole le permet, une seule surface de monitoring.
XBackend : le chaînon manquant pour l’egress
La v1.6 introduit XBackend, une nouvelle ressource expérimentale dans le groupe API gateway.networking.x-k8s.io. Son cas d’usage immédiat : les destinations ExternalHostname, qui étaient exclues du support Service dans Gateway API à cause du risque d’attaques de type confused deputy.
Une XBackend permet de déclarer proprement une destination externe — par exemple, l’API d’un fournisseur d’IA cloud :
apiVersion: gateway.networking.x-k8s.io/v1alpha1
kind: XBackend
metadata:
name: ai-provider-api
namespace: ai-apps
spec:
type: ExternalHostname
externalHostname:
hostname: api.ai-provider.comCette XBackend est ensuite référencée par une HTTPRoute standard, avec le TLS de la Gateway qui reste le point d’autorité pour les connexions sortantes. Pour les charges de travail agentiques — ces agents IA autonomes qui tournent dans le cluster et appellent des APIs externes — c’est le motif d’egress qui manquait cruellement.
La communauté travaille par ailleurs à déplacer la configuration de Session Persistence depuis XBackendTrafficPolicy vers XBackend, et prévoit d’ajouter le support des retries, de la terminaison TLS et d’autres configurations utiles à définir par application plutôt que par route.
Séparation du groupe API expérimental : X marque le spot
Avant la v1.6, les ressources expérimentales partageaient le même groupe API que les ressources stables — gateway.networking.k8s.io — et n’étaient distinguées que par une version v1alpha2. TCPRoute et UDPRoute sont les dernières à avoir emprunté ce chemin.
Désormais, toute nouvelle ressource expérimentale est définie dans le groupe gateway.networking.x-k8s.io et son nom reçoit un préfixe X : XBackend, et bientôt XMesh (qui deviendra Mesh après graduation). La séparation est nette : quand une ressource expérimentale passe en Standard, elle migre dans le groupe stable et perd son préfixe X. Les opérateurs de cluster savent immédiatement, au niveau du groupe API, si une ressource est couverte par la garantie de stabilité ou non.
La conformité à v1.6 : six contrôleurs prêts le jour J
Gateway API s’appuie sur une suite de tests de conformité exhaustive pour garantir un comportement portable à travers les implémentations. Le jour de la publication, six contrôleurs étaient conformes v1.6 :
- Agentgateway — le contrôleur léger orienté edge
- Airlock Microgateway — sécurité et filtrage fin
- GKE Gateway — l’implémentation native Google Cloud
- kgateway — le successeur moderne d’Envoy Gateway
- NGINX Gateway Fabric — le standard de fait pour l’ingress NGINX
- Traefik Proxy — le couteau suisse du reverse-proxy
La liste est plus courte qu’en v1.5 (qui comptait aussi Istio et Contour), conséquence directe de l’ajout de TCPRoute et UDPRoute au périmètre de conformité. Les contrôleurs qui ne supportaient pas le routage L4 doivent désormais l’implémenter pour conserver leur badge de conformité — une pression saine vers la complétude de l’écosystème.
Ce que ça signifie pour vos clusters en production
Gateway API v1.6 n’est pas une release cosmétique. Elle change le périmètre de ce que vous pouvez traiter avec une Gateway unique :
- Bases de données : une Gateway avec un listener TCP
5432+ TCPRoute remplace le LoadBalancer dédié à PostgreSQL. - DNS interne : un listener UDP
53+ UDPRoute expose CoreDNS sans passer par kube-proxy. - VoIP et gaming : les flux UDP temps réel bénéficient de la même fiabilité que le trafic HTTP.
- Agents IA : XBackend + HTTPRoute forment un motif d’egress sécurisé vers les APIs externes.
Le verdict est conditionnel mais clair : si vous gérez plus de trois Services de type LoadBalancer pour des protocoles non-HTTP, passez à Gateway API v1.6 dès que votre contrôleur est conforme. Le coût de la migration est une poignée de manifests YAML ; le gain est la consolidation de votre surface réseau sur un seul plan de contrôle.
Si votre contrôleur n’a pas encore de support L4 standard, la pression de la conformité v1.6 devrait accélérer son adoption. Surveillez les rapports de conformité sur le repo Gateway API.