L’Ingress Kubernetes a un défaut structurel connu depuis longtemps : tout ce qui dépasse le routage HTTP le plus basique (réécriture de chemin, répartition pondérée, en-têtes personnalisés) passe par des annotations, un mécanisme non standardisé et propre à chaque contrôleur. La Gateway API, un projet officiel de Kubernetes distinct de l’API core, remplace ce modèle par des ressources typées et portables entre contrôleurs.

Le problème que l’Ingress ne pouvait pas résoudre

Une annotation nginx.ingress.kubernetes.io/rewrite-target ne fonctionne qu’avec le contrôleur NGINX Ingress ; Traefik, HAProxy ou tout autre contrôleur exige sa propre syntaxe d’annotation pour la même intention. Changer de contrôleur Ingress (voir l’article NGINX vs Traefik) signifie réécrire toutes les annotations avancées, puisque rien dans la spécification Ingress d’origine ne standardise ce comportement au-delà du routage le plus élémentaire.

# Une annotation NGINX, incompréhensible pour
# tout autre contrôleur Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2

Trois ressources séparées, un rôle chacune

La Gateway API décompose ce qu’un Ingress unique mélangeait en trois ressources distinctes, chacune correspondant à une responsabilité et souvent à une équipe différente. GatewayClass (géré par l’équipe plateforme) définit un type d’implémentation de contrôleur. Gateway (géré par l’équipe plateforme ou réseau) définit un point d’entrée concret : adresses, ports, certificats TLS. HTTPRoute (géré par l’équipe applicative) définit les règles de routage propres à un service, sans jamais toucher à la configuration du point d’entrée partagé.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-gateway
spec:
  gatewayClassName: nginx
  listeners:
    - protocol: HTTP
      port: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: checkout-route
spec:
  parentRefs:
    - name: shared-gateway
  rules:
    - matches:
        - path: {value: /checkout}
      backendRefs:
        - name: checkout-service
          port: 8080

Cette séparation résout un vrai problème organisationnel que l’Ingress mélangeait par construction : une équipe applicative peut déclarer ses propres règles de routage (HTTPRoute) sans jamais avoir accès ni besoin de toucher à la configuration partagée du point d’entrée (Gateway), une frontière de permission que RBAC peut appliquer nativement puisque ce sont deux types de ressources distincts.

Le routage pondéré, standardisé, plus en annotation

Ce que l’Ingress ne pouvait exprimer que via des annotations propres à chaque contrôleur (répartir 90% du trafic vers une version, 10% vers une autre) devient un champ standard de l’API, portable entre tous les contrôleurs qui implémentent la spécification.

# Répartition pondérée standardisée, pas une annotation
# spécifique à un contrôleur particulier
rules:
  - backendRefs:
      - name: checkout-v1
        port: 8080
        weight: 90
      - name: checkout-v2
        port: 8080
        weight: 10

Ce qui ne change pas tout de suite

La Gateway API ne remplace pas l’Ingress du jour au lendemain : les deux coexistent, et la majorité des contrôleurs (NGINX, Traefik, Istio) supportent désormais les deux modèles en parallèle. La migration reste un choix, pas une obligation immédiate, et un cluster existant qui fonctionne bien avec l’Ingress classique n’a pas de raison urgente de migrer tant que le besoin de portabilité entre contrôleurs ou de séparation de responsabilités par équipe ne se fait pas sentir concrètement.

À retenir

L’Ingress encode toute logique avancée dans des annotations non portables entre contrôleurs, un défaut structurel que la Gateway API corrige en séparant les rôles en trois ressources typées (GatewayClass, Gateway, HTTPRoute), chacune correspondant à une équipe et une responsabilité distinctes. Le routage pondéré et d’autres comportements avancés deviennent des champs standards de l’API plutôt que des annotations spécifiques à un contrôleur. La migration reste progressive, pas un remplacement forcé, un des choix d’architecture réseau qui se posent dès qu’une migration Kubernetes doit distribuer la gestion du trafic entre plusieurs équipes.