Le Gateway API

Qu'est-ce que le Gateway API ?

Le Gateway API est un ensemble de ressources personnalisées (CRD) qui standardisent le routage L4 à L7 dans Kubernetes. C'est l'évolution — et le successeur annoncé — de l'Ingress : un projet de la SIG-Network, plus expressif, plus portable et surtout orienté rôles.

Là où l'Ingress se limite au HTTP(S), le Gateway API couvre :

• HTTP / HTTPS, mais aussi TCP, UDP, TLS et gRPC ;
• le routage par hôte, chemin et en-tête ;
• des fonctions avancées plus finement contrôlables (pondération de trafic, redirections, réécriture…).

Pourquoi un successeur à l'Ingress ?

• Périmètre limité de l'Ingress : uniquement HTTP(S), pas de TCP/UDP/gRPC.
• Annotations non portables : tout ce qui sort du cadre de base passe par des annotations propres à chaque controller (nginx, Traefik…), donc difficiles à migrer.
• Rôles flous : avec l'Ingress, on ne sait pas clairement qui possède le load balancer et qui possède les routes.
• Gateway API répond à cela avec des champs typés dans l'API (au lieu d'annotations), une API extensible et un comportement cohérent d'une implémentation à l'autre.

Un modèle orienté rôles

Le Gateway API répart les responsabilités entre trois rôles, chacun gérant ses propres ressources (avec le RBAC correspondant) :

• Infrastructure provider → crée les GatewayClass : la « classe » de passerelle (quelle implémentation, quel controller).
• Cluster operator → déploie les Gateway : les points d'entrée réels (listeners, ports, protocoles, TLS).
• Développeur applicatif → crée les HTTPRoute (ou TCPRoute, GRPCRoute, TLSRoute…) dans son namespace, sans toucher à l'infrastructure.

On retrouve les Services (et leurs Pods) comme cibles des routes, via backendRefs.

Les objets principaux

• GatewayClass : comme l'IngressClass, elle déclare une implémentation (un controller). Gérée par le fournisseur d'infrastructure.
• Gateway : une instance de load balancer / point d'entrée, avec un ou plusieurs listeners (port + protocole + TLS). Gérée par l'opérateur du cluster.
• Routes (HTTPRoute, TCPRoute, TLSRoute, GRPCRoute…) : les règles de routage, rattachées à un Gateway via parentRefs et ciblant des Services via backendRefs. Gérées par les développeurs.
• ReferenceGrant : autorise explicitement les références entre namespaces (ex. une route dans app qui cible un Service dans backend).

Plusieurs routes peuvent se rattacher au même Gateway : c'est le point d'entrée mutualisé.

Un manifeste Gateway API

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: nginx
spec:
  controllerName: example.com/nginx-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web-gateway
  namespace: infra
spec:
  gatewayClassName: nginx
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        certificateRefs:
          - name: app-tls
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web
  namespace: app
spec:
  parentRefs:
    - name: web-gateway
      namespace: infra
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: frontend
          port: 80
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api
          port: 8080

[!NOTE] Le Gateway API n'est pas intégré au cœur de Kubernetes : il faut installer ses CRDs, puis un controller compatible (Istio, Envoy Gateway, ingress-nginx, Traefik, Cilium…). L'API principale a atteint le stade GA (v1).

Ingress ou Gateway API ?

• API : l'Ingress est natif ; le Gateway API s'installe via des CRDs.
• Protocoles : Ingress = HTTP(S) ; Gateway API = HTTP/HTTPS, TCP, UDP, TLS, gRPC.
• Fonctions avancées : annotations non portables (Ingress) contre champs typés (Gateway API).
• Rôles : flous (Ingress) contre séparation nette GatewayClass / Gateway / Route.
• Migration : l'Ingress reste pleinement supporté ; de nombreux controllers supportent les deux en parallèle.

En pratique : l'Ingress suffit pour la plupart des sites (simple, universel). On passe au Gateway API pour des besoins TCP/UDP/gRPC, du routage L7 avancé, ou une vraie séparation des rôles.

Les commandes principales

• Lister les classes de passerelle : kubectl get gatewayclass
• Lister les passerelles : kubectl get gateways
• Lister les routes HTTP : kubectl get httproutes
• Obtenir les détails d'une passerelle : kubectl describe gateway web-gateway
• Voir les ressources disponibles : kubectl api-resources | grep gateway.networking.k8s.io
• Appliquer les manifestes : kubectl apply -f gateway.yaml