> kubectl convert --from=ingress --to=gateway-api --dry-run_
Dossier : Migration de Ingress vers Gateway API
Par Nicolas DELAHAYE | v.1974 | Architecte SolutionSTATUS: NETWORK_ARCHITECTURE_UPGRADE
1. Le Constat : Pourquoi tuer l'Ingress ?
Pendant des années, l'objetIngress a été le standard de facto. Couplé à des contrôleurs comme NGINX, Traefik ou HAProxy, il a fait le travail. Mais soyons honnêtes, à l'échelle, c'est devenu un cauchemar de maintenance.
Les limites sont structurelles :
- L'enfer des Annotations : Pour faire du rate-limiting ou du rewrite, vous injectez des annotations spécifiques au contrôleur (vendor lock-in).
- Tout ou rien : L'objet Ingress mélange la configuration de l'infrastructure (TLS, IP) et le routage applicatif (Paths). Difficile de séparer les rôles Ops et Dev.
- HTTP Only : Pas de support natif propre pour TCP, UDP ou gRPC sans "hacks".
2. Gateway API : Une Révolution Architecturale
La Gateway API n'est pas une v2 de l'Ingress. C'est une refonte complète basée sur une architecture orientée Rôles. Elle introduit plusieurs ressources (CRDs) pour découpler les responsabilités.👥 Qui gère quoi ?
- GatewayClass (Infra Provider) : Définit le moteur sous-jacent (NGINX, Istio, Cilium).
- Gateway (Ops / Platform Team) : Définit les points d'entrée, les ports, le TLS et les IP. C'est le "Load Balancer".
- HTTPRoute / TCPRoute (Dev Team) : Définit les règles de routage vers les services. Les devs ne touchent plus à l'infra !
3. Comparatif Technique : Avant vs Après
Regardons concrètement comment la configuration évolue d'un modèle monolithique à un modèle distribué.L'Ancien Monde (Ingress)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-legacy
annotations:
# Dépendance forte à l'implémentation NGINX
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: app.example.com
http:
paths:
- path: /old
backend:
service:
name: app-svc
port:
number: 80
Le Nouveau Monde (Gateway API)
Ici, l'Ops configure le Gateway une fois pour toutes :# Géré par l'équipe PLATEFORME apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: shared-gateway namespace: gateway-system spec: gatewayClassName: nginx-gateway listeners: - name: https port: 443 protocol: HTTPS tls: mode: Terminate certificateRefs: - name: wildcard-cert allowedRoutes: namespaces: from: All # Autorise les apps des autres namespaces à s'attacherEt le développeur déclare simplement sa route, sans se soucier du certificat SSL ou de l'IP :
# Géré par l'équipe APP (Namespace distinct)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: app-route
namespace: my-app
spec:
parentRefs:
- name: shared-gateway
namespace: gateway-system
hostnames:
- app.example.com
rules:
- matches:
- path:
type: PathPrefix
value: /new
backendRefs:
- name: app-svc
port: 80
4. Les "Killer Features" impossibles avec Ingress
🚀 Traffic Splitting (Canary natif)
Plus besoin de Service Mesh lourd (Linkerd/Istio) juste pour faire du Canary. C'est natif :
rules:
- backendRefs:
- name: app-v1
port: 80
weight: 90 # 90% du trafic
- name: app-v2
port: 80
weight: 10 # 10% du trafic (Canary)
🛡️ Multi-Protocoles
L'API ne s'arrête pas au HTTP. Vous avez besoin d'exposer une base de données ou un flux vidéo ?kind: TCPRoute→ Pour vos bases de données.kind: UDPRoute→ Pour le streaming ou le gaming.kind: GRPCRoute→ Pour vos microservices modernes.
5. Stratégie de Migration : Le plan "Zero Downtime"
Ne faites pas de "Big Bang". La Gateway API permet la coexistence. Voici la stratégie que je recommande pour les clusters en production :| Phase | Action | Impact |
|---|---|---|
| 1. Préparation | Installer les CRDs Gateway API et configurer la GatewayClass. |
Aucun (Infrastructure only). |
| 2. Double Stack | Déployer les HTTPRoute en parallèle des Ingress existants. |
Double exposition. Permet de tester les nouvelles routes via curl --resolve. |
| 3. Switch DNS | Mise à jour du DNS pour pointer vers l'IP du Gateway LoadBalancer. | Le trafic bascule. Rollback possible par simple DNS. |
| 4. Cleanup | Suppression des anciens objets Ingress. | Migration terminée. |
6. Intégration Helm & GitOps (ArgoCD)
Pour industrialiser cela, modifiez vos Chartes Helm pour supporter conditionnellement les deux modes via le fichiervalues.yaml :
# values.yaml pattern gateway: enabled: true className: nginx-gateway host: app.example.com # template/httproute.yaml {{- if .Values.gateway.enabled }} apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: {{ include "app.fullname" . }} spec: parentRefs: - name: {{ .Values.gateway.className }} hostnames: - {{ .Values.gateway.host }} rules: ... {{- end }}Cette approche permet de migrer application par application dans ArgoCD en changeant simplement un flag booléen.
📚 Ressources Officielles & Documentation
| Sujet | Source | Lien |
|---|---|---|
| Spec & Concepts | Kubernetes.io Docs | Docs Officielles |
| Migration Guide | Gateway API SIG | Guide Migration |
| GKE Implementation | Google Cloud | GKE Guide |