A la découverte de Gateway API

L’annonce comme quoi Ingress NGINX Controller va être officiellement retiré de l’écosystème Kube en mars 2026, a relancé beaucoup de discussions autour de la Gateway API.

Et de mon côté, j’avouuuuuuue ça m’a surtout fait me poser pas mal de questions :

Est-ce que c’est vraiment « le futur » ?
C’est quoi exactement la Gateway API ?
Pourquoi ça existe alors qu’on a déjà les Ingress ?
Qu’est-ce que ça apporte de plus ?

Déjà, Gateway API, c’est quoi ? 🤔

Si on se réfère à la doc Kubernetes (et qu’on simplifie un peu), la Gateway API est un add-on Kubernetes pour gérer l’accès réseau aux applications de notre cluster.

Son objectif est de diriger le trafic entrant dans le cluster comme on peut le faire avec les ingress finalement.

Même si l’Ingress est relativement simple, il suffit d’un Ingress controller puis d’un ingress et “roule ma poule”. Ils sont très dépendant d’annotations (souvent spécifiques au controller). Et ce n’est pas toujours évident à gérer à grande échelle.

La où la Gateway API apporte des ressources séparées, plus explicites, plus lisible et role-oriented.

Vous êtes perdu ? pas de panique, on va voir ça juste après, un peu de patience !! 😅

Justement, rentrons un peu plus dans le détail !

La séparation des roles

La Gateway API repose sur plusieurs ressources bien distinctes, chacune avec un rôle précis.

Pour commencer, on a la GatewayClass. Elle définit comment les gateways sont implémentées et quel controller est utilisé (Traefik, Istio, Envoy, Cilium…). En gros, si on doit résumer ça en 1 phrase, la GatewayClass répond à la question “Qu’est-ce qu’on met en place pour accepter du trafic entrant dans le cluster ?”. Ça peut être un load balancer d’un cloud provider ou une brique réseau par exemple. A savoir aussi que c’est un objet cluster-wide. Voici un exemple au format YAML :

# https://github.com/marcel-dempers/docker-development-youtube-series/blob/master/kubernetes/gateway-api/traefik/01-gatewayclass.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: traefik
spec:
  controllerName: traefik.io/gateway-controller

La Gateway est associée à une GatewayClass. C’est elle qui définit quels ports sont exposés, comment le trafic est accepté, quels certificats TLS sont utilisés. Et point très cool, c’est namespacé. Concrètement, ça veut dire qu’on peut avoir une Gateway dans un namespace team-a basée sur Traefik et une autre Gateway dans team-b basée sur Istio (à condition, bien sûr, que les GatewayClass existent). Perso je trouve ça stylé, ça permet d’isoler les usages ! Pareil, je vous mets un petit exemple :

# https://github.com/marcel-dempers/docker-development-youtube-series/blob/master/kubernetes/gateway-api/traefik/02-gateway.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway-api
  namespace: default
spec:
  gatewayClassName: traefik

  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same  #or All or Selector
    
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: secret-tls
            namespace: default
      allowedRoutes:
        namespaces:
          from: Same

Et enfin, on a les routes. C’est l’équivalent (en beaucoup mieux 😅) des règles d’un Ingress. On définit comment le trafic est routé depuis un listener, vers un backend (souvent un Service Kubernetes). Mais surtout c’est beaucoup plus lisible je trouve. Et surtout, ça ne repose pas sur des annotations spécifique à un ingress controller ! Et on ne perd pas les bonnes habitudes, voici ce que ça donne :

# https://github.com/marcel-dempers/docker-development-youtube-series/blob/master/kubernetes/gateway-api/03-httproute-by-hostname.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: python-route
  namespace: default

spec:
  parentRefs:
  - name: gateway-api
    sectionName: http
    kind: Gateway

  hostnames:
  - example-app-python.com

  rules:
  - backendRefs:
    - name: python-svc
      port: 5000
      weight: 1

Et le côté role-based dans tout ça ? 🤔

C’est probablement ce que je préfère dans la Gateway API. Prenons un exemple très classique, avec 3 teams différentes :

Une Team Infrastructure Provider qui va gérer la GatewayClass (Traefik, Istio, Cilium…)
Une Team Cluster Operator qui va gérer les Gateways (ports, TLS, exposition)
Une Team Dev qui gère uniquement les HTTPRoute / GRPCRoute de son appli

Avec cette répartition, chacun reste dans son périmètre. Personne n’écrase le travail des autres. Et comme il parait qu’une image vaut mille mots alors, voici une image :

Après, okkkkkkk ça, c’est sur le papier dans la vraie vie, je ne sais pas si ça se passe vraiment comme ça mdr. Mais je pense qu’il faudrait tendre avec ce genre d’orga

Et en pratique, ça donne quoi ?

Plutôt que de réinventer la roue, j’ai suivi l’excellent tuto de DevOps Guy avec une très très bonne introduction à Gateway API ! 😍

J’ai couplé le tuto écris à sa video :

Pour info, j’ai utilisé le chart Traefik en version 38.0.2 et les CRD semblent s’installer automatiquement. Donc pas besoin de les appliquer à la main comme dans le tuto 😜

Conclusion

Après avoir mis les mains dedans, voilà ce que j’en pense. 🧐

J’ai adoré le côté role-based, je trouve ça beaucoup plus clair et pratique à grande échelle comparé aux ingress.

J’ai apprécié aussi l’approche plateforme avec une gestion centralisée via les GatewayClass et le découpage par namespace que l’on peut faire (ou pas), on organise les ressources comme on veut finalement pour que ça colle au plus à notre besoin.

Autre coup de coeur, Les HTTP rules. Il y en a pas mal, URLRewrite, ResponseHeaderModifier, CORS… (et je pense qu’il va y en avoir d’autres). C’est tellement plus simple et lisible !

Je suis tombé sur pas mal de ressources expliquant que la Gateway API pouvait servir de base à un Service Mesh. Je ne me suis pas du tout penché sur le sujet, donc je n’en parlerai pas ici, mais je drop l’info si jamais ça vous intrigue.

Pendant mes recherches, je suis aussi tombé sur deux outils qui m’ont paru sympas :

ingress2gateway permettant de migrer vos ingress vers gateway API
gwctl qui ressemble à un wrapper kubectl spécialisé pour piloter les objets Gateway API

Au final, faut-il migrer ?

Et baaaaaaah ça dépend mdr 😂

Kubernetes ne déprécie pas l’API Ingress, c’est uniquement le controller NGINX. Donc si vos Ingress font le job, pas d’urgence

En revanche, si vous cherchez plus de flexibilité sur la gestion du trafic, une meilleure séparation des responsabilités et que vous avez des équipes bien découpées, pour moi la Gateway API vaut clairement le coup

Je vous laisser sur cette réflexion ! En espérant que l’article vous aura éclairé sur Gateway API ! 💡