Kubernetes : Migrer de l'Ingress vers la Gateway API

INTRODUCTION

Pendant des années, l'API Ingress a été le standard de facto pour exposer des services Kubernetes. Pourtant, elle souffre de limitations structurelles bien connues des équipes Ops : une dépendance excessive aux annotations propriétaires, un manque de portabilité et un modèle de sécurité "tout ou rien".

La Kubernetes Gateway API change radicalement la donne. Elle ne se contente pas de remplacer Ingress ; elle introduit un modèle orienté rôles, standardise le routage avancé (Traffic Splitting, Header Matching) et simplifie la gouvernance multi-équipes.

Ce guide technique analyse les différences fondamentales et vous accompagne pas à pas dans la migration de vos premières routes.

Prérequis

Avant de commencer, assurez-vous de disposer de l'environnement suivant :

Cluster Kubernetes : Version 1.24+ recommandée pour un support stable.
CLI : kubectl configuré avec des droits d'administration (cluster-admin).
Implémentation Gateway API : Ce tutoriel est agnostique, mais nécessite un contrôleur installé (ex: Istio, Cilium, Envoy Gateway, Nginx Gateway Fabric ou Traefik).
CRDs Gateway API : Les définitions de ressources doivent être présentes sur le cluster.

Comparatif technique : Ingress vs Gateway API

Pourquoi changer ? Voici les différences structurelles majeures :

Fonctionnalité	Ingress (Legacy)	Gateway API (Nouveau Standard)
Modèle de ressources	Monolithique (une ressource `Ingress` gère tout).	Découplé (`GatewayClass`, `Gateway`, `HTTPRoute`).
Gouvernance (RBAC)	Difficile : Ops et Devs entrent souvent en conflit sur le même objet.	Native : Les Ops gèrent la `Gateway`, les Devs gèrent leurs `HTTPRoute`.
Extensions	Annotations non standard (ex: `nginx.ingress...`).	Champs typés, validés et extensibles par design.
Routing avancé	Complexe (Canary, Blue/Green via annotations).	Standardisé (Traffic splitting, Header matching, Query param).
Portabilité	Faible (configuration liée au contrôleur).	Élevée (API unifiée entre les fournisseurs).

Tutoriel : Migration d'une règle simple

Nous allons transformer une ressource Ingress classique en une architecture Gateway + HTTPRoute.

1. Installation des CRDs

Si votre cluster ne dispose pas encore des Custom Resource Definitions (CRDs), installez le canal standard :

# NOTE: Requiert des droits cluster-admin
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml

2. Le point de départ : Une Ingress classique

Voici la configuration "Legacy" que nous souhaitons migrer. Elle expose un service sur le chemin /v1.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: legacy-ingress
  namespace: APP_NAMESPACE
  annotations:
    kubernetes.io/ingress.class: nginx # Dépendance spécifique
spec:
  rules:
  - host: api.tecapic.fr
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

3. L'approche Gateway API : Séparation des responsabilités

La philosophie de la Gateway API repose sur le Persona-based model.

Étape A : L'Administrateur Infra configure la Gateway

L'équipe Infrastructure déploie la Gateway. C'est le point d'entrée réseau. Elle définit où le trafic entre (port, protocole, TLS).

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: INFRA_NAMESPACE
spec:
  gatewayClassName: istio # ou cilium, nginx, envoy-gateway-class...
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All # Autorise les namespaces applicatifs à s'attacher ici

Étape B : Le Développeur configure la HTTPRoute

L'équipe Application définit comment le trafic est routé vers son service. Ils n'ont pas besoin de toucher à la configuration du LoadBalancer.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: APP_NAMESPACE
spec:
  parentRefs:
  - name: main-gateway
    namespace: INFRA_NAMESPACE # Référence cross-namespace explicite
  hostnames:
  - "api.tecapic.fr"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1
    backendRefs:
    - name: my-service
      port: 80

Sécurité et Gouvernance 🔐

La Gateway API renforce la sécurité grâce à un modèle plus granulaire :

Cross-Namespace Routing contrôlé : Par défaut, une Gateway peut refuser les routes venant d'autres namespaces. Le champ allowedRoutes permet de définir une whitelist précise (par sélecteur de labels ou liste explicite), empêchant le "Shadow IT" d'exposer des services publiquement sans accord.
Gestion TLS centralisée ou déléguée : L'équipe Infra peut gérer les certificats sur la Gateway (terminaison TLS) tout en laissant le routing aux devs. Alternativement, le TLS peut être délégué via TLSRoute pour du Passthrough.
Principe de moindre privilège : Les développeurs n'ont plus besoin de droits d'écriture sur l'objet qui gère l'IP publique (Gateway ou Ingress), mais uniquement sur leurs propres objets de routage.

Observabilité et Debugging 📈

Finis les statuts vagues. La Gateway API standardise les retours d'état via les conditions.

Vérifier l'attachement d'une route :
```
kubectl get httproute app-route -n APP_NAMESPACE -o yaml
```
Recherchez le bloc status.parents.
- Si Accepted est True : La route est valide et attachée.
- Si Accepted est False : Le message d'erreur vous dira exactement pourquoi (ex: NotAllowedByListeners).

Tests & Validation ✅

Avant de basculer vos DNS, validez la configuration en utilisant le header Host.

Récupérez l'IP de la Gateway :

kubectl get gateway main-gateway -n INFRA_NAMESPACE

Test fonctionnel (Dry-run) : Simulez une requête sans modifier le DNS public.
```
curl -H "Host: api.tecapic.fr" http://<EXTERNAL_IP_GATEWAY>/v1
```

Stratégie de Rollback (Plan B) ↩️

La migration est non destructive car les API Ingress et Gateway peuvent coexister sur le même cluster (et même le même contrôleur souvent).

Déploiement parallèle : Gardez l'Ingress existante active. Déployez la Gateway et la HTTPRoute à côté.
Bascule DNS (Canary) : Changez l'entrée DNS pour pointer vers l'IP de la nouvelle Gateway (ou utilisez un poids DNS si possible).
Retour arrière : En cas d'erreur, repointez simplement le DNS vers l'IP de l'Ingress Controller original. Aucune reconfiguration complexe du cluster n'est requise.

Erreurs fréquentes (Troubleshooting)

Symptôme : HTTPRoute affiche un statut Accepted: False.
- Cause probable : La Gateway n'autorise pas le namespace de la route (voir allowedRoutes).
- Solution : Mettez à jour la Gateway ou déplacez la route.
Symptôme : 404 Not Found malgré une route valide.
- Cause probable : Le hostname défini dans la HTTPRoute ne correspond pas exactement au header de la requête, ou le path prefix est incorrect.

Checklist de mise en production

Les CRDs Gateway API sont installés et à jour.
Une GatewayClass valide est présente.
La Gateway restreint correctement les namespaces autorisés (allowedRoutes).
Les règles RBAC empêchent les développeurs de modifier la Gateway.
Les HTTPRoutes pointent vers les bons services (backendRefs).
Le monitoring remonte les codes d'erreur par route (4xx/5xx).

FAQ

Q1. L'API Ingress va-t-elle disparaître ? R: Non, l'Ingress passe en mode "GA Frozen". Elle ne recevra plus de nouvelles fonctionnalités majeures, mais restera supportée indéfiniment. La Gateway API est le futur pour les cas d'usage avancés.

Q2. Puis-je utiliser Gateway API avec Nginx ? R: Oui. Nginx propose une implémentation officielle via Nginx Gateway Fabric. La plupart des grands contrôleurs (Istio, Cilium, Linkerd, Traefik, Kong) supportent déjà l'API en production.

Conclusion

La migration vers la Gateway API n'est pas qu'une mise à jour technique ; c'est une amélioration de la gouvernance de votre plateforme Kubernetes. Elle permet de déléguer le routage aux équipes applicatives tout en gardant un contrôle strict de l'infrastructure.

Conseil Tecapic : Commencez petit. Migrez un service interne ou non critique en parallèle de votre Ingress actuel pour vous familiariser avec les objets Gateway et HTTPRoute sans risque.

Kubernetes Gateway API vs Ingress : Guide de migration et comparatif technique