Kubernetes Gateway API : migration depuis Nginx Ingress

Pourquoi l'Ingress est limité

L'objet Ingress Kubernetes a été conçu en 2015 pour un cas d'usage simple : exposer des services HTTP derrière un reverse proxy. En 2026, il montre ses limites dans plusieurs dimensions :

• Portabilité nulle : le routing avancé (header-based, weight-based) est implémenté via des annotations propriétaires (nginx.ingress.kubernetes.io/*) non portables entre implémentations
• Mono-tenant : un seul namespace contrôle la configuration de toutes les règles de routing
• Extensibilité limitée : impossible d'exprimer du routing TCP/UDP ou des politiques de timeout nativement
• Couplage fort : la configuration du load balancer (gateway) est mélangée avec les règles de routing (routes)

Gateway API : les ressources clés

La Gateway API introduit une hiérarchie de ressources qui sépare clairement les responsabilités :

• GatewayClass : définit le type d'implémentation (Contour, Cilium, Envoy Gateway). Ressource cluster-scoped gérée par l'admin.
• Gateway : instance d'un load balancer avec ses listeners (ports, protocoles, TLS). Gérée par l'équipe infrastructure.
• HTTPRoute : règles de routing HTTP attachées à un ou plusieurs Gateway. Gérée par les équipes applicatives dans leurs propres namespaces.
• TCPRoute / TLSRoute : routing TCP et TLS passthrough pour les workloads non-HTTP.
• ReferenceGrant : autorisation explicite pour qu'un HTTPRoute d'un namespace accède à un Service dans un autre namespace.

Implémentations disponibles

Plusieurs implémentations de la Gateway API sont disponibles en production en 2026 :

• Envoy Gateway : maintenu par la CNCF, basé sur Envoy, recommandé pour les nouveaux projets
• Cilium : intégration native eBPF, excellentes performances, idéal sur EKS
• Contour : basé sur Envoy, maturité éprouvée, support VMware
• Kong : riche en fonctionnalités de gestion d'API
• nginx-gateway-fabric : implémentation NGINX officielle de la Gateway API

Exemples HTTPRoute

Routing par chemin

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-routes
  namespace: backend
spec:
  parentRefs:
    - name: prod-gateway
      namespace: infrastructure
  hostnames:
    - "api.move2cloud.fr"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1/payments
      backendRefs:
        - name: payment-service
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /v1/users
      backendRefs:
        - name: user-service
          port: 8080

Routing par header (A/B testing)

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: ab-test
  namespace: frontend
spec:
  parentRefs:
    - name: prod-gateway
      namespace: infrastructure
  rules:
    - matches:
        - headers:
            - name: X-Beta-User
              value: "true"
      backendRefs:
        - name: frontend-v2
          port: 3000
    - backendRefs:
        - name: frontend-v1
          port: 3000

Canary avec weight-based routing

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: canary-release
  namespace: backend
spec:
  parentRefs:
    - name: prod-gateway
      namespace: infrastructure
  rules:
    - backendRefs:
        - name: my-service-v1
          port: 8080
          weight: 90    # 90 % du trafic vers v1
        - name: my-service-v2
          port: 8080
          weight: 10    # 10 % du trafic vers v2

Migration depuis Nginx Ingress

Voici comment transformer une règle Ingress NGINX typique en HTTPRoute :

# AVANT : Ingress NGINX avec annotations propriétaires
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/rate-limit: "100"
spec:
  ingressClassName: nginx
  rules:
    - host: app.move2cloud.fr
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080
---
# APRÈS : HTTPRoute Gateway API (portable, standardisé)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
  namespace: production
spec:
  parentRefs:
    - name: prod-gateway
      namespace: infrastructure
  hostnames:
    - "app.move2cloud.fr"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080

Multi-tenancy avec ReferenceGrant

Le ReferenceGrant est un mécanisme de sécurité qui autorise explicitement un HTTPRoute dans un namespace à référencer un Service dans un autre namespace :

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-team-a-to-backend
  namespace: backend        # Namespace du Service cible
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      namespace: team-a     # Namespace source autorisé
  to:
    - group: ""
      kind: Service

TLS avec cert-manager

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
  namespace: infrastructure
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  gatewayClassName: cilium
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      hostname: "*.move2cloud.fr"
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-tls-cert
            namespace: infrastructure

Conclusion

La Gateway API est la voie vers laquelle Kubernetes se dirige pour la gestion du trafic entrant. Elle résout les problèmes fondamentaux de l'Ingress : portabilité, multi-tenancy, expressivité. La migration est progressive — vous pouvez faire coexister Ingress et Gateway API pendant la transition. Commencez par les nouveaux services et migrez les anciens au fur et à mesure.