Gateway API 1.6 fait passer TCPRoute et UDPRoute dans le canal Standard et l’API v1. Les équipes Kubernetes disposent enfin d’un modèle portable et stable pour router des protocoles de couche 4 comme les bases de données, DNS, VoIP, jeux ou télémétrie IoT, sans dépendre d’une ressource personnalisée propre à chaque contrôleur.

La version sépare également plus nettement l’innovation expérimentale. Les futures ressources non stabilisées rejoignent le groupe gateway.networking.x-k8s.io et prennent un préfixe X. Ce changement rend le niveau de maturité visible dans le nom de l’API, mais oblige les plateformes qui testent ces ressources à suivre leurs manifestes avec attention.

La réponse rapide

QuestionRéponse
Qu’est-ce qui devient stable ?TCPRoute et UDPRoute passent dans gateway.networking.k8s.io/v1.
Quels usages sont visés ?Flux TCP ou UDP sans compréhension applicative : base de données, DNS, VoIP, jeu, IoT.
Faut-il supprimer les Services ?Non. Les routes envoient toujours le trafic vers des Services ou autres backends.
v1alpha2 disparaît-il immédiatement ?Il est déprécié en 1.6 et sera retiré dans une version future.
Peut-on migrer sans test du contrôleur ?Non. Le support et la conformité varient selon l’implémentation et sa version.

Une route portable pour les protocoles bruts

Gateway API possédait déjà un socle stable pour HTTP et TLS. Le trafic TCP ou UDP brut restait souvent exposé par un Service de type LoadBalancer ou une CRD du fournisseur. Cette dernière solution rendait la configuration difficile à transférer entre NGINX, Traefik, GKE Gateway ou un autre contrôleur.

TCPRoute associe un listener TCP d’un Gateway à un backend selon le port, sans examiner le protocole applicatif. UDPRoute suit le même modèle. Une plateforme peut ainsi séparer la propriété de l’infrastructure Gateway, détenue par l’équipe réseau, de celle des routes, gérée par les équipes applicatives.

Le passage en Standard signifie que la forme de l’API, les comportements principaux et les tests de conformité ont atteint un niveau adapté à la production. Il ne garantit pas que toutes les extensions de chaque contrôleur se comportent de la même façon.

Ce que cela change pour les bases et services internes

Une base PostgreSQL, un broker ou un serveur de jeu peut partager une infrastructure Gateway avec d’autres flux tout en conservant un listener distinct. Les droits Kubernetes peuvent autoriser une équipe à attacher une route à certains listeners sans lui permettre de modifier l’adresse publique ou les certificats globaux.

Le modèle facilite la standardisation des manifestes, mais il ne remplace pas les contrôles réseau. Une route TCP ne chiffre pas automatiquement la connexion, n’authentifie pas le client et ne crée pas une politique NetworkPolicy. Le protocole transporté doit toujours fournir TLS lorsque nécessaire, et le cluster doit limiter les communications latérales.

Pour UDP, l’absence de connexion rend l’observabilité et l’équilibrage plus délicats. Les délais d’expiration, l’affinité et la gestion des paquets dépendent encore fortement du contrôleur et du fournisseur réseau.

L’expérimental change d’adresse

Jusqu’à présent, les ressources expérimentales partageaient gateway.networking.k8s.io avec les API standard, leur version alpha signalant la différence. À partir de la nouvelle organisation, elles utilisent gateway.networking.x-k8s.io et un nom préfixé par X, comme XBackend ou XMesh.

Cette séparation évite qu’une ressource instable ressemble à une API durable dans des inventaires ou politiques. Lorsqu’elle se stabilise, elle doit changer de groupe et perdre son préfixe, ce qui implique une migration explicite. Les outils GitOps et générateurs de politiques doivent donc reconnaître les deux groupes.

Un plan de migration prudent

Commencez par inventorier les TCPRoute et UDPRoute en v1alpha2, ainsi que les CRD propriétaires qui couvrent le même usage. Vérifiez ensuite que le contrôleur installé annonce la conformité Gateway API 1.6 pour ces ressources, et pas seulement une compatibilité générale avec Gateway API.

Installez les CRD 1.6 dans un environnement de test, convertissez un flux non critique et comparez adresses, ports, santé des backends et comportement lors d’un redémarrage. Testez aussi les refus : route non autorisée, namespace incorrect, backend absent et listener incompatible.

La bascule de production doit conserver un chemin de retour. Deux ressources ne peuvent pas toujours écouter le même port simultanément ; il peut être nécessaire de préparer un second Gateway ou une adresse temporaire, valider puis déplacer le DNS.

La conformité ne supprime pas les différences de produit

Gateway API dispose d’une suite de tests de conformité. Les implémentations peuvent toutefois supporter des profils et fonctionnalités optionnelles différents. Les annotations de fournisseur, politiques de timeout, métriques et intégrations WAF restent susceptibles de créer un verrouillage.

L’objectif raisonnable n’est pas une portabilité parfaite, mais un cœur standard lisible par toutes les équipes. Les extensions doivent être isolées et documentées afin que leur coût de migration soit visible.

Gateway API 1.6 comble un manque important entre le simple Service et les CRD réseau propriétaires. TCPRoute et UDPRoute peuvent désormais constituer le socle commun, à condition de tester le contrôleur réel et de ne pas confondre routage stable avec sécurité automatique.