Kubernetes Gateway API 1.7 promeut les retries HTTPRoute au canal Standard
Le 29 octobre 2026, la Gateway API Kubernetes livre sa version 1.7.0 : la configuration des retries HTTPRoute passe au canal Standard, pendant que le tracing distribué, les filtres de pré-routage et la persistance de session arrivent en expérimental. Les équipes qui exposent du trafic via plusieurs implémentations de gateway doivent reprendre leurs annotations de retry et leur politique de télémetrie avant la montée de version.
29 octobre 2026. La Gateway API de Kubernetes livre sa version 1.7.0, un cycle sans API « core » nouvelle mais qui fait bouger deux lignes : les retries HTTPRoute (GEP-1731) passent au canal Standard, et le tracing distribué (GEP-4768) entre en expérimental sous le nom XTelemetryPolicy. 29 octobre 2026, même jour. Le même cycle promeut quatre autres propositions expérimentales — filtres de pré-routage, persistance de session, routabilité d’adresse de Gateway, ClusterTrustBundle dans les références de certificats. 29 octobre 2026, toujours. Les breaking changes restent cantonnés au canal expérimental, mais ils touchent les APIs SessionPersistence et XBackend. L’essentiel tient en une phrase : pour la première fois, la façon dont une requête échouée est rejouée devient un comportement portable d’une implémentation de gateway à l’autre.
Pour une équipe plateforme, cette version n’est pas qu’une liste de GEP. C’est le moment où les retries — l’un des réglages les plus sensibles du trafic nord-sud — cessent d’être un contrat implicite pour devenir un champ de l’API.
Pourquoi la promotion des retries change la donne
Depuis l’origine de la Gateway API, la famille d’objets HTTPRoute décrit quoi router, mais pas toujours comment le trafic doit se comporter en cas d’échec. Les retries dépendaient d’annotations propres à chaque contrôleur : Istio, Cilium, Kong, NGINX Gateway Fabric ou Traefik ne rejouaient pas les requêtes de la même façon, avec des codes et des politiques de backoff différents.
La v1.7.0 change ce contrat. La configuration des retries d’une règle HTTPRoute — retry.codes, retry.attempts et retry.backoff — est promue au canal Standard, avec les tests de conformité associés (HTTPRouteRetryCodes et HTTPRouteRetryConnectionError). Deux nuances comptent pour l’exploitant. D’abord, retry.attempts prend la valeur par défaut 1 et son minimum descend de 1 à 0, ce qui permet de désactiver les retries règle par règle. Ensuite, le champ backoff reste « implementation-specific » : sa précision — et surtout son jitter — varie d’une implémentation à l’autre, précisément pour éviter les rafales synchronisées de rejeu qui transforment une panne en tempête.
Le gain est concret : une équipe qui normalise ses routes sur la Gateway API peut désormais décrire la politique de retry dans le manifeste, la porter d’un fournisseur à l’autre, et s’appuyer sur des tests de conformité pour vérifier que l’implémentation fait ce qui est écrit. C’est la première brique de fiabilité du trafic qui traverse le canal Standard — pas la dernière.
L’expérimental qui dessine la suite
Le reste de la version prépare le terrain, et trois pistes méritent l’attention.
Le tracing distribué, via XTelemetryPolicy (GEP-4768). La politique normalise la configuration du tracing des Gateway sans CRD propre à un fournisseur, sur la base des conventions sémantiques OpenTelemetry. Les métriques et les journaux d’accès ne sont pas encore couverts — la proposition est explicitement limitée au tracing — mais c’est le premier pas vers une observabilité standardisée au niveau de la gateway, le maillon où la visibilité manque le plus aujourd’hui.
Les filtres de pré-routage (GEP-5224). Avec GatewayListenerFilters, des filtres s’exécutent avant la décision de routage : authentification externe, traitement de charge utile. Ils s’appliquent à la fois aux Gateway et aux ListenerSet. C’est la réponse à un besoin récurrent — brancher un contrôle d’accès avant même de choisir le backend — qui passait par des hacks de contrôleur.
La persistance de session et la routabilité. La persistance de session migre sur la ressource XBackend (GEP-1619 et GEP-4894), les points d’attache inline et BackendTrafficPolicy étant dépréciés. La routabilité d’adresse (GEP-5093) s’exprime désormais par adresse de Gateway, une même Gateway pouvant servir des adresses de portées différentes. Enfin, caCertificateRefs peut référencer un ClusterTrustBundle (GEP-5075) au lieu de recopier des CA dans chaque namespace.
Un dernier détail logistique : les artefacts de release contiennent désormais les schémas OpenAPIv2, ce qui facilite l’intégration dans les pipelines de validation.
Les breaking changes, et pourquoi ils ne devraient pas vous réveiller la nuit
La liste des changements cassants est réelle mais circonscrite au canal expérimental. L’API SessionPersistence est restructurée : sessionName se scinde en cookie.name et header.name, cookieConfig devient cookie, et le chemin du cookie prend par défaut / au lieu d’être déduit des matches de route. L’API XBackend renomme spec.port.port en spec.port.number, supprime spec.port.name, et interdit backendRef.port quand on référence un XBackend. Côté types Go, BackendAncestorStatus.AncestorRef est renommé et ForwardBodyConfig.MaxSize passe de uint16 à int32.
Le point de vigilance est simple : tout ceci ne touche que des champs expérimentaux. Un cluster qui n’active pas les feature gates correspondants ne voit rien changer au passage en 1.7.0. En revanche, les équipes qui ont déjà adopté XBackend ou la persistance de session en bêta doivent relire leurs manifests avant la montée de version, car la sémantique a bougé sans crier gare.
Le cycle embarqué est par ailleurs à jour : Go 1.27, et les dépendances Kubernetes alignées sur v0.37. Du côté de l’écosystème, Envoy Gateway passe Conformant, HAProxy Ingress est renommé N42 Gateway, et la liste des rapports de conformité s’allonge — Cilium, Istio, Kong, Traefik, NGINX Gateway Fabric, Linkerd, GKE Gateway et d’autres sont à jour.
Ce qu’il faut faire maintenant
La montée de version est mécanique, mais trois vérifications évitent des surprises.
- Reprendre vos annotations de retry. Si vous doubliez la Gateway API d’annotations propres au contrôleur pour gérer les retries, c’est le moment de les migrer vers les champs standard
retry.codesetretry.attemptsd’HTTPRoute. - Tester la télémetrie en lab.
XTelemetryPolicyest expérimental : activez le feature gate sur un cluster de test et mesurez si les spans couvrent bien la traversée de la gateway avant de généraliser. - Auditer les champs expérimentaux. Inventoriez vos usages de SessionPersistence et XBackend ; les renommages de champs sont silencieux au niveau de la compilation tant que rien ne valide vos manifests.
- Vérifier la conformité de votre implémentation. La promotion des retries ajoute des tests de conformité : consultez le rapport de votre fournisseur pour savoir s’il implémente déjà le nouveau canal.
Rien de tout cela ne bloque une simple mise à jour. Mais un parc qui a normalisé ses routes sur plusieurs contrôleurs sans auditer les annotations risque de voir des politiques de retry diverger précisément là où il pensait les avoir unifiées.
Verdict
La Gateway API 1.7 se juge à une bascule : les retries HTTPRoute deviennent un contrat portable, et le tracing distribué devient un sujet de standard. Si vous exploitez plusieurs implémentations de gateway sur un même cluster, la migration vers les champs de retry standard vaut la montée de version dès maintenant — c’est de la fiabilité que vous gagnez sans dépendre d’un fournisseur. Si vous êtes sur une implémentation unique, l’urgence est moindre, mais préparez déjà l’audit de vos champs expérimentaux : la prochaine promotion au Standard, très probablement du côté de la télémetrie, ne préviendra pas deux fois.