Introduction gateway api

Gateway API :

• Introduction:
  • Pourquoi Gateway API remplace Ingress

  • Architecture : GatewayClass, Gateway, HTTPRoute, TCPRoute, etc.

Depuis plusieurs années, la ressource Ingress de Kubernetes est utilisée pour gérer le trafic entrant vers les applications. Bien qu’efficace pour les cas simples, elle présente des limites importantes :

• Spécification non extensible : difficile à adapter à des besoins complexes (multi-tenancy, TLS avancé, routage fin, etc.)

• Forte dépendance au contrôleur : chaque implémentation (NGINX, Traefik, Istio…) interprète différemment les annotations, entraînant une incompatibilité entre les clusters.

• Manque de séparation des responsabilités : impossible de distinguer clairement la gestion du réseau (opérations) de la configuration applicative (développeurs).

Pour répondre à ces limitations, la communauté Kubernetes via le Special Interest Group (SIG Network) a conçu le projet Gateway API.
Son objectif est d’apporter une évolution majeure d’Ingress, en introduisant :

• Une API déclarative, modulaire et extensible, basée sur les CRD (Custom Resource Definitions) ;

• Une clarté des rôles entre opérateurs, plateformes et développeurs ;

• Une interopérabilité garantie entre les différents fournisseurs de Gateway (Cilium, Istio, Traefik, Envoy Gateway, etc.).

En d’autres termes, Gateway API est le nouveau standard réseau pour Kubernetes, conçu pour refléter la complexité des environnements modernes tout en restant cohérent avec la philosophie déclarative du projet.

Architecture de Gateway API

Gateway API introduit plusieurs ressources clés qui travaillent ensemble pour définir le trafic entrant :

1. GatewayClass

   • Définit le type de passerelle à déployer (similaire à une classe de Storage).

   • Gérée par le provider ou gateway-controller  (Cilium, Istio, Traefik, etc.). Remplace ingress-controller

   • Exemples : cilium, istio, traefik, envoy, nginx-gateway-fabric.

2. Gateway

   • Représente une instance concrète de passerelle réseau dans le cluster.

   • Définie par les opérateurs (infrastructure), elle configure les ports, protocoles et certificats. Remplace ingress-class

   • Peut être partagée entre plusieurs équipes ou namespaces.

3. HTTPRoute / TCPRoute / GRPCRoute / UDPRoute

   • Gérés généralement par les équipes applicatives, ils décrivent comment le trafic doit être routé vers les services backend. Remplace les ingress

   • Par exemple :

     • HTTPRoute pour les applications web ;

     • TCPRoute pour des flux binaires ou bases de données ;

     • GRPCRoute pour les APIs gRPC.

4. ReferencePolicy

   • Définit explicitement quelles ressources peuvent se référencer entre namespaces, renforçant la sécurité et l’isolation multi-tenant.

Avantages clés de Gateway API

• Séparation claire des rôles
  • L’opérateur crée les GatewayClass et Gateway, le développeur gère les HTTPRoute.

• Multi-namespaces natif

  • Un Gateway peut servir plusieurs applications dans différents namespaces.

• Extensibilité et standardisation

  • Une seule API pour de multiples implémentations (Cilium, Istio, Traefik, Envoy…).

• Support de scénarios avancés

  • Routage conditionnel, réécriture d’URL, filtrage, déploiement canary ou blue/green, TLS mutualisé, etc.4

Gateway API modernise la gestion du trafic entrant dans Kubernetes. Elle devra remplacer les Ingress par une approche plus claire, modulaire et extensible, adaptée aux besoins des environnements multi-tenant, multi-fournisseurs et orientés DevOps