L’après Ingress NGINX

Si votre cluster route encore le trafic via ingress-nginx, vous exploitez un logiciel dont plus personne ne corrige les défauts. Le dépôt a été archivé le 24 mars 2026. Il n’y aura plus de release, plus de correction de bug et — c’est le point qui compte — plus aucun correctif de sécurité, pour aucune vulnérabilité, jamais. Rien n’a cassé ce jour-là, et c’est précisément le problème : votre ingress fonctionne toujours, donc rien ne vous a forcé à agir.

Ce guide est écrit après l’échéance, pas avant. Il montre comment mesurer votre exposition en quatre commandes, comment choisir une destination sur preuves plutôt qu’au ressenti, quels comportements d’ingress-nginx changent silencieusement de sens une fois traduits, et une séquence de déploiement qui vous laisse remettre le trafic en arrière si le nouveau plan de données se comporte mal.

Ce qui s’est réellement passé — et ce qui n’a pas eu lieu

La chronologie est courte et mérite d’être exacte, car beaucoup de commentaires de seconde main l’ont déformée. Le SIG Network de Kubernetes et le Security Response Committee ont annoncé le retrait le 11 novembre 2025. Le 29 janvier 2026, le Steering Committee et le SRC ont haussé le ton dans une déclaration commune d’une franchise inhabituelle : rester sur Ingress NGINX après son retrait vous expose, vous et vos utilisateurs, à une attaque, et aucune des alternatives disponibles n’est un remplaçant direct.^{[retire][steering]}

C’est la dernière ligne qui est le plus souvent mal lue. L’API Ingress n’est pas dépréciée. La documentation indique qu’elle est en disponibilité générale, que le projet n’a aucun plan pour la supprimer, et qu’elle est simplement gelée : plus de changements ni de mises à jour. Vos objets Ingress en networking.k8s.io/v1 sont du Kubernetes valide et le resteront. Ce qui est mort, c’est un contrôleur particulier qui les lit.^[ingressdoc]

Ce que vous héritez en restant

La façon la plus claire de dimensionner le risque est de regarder les correctifs de sécurité publiés par le projet dans ses dernières semaines. Le 2 février 2026 — quatre jours après la déclaration du Steering, sept semaines avant le passage du dépôt en lecture seule — le SRC a divulgué quatre vulnérabilités dans ingress-nginx : CVE-2026-1580, CVE-2026-24512, CVE-2026-24513 et CVE-2026-24514. Les plus graves ont été classées HIGH à 8,8, corrigées en v1.13.7 et v1.14.3.^[advisory]

CVE-2026-24512 est celle à intégrer. Le champ rules.http.paths.path d’un Ingress permettait d’injecter de la configuration dans NGINX, menant à l’exécution de code arbitraire dans le contexte du contrôleur et à la divulgation de tous les Secrets que le contrôleur peut lire — soit, dans une installation par défaut, tous ceux du cluster. La mitigation intérimaire consistait en un validating admission controller rejetant les Ingress dont le path type est ImplementationSpecific. Notez ce que cette classe de faille exige de l’attaquant : pouvoir créer un Ingress. Toute personne disposant d’un droit d’écriture sur un namespace remplit la condition.^[cve24512]

Deux autres ont suivi, et ce sont elles qui bouclent l’argument. CVE-2026-3288, divulguée le 9 mars 2026 et classée HIGH à 8,8, était une injection de configuration via l’annotation rewrite-target — celle-là même dont le tableau de sémantique plus bas vous avertit — corrigée en v1.13.8, v1.14.4 et v1.15.0. Puis CVE-2026-4342, divulguée le 19 mars 2026, à 8,8 avec le même vecteur : injection de configuration via les commentaires, menant là encore à l’exécution de code dans le contrôleur et à la divulgation des Secrets de tout le cluster. Elle a été corrigée en v1.13.9, v1.14.5 et controller-v1.15.1. Soit la version finale. La dernière chose que ce projet ait jamais publiée est un correctif de sécurité, cinq jours avant le passage du dépôt en lecture seule. Ce qui viendra ensuite n’aura rien.^{[cve3288][cve4342][lastrel]}

Pour la borne haute, le précédent est CVE-2025-1974 — « IngressNightmare », mars 2025, CVSS 9,8. Le projet Kubernetes l’a décrite sans détour : n’importe quoi sur le réseau de pods avait de bonnes chances de prendre le contrôle du cluster, sans aucune authentification. Celle-là a eu un correctif. La prochaine n’en aura pas.^[nightmare]

Les déploiements existants continueront de fonctionner : si vous ne vérifiez pas de manière proactive, vous ne saurez peut-être pas que vous êtes concerné avant d’être compromis.^[steering]

Sur l’échelle : le Steering Committee et le SRC affirment qu’environ 50 % des environnements cloud native dépendent de ce contrôleur, en citant des travaux internes de Datadog. Prenez ce chiffre comme un ordre de grandeur et non comme une mesure — le jeu de données n’est pas public et reflète les environnements supervisés par Datadog — mais il est corroboré par la propre estimation du projet en 2025: « plus de 40 % des clusters Kubernetes ». Dans tous les cas, ce n’est pas un chantier marginal.

Savoir si vous êtes concerné

Avant de planifier quoi que ce soit, mesurez. La première commande est celle que publie le projet Kubernetes lui-même ; les trois autres vous disent la charge réelle, car le coût de cette migration n’est pas le nombre d’objets Ingress, mais le nombre d’annotations distinctes derrière eux.

# 1. The check the Kubernetes project itself publishes
kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

# 2. Which controller image, and therefore which version, is actually running
kubectl get deploy -A -l app.kubernetes.io/name=ingress-nginx \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}'

# 3. How much surface you have to translate: every Ingress bound to it
kubectl get ingress -A \
  -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.spec.ingressClassName}{"\n"}{end}'

# 4. The real cost driver - the annotations, ranked by how often you use them
kubectl get ingress -A -o json \
  | jq -r '.items[].metadata.annotations // {} | keys[]' \
  | grep -F 'nginx.ingress.kubernetes.io/' | sort | uniq -c | sort -rn

La quatrième commande est l’estimation. Un cluster avec soixante Ingress et quatre annotations, c’est un après-midi. Un cluster avec douze Ingress et vingt-deux annotations — dont configuration-snippet — c’est un projet, et vous venez de comprendre pourquoi.

Choisir la destination avant de toucher au moindre YAML

Il y a trois options honnêtes, et la bonne dépend de votre degré réel de dépendance au comportement d’ingress-nginx. À savoir avant d’établir une liste courte : les seuls Ingress Controllers que Kubernetes supporte et maintient en tant que projet sont ceux d’AWS et de GCE. Tout le reste de la liste documentée — Traefik, HAProxy, Contour, Kong, APISIX, Cilium, Higress, Istio et les autres — est tiers. Notez aussi que kubernetes/ingress-nginx ne figure plus du tout sur cette page.^[ctrldoc]

Si vous partez sur la Gateway API, la version courante est la v1.6.0, taguée fin juin 2026 et annoncée le 3 août 2026. TCPRoute et UDPRoute y sont passées d’Experimental à Standard en v1, rejoignant Gateway, GatewayClass, HTTPRoute, GRPCRoute, TLSRoute, ListenerSet, ReferenceGrant et BackendTLSPolicy. Les versions v1alpha2 de TCPRoute et UDPRoute sont dépréciées depuis la v1.6 et seront supprimées. Installez le correctif courant, la v1.6.1 du 16 juillet 2026, et non la v1.6.0. Côté versions de cluster, le projet ne publie pas de plancher fixe : sa politique annoncée est de prendre en charge les cinq versions mineures les plus récentes de Kubernetes. Vérifiez cette politique face à votre cluster plutôt que de vous fier à un chiffre lu dans un billet de blog.^{[gw16][gw16rel][gw161][versioning]}

Un changement structurel de la v1.6 mérite d’être anticipé : les nouvelles ressources expérimentales vivent désormais dans un groupe d’API distinct, gateway.networking.x-k8s.io, avec un préfixe X sur le nom du type — XBackend, XMesh. Lorsqu’une ressource est promue, elle est renommée dans gateway.networking.k8s.io et perd le préfixe. Le signal est délibéré : si le kind dont vous allez dépendre commence par X, ce n’est pas un engagement de production.^[gw16]

Choisissez sur preuves. Le projet Gateway API publie, pour chaque release, des rapports de conformité indiquant exactement combien de fonctionnalités étendues chaque implémentation valide, par type de route. Ce tableau est un meilleur outil de présélection que n’importe quelle page comparative d’éditeur, celle-ci comprise — consultez la ligne de la version que vous comptez exécuter, pas celle de l’an dernier. Attention toutefois : toutes les implémentations ne soumettent pas de rapport à chaque version. Une ligne absente signifie « pas de rapport pour cette version », pas « non conforme ».^[conform]

Une remarque, parce que la question tombe systématiquement en France : pourquoi pas Traefik ? C’est une réponse légitime, et une implémentation conforme de la Gateway API — mais vérifiez le rapport de conformité de la version que vous visez plutôt que de vous fier à la réputation, car le nombre de fonctionnalités étendues validées varie fortement d’une implémentation à l’autre, y compris pour GRPCRoute et TLSRoute. Si vous êtes sur un Kubernetes managé chez un hébergeur européen, commencez par la question qui contraint tout le reste : quel contrôleur votre fournisseur propose-t-il, et sur quelle version de la Gateway API est-il certifié ? Dans la pratique, c’est le cycle de mise à jour de la plateforme qui fixe le rythme de la migration, pas votre backlog.

Cinq comportements qui ne survivent pas à la traduction

C’est là que les migrations dérapent, et la section vaut la lecture même si votre destination est déjà arrêtée. ingress-nginx a accumulé des comportements qui n’ont jamais figuré dans la spécification Ingress, dont vos applications dépendent aujourd’hui sans le dire, et qu’aucune implémentation conforme de la Gateway API ne reproduit. Le projet Kubernetes en a documenté cinq précisément pour éviter cette découverte à ses utilisateurs.^[gotchas]

En pratique, c’est la redirection de slash final qui fait le plus mal, parce qu’elle n’échoue pas bruyamment. Les requêtes vers /api qui étaient redirigées vers /api/ renvoient maintenant un 404 depuis l’application, et l’erreur apparaît dans les logs de votre service et non en bordure — la première hypothèse est donc un bug applicatif, pas la migration de la veille.

ingress2gateway : ce qu’il convertit, et ce qu’il refuse

Il existe un convertisseur officiel, et il s’est beaucoup amélioré. ingress2gateway a atteint la 1.0 le 20 mars 2026 en tant que sous-projet du SIG Network. Le changement principal : la couverture des annotations ingress-nginx est passée de trois à plus de trente, dont CORS, TLS vers le backend, correspondance par regex et réécriture de chemin. La 1.0 a également ajouté des tests d’intégration au niveau contrôleur, qui déploient un vrai ingress-nginx et un vrai contrôleur Gateway API dans des clusters réels et comparent leur comportement à l’exécution, au lieu de simplement comparer du YAML.^[i2gblog]

# Install the official converter (Go 1.25.5 or newer to build from source)
go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0
# or: brew install ingress2gateway

# Convert a manifest on disk, without touching the cluster
ingress2gateway print --input-file ingress.yaml \
  --providers=ingress-nginx > gwapi.yaml

# Convert one namespace from a live cluster
ingress2gateway print --namespace shop \
  --providers=ingress-nginx > gwapi.yaml

# Convert everything, and keep the warnings - they are the migration backlog
ingress2gateway print --all-namespaces \
  --providers=ingress-nginx > gwapi.yaml 2> unsupported.log

Neuf providers sont pris en charge — ingress-nginx, nginx, traefik, kong, istio, apisix, cilium, gce et openapi — avec six émetteurs de sortie, dont envoy-gateway et kgateway. Sa sortie cible la Gateway API v1.5.0. Ce qu’il ne fera pas à votre place :^[i2g]

• configuration-snippet et server-snippet — non pris en charge, et aucun équivalent n’existe. Les directives NGINX arbitraires sont exactement le choix de conception que le projet Kubernetes a désigné comme source d’une « dette technique insurmontable ». Si vos snippets encodent de la logique métier, cette logique doit remonter dans l’application, dans un filtre ou dans un CRD de politique spécifique à l’implémentation.^[retire]
• proxy-body-size — aucun équivalent Gateway API. Configurez-le sur le plan de données, ce qui le rend spécifique à l’implémentation et non portable.
• proxy-read-timeout / proxy-send-timeout — correspondance au mieux vers timeouts.request, ce qui n’est pas la même chose. Remesurez sous charge au lieu de présumer la parité.
• Normalisation d’URL — pas configurable via la Gateway API standard. Si vous vous appuyiez dessus, vous vous appuyiez sur le plan de données, et il faut le vérifier implémentation par implémentation.

Lisez les avertissements de l’outil comme votre backlog de migration, pas comme du bruit. Tout ce qu’il écrit sur stderr est un comportement qu’il n’a pas pu transposer, et chacun d’eux est un incident de production qui attend le changement de DNS.

Ingress et Gateway API, côte à côte

Un exemple minimal mais réaliste : un hostname, du TLS et un chemin partagé entre une API et un front web. Les mettre côte à côte a un intérêt : la version Gateway API est plus longue, et cette longueur n’est pas du cérémonial — c’est le comportement qu’ingress-nginx vous fournissait implicitement, désormais écrit.

Avant — un Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
  namespace: shop
spec:
  ingressClassName: nginx
  tls:
    - hosts: [shop.example.com]
      secretName: shop-example-com-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Après — un Gateway et deux HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shop-gateway
  namespace: shop
spec:
  gatewayClassName: nginx          # must match an installed GatewayClass
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: shop.example.com
      allowedRoutes:
        namespaces:
          from: Same
    - name: https
      protocol: HTTPS
      port: 443
      hostname: shop.example.com
      tls:
        mode: Terminate
        certificateRefs:
          - group: ""              # empty string = core API group
            kind: Secret
            name: shop-example-com-tls
      allowedRoutes:
        namespaces:
          from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route
  namespace: shop
spec:
  parentRefs:
    - name: shop-gateway
      sectionName: https
  hostnames: [shop.example.com]
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: web-service
          port: 80
---
# ingress-nginx redirected HTTP to HTTPS for you. Gateway API does not.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route-ssl-redirect
  namespace: shop
spec:
  parentRefs:
    - name: shop-gateway
      sectionName: http
  hostnames: [shop.example.com]
  rules:
    - filters:
        - type: RequestRedirect
          requestRedirect:
            scheme: https
            statusCode: 308

Trois points à relever. sectionName lie la route à un listener précis : c’est ainsi que vous gardez les comportements HTTP et HTTPS séparés. allowedRoutes est la séparation des rôles que l’API Ingress n’a jamais eue : une équipe plateforme possède le Gateway et décide quels namespaces peuvent s’y rattacher, tandis que les équipes applicatives possèdent leurs HTTPRoute. Et le troisième objet n’existe que pour reproduire une redirection qu’ingress-nginx effectuait par défaut — ce qui résume assez bien toute la migration.^[gwapi]

Une bascule que vous pouvez vraiment annuler

La propriété la plus utile de cette migration, c’est que les deux contrôleurs peuvent tourner en même temps. Ce sont des objets différents, qui observent des ressources différentes, derrière des load balancers différents. Rien n’impose une bascule d’un bloc — n’en faites donc pas.

1. Installez le nouveau contrôleur à côté de l’ancien. GatewayClass distincte, namespace distinct, son propre Service LoadBalancer et sa propre adresse externe. Le trafic continue d’aller vers ingress-nginx.
2. Convertissez et relisez. Lancez ingress2gateway sur un namespace, lisez les avertissements et corrigez à la main les annotations non traduites. N’appliquez jamais la sortie sans l’avoir lue.
3. Appliquez les objets Gateway API avec les mêmes hostnames. Rien ne change encore pour les utilisateurs : le nouveau contrôleur a sa propre IP et aucun enregistrement DNS ne pointe dessus.
4. Comparez les deux bordures directement avec --resolve, requête par requête : codes de statut, cibles de redirection, en-têtes, et spécifiquement les cas de slash final et de regex. C’est l’étape qui attrape les cinq comportements ci-dessus.
5. Déplacez le DNS progressivement — enregistrement à faible TTL, politique pondérée, ou un hostname non critique en premier. Laissez ingress-nginx servir jusqu’à ce que la nouvelle bordure ait encaissé du trafic réel sur un pic.
6. Démantelez délibérément. Supprimez le Deployment ingress-nginx, son Service, son IngressClass et sa ValidatingWebhookConfiguration. Laisser traîner le webhook d’admission, c’est se retrouver avec un cluster cassé des semaines plus tard.

# Install the Standard channel CRDs (server-side apply, as the project documents)
kubectl apply --server-side -f \
  https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.1/standard-install.yaml

# The Gateway must be Programmed before you move any traffic to it
kubectl get gateway shop-gateway -n shop \
  -o jsonpath='{.status.conditions[?(@.type=="Programmed")].status}{"\n"}'

# Every parentRef must be Accepted, and every backendRef ResolvedRefs.
# Nested ranges keep each condition paired with its own status.
kubectl get httproute shop-route -n shop -o jsonpath='{range .status.parents[*]}{.controllerName}{"\t"}{range .conditions[*]}{.type}={.status}{" "}{end}{"\n"}{end}'

# Compare old and new on the same request, before DNS moves.
# A cloud load balancer publishes either .ip or .hostname - AWS uses .hostname,
# so --connect-to is used instead of --resolve: it accepts both.
OLD=$(kubectl get svc -n ingress-nginx ingress-nginx-controller \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}{.status.loadBalancer.ingress[0].hostname}')
NEW=$(kubectl get gateway shop-gateway -n shop \
  -o jsonpath='{.status.addresses[0].value}')
for edge in "$OLD" "$NEW"; do
  curl -sS -o /dev/null -w "$edge  %{http_code}  %{redirect_url}\n" \
    --connect-to "shop.example.com:443:$edge:443" https://shop.example.com/api
done

Notez la condition Programmed dans la deuxième commande. Un Gateway qui existe n’est pas un Gateway qui sert ; les conditions de statut sont le contrat, et les vérifier coûte moins cher que de découvrir la différence pendant le changement de DNS.

ingress-nginx, NGINX Ingress, NGINX Gateway Fabric

Trois projets distincts, des noms voisins, et une vraie source de mauvaises décisions pendant exactement cette migration. Certains migrent d’ingress-nginx vers « NGINX Ingress » en croyant avoir changé quelque chose, et déchantent plus tard — ou écartent NGINX en bloc en supposant que les trois sont morts ensemble.

Le projet Kubernetes a lui-même jugé nécessaire de l’écrire noir sur blanc : les deux utilisent NGINX comme plan de données, mais n’ont par ailleurs aucun lien. Passer du contrôleur communautaire à celui de F5 est une vraie migration, avec son propre travail de traduction d’annotations ; ce n’est pas un changement de nom.^[gotchas]

Ce que je ferais cette semaine

Si vous n’avez pas commencé : exécutez aujourd’hui les quatre commandes de détection, car le décompte d’annotations est le seul chiffre qui vous dit si c’est un après-midi ou un trimestre. Si la réponse est « un après-midi », faites-le cette semaine et cessez de porter le risque. Si c’est « un trimestre », le geste utile reste d’installer dès maintenant un second contrôleur en parallèle et de migrer un hostname sans enjeu : c’est à la première migration que vous découvrez lesquelles de vos hypothèses étaient en réalité des comportements d’ingress-nginx.

La leçon de fond, je l’ai déjà écrite dans les architectures cloud ennuyeuses : les composants les plus susceptibles de vous faire mal sont ceux auxquels personne ne pense, précisément parce qu’ils fonctionnent depuis des années. Un Ingress Controller maintenu par une ou deux personnes bénévoles, devant la moitié du monde cloud native, était une concentration de risque bien avant son archivage. Il vaut la peine d’auditer ce qui, ailleurs dans votre stack, a la même forme — et de se demander, comme dans quand ne pas utiliser Kubernetes, si la plateforme justifie la surface opérationnelle qu’elle vous coûte.

Questions fréquentes

Puis-je continuer à faire tourner ingress-nginx sans danger ?

Ça marche, et ça continuera de marcher. Mais il ne recevra plus jamais de correctif de sécurité — et il faut voir ce qu’était réellement la version finale : controller-v1.15.1 était le correctif de CVE-2026-4342, une injection de configuration allant jusqu’à l’exécution de code dans le contrôleur et la divulgation des Secrets de tout le cluster, publiée le jour même de l’avis et cinq jours avant le passage du dépôt en lecture seule. C’était la sixième faille de ce type en sept semaines. La prochaine n’aura pas de correctif. Si vous devez le garder quelques semaines, restreignez au minimum qui peut créer des Ingress, retirez au contrôleur l’accès aux Secrets à l’échelle du cluster si votre installation le lui accorde, et n’exposez pas le webhook d’admission.

L’API Ingress de Kubernetes est-elle dépréciée aussi ?

Non, et c’est le contresens le plus fréquent. L’API Ingress est en disponibilité générale, avec les garanties de stabilité habituelles du GA, et le projet Kubernetes a déclaré n’avoir aucun plan pour la supprimer. Elle est gelée : plus de développement. Seul le contrôleur NGINX communautaire a été retiré, pas l’API qu’il implémente.

Quelle différence entre ingress-nginx et nginx-ingress ?

Ce sont des projets différents portés par des organisations différentes. kubernetes/ingress-nginx était maintenu par la communauté Kubernetes et est archivé. nginx/kubernetes-ingress est le NGINX Ingress Controller de F5 et est activement développé. Selon les mots du projet Kubernetes lui-même : les deux utilisent NGINX comme plan de données, mais n’ont sinon aucun lien. Passer de l’un à l’autre est une vraie migration, pas un renommage.

ingress2gateway peut-il migrer mon cluster automatiquement ?

En partie. La version 1.0 couvre plus de trente annotations ingress-nginx, contre trois auparavant, et c’est le bon point de départ. Mais configuration-snippet n’a pas d’équivalent et n’est pas supporté, proxy-body-size n’a pas d’équivalent Gateway API, les timeouts de proxy ne sont mappés qu’au mieux, et la normalisation d’URL n’est pas exprimable du tout. Lisez tout ce qu’il écrit sur stderr : cette sortie est votre travail manuel restant.

Passer à la Gateway API ou simplement changer d’Ingress Controller ?

Changer de contrôleur est plus rapide et conserve vos objets existants, mais vous atterrissez sur une API gelée et vous devez tout de même ré-exprimer chaque annotation dans un nouveau dialecte : vous recommencerez probablement. La Gateway API est une réécriture plus lourde, mais c’est là que se fait le développement, et elle apporte la séparation des rôles entre l’équipe plateforme, propriétaire du Gateway, et les équipes applicatives, propriétaires de leurs routes. Les gros parcs d’Ingress simples plaident pour le changement de contrôleur ; les bordures partagées entre plusieurs équipes plaident pour la Gateway API.

Traefik est-il un bon remplaçant d’Ingress NGINX ?

C’est un choix légitime : Traefik supporte l’API Ingress et est une implémentation conforme de la Gateway API. Mais ne décidez pas sur la réputation. Consultez le rapport de conformité de la version que vous comptez déployer et comparez, ligne à ligne, les fonctionnalités étendues validées pour HTTPRoute, GRPCRoute et TLSRoute avec celles dans lesquelles vos annotations ingress-nginx ont été traduites. Le nombre de fonctionnalités validées varie fortement d’une implémentation à l’autre.

Faut-il mettre à jour Kubernetes avant d’installer la Gateway API ?

Le projet ne publie pas de version minimale fixe de Kubernetes ; sa politique annoncée est de prendre en charge les cinq versions mineures les plus récentes. Confrontez cette politique à votre cluster plutôt qu’à un chiffre lu dans un billet. Installez les CRD du canal Standard depuis le correctif courant — la v1.6.1 du 16 juillet 2026 — avec server-side apply, comme le documente le projet. Si vous installez le canal Experimental, ses CRD sont de toute façon trop volumineuses pour un kubectl apply côté client, et les types expérimentaux portent désormais un préfixe X dans un groupe d’API distinct, précisément pour que vous ne bâtissiez pas de la production dessus par accident.

La même discipline vaut pour la cryptographie en dessous : SSH et TLS post-quantiques détaille ce qu'il faut vérifier sur les connexions dont dépendent ces systèmes.

Sources

Chaque affirmation ci-dessus est traçable vers l’une de ces sources. Uniquement des sources primaires et officielles : billets et documentation du projet Kubernetes, état des dépôts, avis de sécurité et spécification de la Gateway API.

1. Kubernetes blog — Ingress NGINX Retirement: What You Need to Know (11 Nov 2025)
2. Kubernetes blog — Ingress NGINX: Statement from the Steering and Security Response Committees (29 Jan 2026)
3. Kubernetes blog — Before You Migrate: Five Surprising Ingress-NGINX Behaviors You Need to Know (27 Feb 2026)
4. GitHub — kubernetes/ingress-nginx (public archive, read-only since 24 Mar 2026)
5. GitHub — ingress-nginx controller-v1.15.1, the final release (19 Mar 2026)
6. Kubernetes Security Response Committee — [Security Advisory] Multiple issues in ingress-nginx (2 Feb 2026)
7. kubernetes/kubernetes#136678 — CVE-2026-24512, configuration injection via the Ingress path field
8. kubernetes/kubernetes#137560 — CVE-2026-3288, configuration injection via the rewrite-target annotation
9. kubernetes/kubernetes#137893 — CVE-2026-4342, comment-based configuration injection (fixed by the final release)
10. Kubernetes blog — Ingress-nginx CVE-2025-1974: What You Need to Know (24 Mar 2025)
11. Kubernetes documentation — Ingress (the API is generally available and frozen)
12. Kubernetes documentation — Ingress Controllers
13. Gateway API — API overview and channel status
14. Kubernetes blog — Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard (3 Aug 2026)
15. GitHub — Gateway API v1.6.0 release notes
16. GitHub — Gateway API v1.6.1, the current patch release (16 July 2026)
17. Gateway API — v1.6 conformance reports by implementation
18. GitHub — kubernetes-sigs/ingress2gateway
19. Kubernetes blog — Announcing Ingress2Gateway 1.0: Your Path to Gateway API (20 Mar 2026)
20. GitHub — nginx/kubernetes-ingress, the F5 NGINX Ingress Controller (a different project)
21. GitHub — nginx/nginx-gateway-fabric, F5's Gateway API implementation
22. Gateway API — versioning, release channels and graduation criteria