Gateway API : le successeur de l'Ingress sur Kubernetes

En mars 2026, le projet Ingress NGINX, contrôleur utilisé par une grande partie des clusters Kubernetes, a cessé d'être maintenu. Plus de correctifs, plus de mises à jour de sécurité : de nombreuses équipes doivent désormais choisir une nouvelle façon d'exposer leurs applications. La réponse officielle de la communauté s'appelle la Gateway API.

Pensée par le SIG Network de Kubernetes, la Gateway API est une famille de ressources qui décrit comment le trafic entre dans un cluster et comment il est routé vers les services. Là où l'Ingress se limitait à un objet unique, souvent complété par des annotations propres à chaque contrôleur, elle propose un modèle portable, extensible et orienté rôles. Elle est stable (GA) depuis fin 2023 pour ses ressources HTTP principales et reconnue par Envoy Gateway, Istio, Traefik, Cilium et la plupart des offres Cloud managées.

Dans cet article, nous allons d'abord revenir sur les limites de l'Ingress, puis détailler le modèle de la Gateway API et ses ressources, comparer les principales implémentations et enfin décrire une démarche de migration progressive avec des exemples YAML.

Pourquoi l'Ingress atteint ses limites

L'objet Ingress, introduit dès les premières versions de Kubernetes, répond à un besoin simple : exposer des services HTTP à l'extérieur du cluster en fonction d'un nom d'hôte et d'un chemin. Pendant des années, cette simplicité a fait son succès. Elle est aussi à l'origine de ses principales faiblesses.

• Un périmètre trop étroit : la spécification ne couvre que le routage HTTP par hôte et par chemin. Les redirections, les réécritures d'URL, la répartition de trafic ou le routage par header n'existent pas dans l'API.
• Les annotations comme échappatoire : chaque contrôleur a comblé ces manques avec ses propres annotations (nginx.ingress.kubernetes.io/...), non typées, non validées et non portables d'un contrôleur à l'autre.
• Un seul objet pour tous les rôles : l'équipe plateforme qui gère les certificats et les équipes applicatives qui définissent leurs routes modifient la même ressource, ce qui complique les droits d'accès.
• Peu de support des autres protocoles : TCP, UDP ou gRPC ne sont pas modélisés de façon standard.

L'annonce de la fin de maintenance d'Ingress NGINX a rendu ce problème concret. Ce contrôleur, très répandu, concentrait justement des centaines de configurations reposant sur des annotations. L'API Ingress elle-même n'est pas supprimée de Kubernetes, mais elle est gelée : aucune évolution n'y est plus prévue, et toutes les nouveautés arrivent dans la Gateway API.

Comprendre le modèle de la Gateway API

La Gateway API repose sur une idée directrice : séparer les responsabilités entre les personnes qui interviennent sur l'infrastructure réseau. La documentation officielle distingue trois profils, chacun gérant sa propre ressource.

GatewayClass, Gateway et routes

• GatewayClass : définit un type de passerelle et l'implémentation qui la pilote (Envoy Gateway, Istio, Cilium...). Elle est gérée par le fournisseur d'infrastructure, de façon comparable à une StorageClass.
• Gateway : représente une instance de passerelle, avec ses points d'écoute (ports, protocoles, noms d'hôte) et sa configuration TLS. Elle est gérée par l'équipe plateforme ou l'administrateur du cluster.
• HTTPRoute : décrit les règles de routage HTTP vers les services. Elle appartient aux développeurs, dans leur propre namespace. D'autres types existent : GRPCRoute, TLSRoute, TCPRoute et UDPRoute.

Ce découpage permet de déléguer finement les droits avec le RBAC : une équipe peut créer ses routes sans jamais toucher aux certificats ni aux ports exposés. Une Gateway choisit explicitement quels namespaces peuvent s'y attacher, ce qui évite qu'une route mal configurée n'impacte tout le cluster.

Exemple de configuration

Voici une Gateway partagée, exposée en HTTPS, puis une HTTPRoute qui envoie 90 % du trafic vers la version stable d'une API et 10 % vers une version canari.

# Gateway gérée par l'équipe plateforme
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: passerelle-publique
  namespace: infra
spec:
  gatewayClassName: envoy
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      hostname: "*.example.com"
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-example-com
      allowedRoutes:
        namespaces:
          from: All

# HTTPRoute gérée par l'équipe applicative
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
  namespace: produit
spec:
  parentRefs:
    - name: passerelle-publique
      namespace: infra
  hostnames:
    - "api.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: api-stable
          port: 8080
          weight: 90
        - name: api-canari
          port: 8080
          weight: 10

La Gateway porte le certificat et le port, la route ne contient que la logique applicative. Le partage de trafic par poids, qui nécessitait une annotation spécifique avec l'Ingress, devient ici un champ standard et validé par l'API. Les en-têtes, les redirections, les réécritures d'URL et les filtres s'expriment de la même façon, directement dans la spécification.

À lire : découvrez notre formation DevOps Engineer

Les implémentations disponibles

La Gateway API est une spécification : un contrôleur doit être installé dans le cluster pour la mettre en œuvre. Le projet publie des tests de conformité qui permettent aux implémentations de déclarer les fonctionnalités qu'elles supportent. Plusieurs options se détachent pour les équipes qui quittent Ingress NGINX.

Envoy Gateway est l'implémentation de référence du projet Envoy, dédiée à la Gateway API. Elle déploie des proxys Envoy et expose des politiques complémentaires (limitation de débit, authentification, timeouts) via ses propres ressources. C'est un choix naturel pour les équipes qui souhaitent un ingress moderne sans service mesh.

Istio a adopté la Gateway API comme API de configuration par défaut pour le trafic entrant, et l'utilise aussi pour le routage interne du mesh. Les équipes qui déploient déjà Istio peuvent unifier leur gestion du trafic nord-sud et est-ouest.

Traefik supporte la Gateway API en plus de ses CRDs IngressRoute, ce qui facilite une transition par étapes pour ses utilisateurs actuels.

Cilium intègre la Gateway API directement dans son plan de données basé sur eBPF et Envoy, ce qui convient aux clusters qui utilisent déjà Cilium comme interface réseau (CNI).

Le choix dépend donc moins des fonctionnalités de routage, communes grâce à la spécification, que de l'écosystème déjà en place et des politiques complémentaires nécessaires. Les offres Cloud managées (GKE, AKS, EKS) proposent aussi leurs propres GatewayClass. Les fonctionnalités avancées restent toutefois spécifiques à chaque implémentation : un test sur un environnement de préproduction s'impose avant de généraliser.

Migrer depuis l'Ingress

La migration ne se fait pas en une nuit, mais elle peut être progressive, car un Ingress et une Gateway peuvent coexister dans le même cluster. Une démarche en quatre étapes fonctionne bien en pratique.

1. Inventorier l'existant : lister les Ingress, leurs annotations et les fonctionnalités réellement utilisées (réécritures, authentification, limitation de débit, timeouts).
2. Choisir et installer une implémentation : installer les CRDs de la Gateway API, puis le contrôleur retenu, et créer une GatewayClass et une Gateway de test.
3. Convertir les ressources : traduire les Ingress en HTTPRoute, en s'appuyant sur l'outil officiel ingress2gateway.
4. Basculer le trafic progressivement : valider les routes avec la nouvelle passerelle, puis déplacer le DNS ou le load balancer, et retirer l'ancien contrôleur une fois le trafic migré.

L'outil ingress2gateway, maintenu par la communauté Kubernetes, lit les Ingress d'un cluster ou de fichiers YAML et génère les ressources Gateway API équivalentes. Il sait traduire une partie des annotations d'Ingress NGINX et signale celles qu'il ne peut pas convertir.

# Conversion des Ingress du namespace produit vers des ressources Gateway API
ingress2gateway print --providers ingress-nginx --namespace produit > gateway-api.yaml

# Vérification du résultat avant application
kubectl apply --dry-run=server -f gateway-api.yaml

Le résultat doit toujours être relu : certaines annotations n'ont pas d'équivalent standard et demandent d'utiliser une politique propre à l'implémentation choisie. À titre d'exemple, un Ingress qui réécrit un chemin se traduit par un filtre de la route.

# Équivalent d'une réécriture de chemin via un filtre HTTPRoute
rules:
  - matches:
      - path:
          type: PathPrefix
          value: /api
    filters:
      - type: URLRewrite
        urlRewrite:
          path:
            type: ReplacePrefixMatch
            replacePrefixMatch: /
    backendRefs:
      - name: backend
        port: 8080

Dans une démarche GitOps, ces manifestes sont versionnés puis déployés par un outil comme Argo CD, ce qui permet de relire les changements en revue de code et de revenir en arrière rapidement. Enfin, pensez à surveiller les taux d'erreur et les latences avec Prometheus pendant la bascule.

À découvrir : notre formation DevOps Engineer

Conclusion

La Gateway API n'est pas qu'un remplaçant de l'Ingress : c'est une refonte du modèle d'exposition des applications sur Kubernetes. Elle sépare les rôles, standardise des fonctionnalités qui dépendaient jusqu'ici d'annotations et ouvre la voie à une vraie portabilité entre implémentations, qu'il s'agisse d'Envoy Gateway, d'Istio, de Traefik ou de Cilium.

La fin de maintenance d'Ingress NGINX fait de cette migration un chantier à planifier sans attendre. En inventoriant les usages, en choisissant une implémentation cohérente avec l'existant et en procédant par étapes avec ingress2gateway, les équipes peuvent la mener sans interruption de service.

Maîtriser la Gateway API devient une compétence différenciante pour les ingénieurs DevOps et plateforme : elle s'impose comme le standard du routage sur Kubernetes pour les années à venir.