Kubernetes Gateway API 2026 : remplacer Ingress

À la fin de ce tutoriel, vous installerez les CRDs Gateway API, un contrôleur (Envoy Gateway), une app derrière un Gateway + HTTPRoute, puis vous saurez migrer depuis Ingress — vocabulaire, rôles, TLS et checklist 2026, lab jetable.

Niveau : Intermédiaire · Temps estimé : 55–70 min · Versions cibles : Kubernetes 1.29+ · Gateway API standard (v1) · Envoy Gateway (Helm) · Helm 3 · image nginx:1.27-alpine · Dernière vérification : 2026-09-11 · Region cloud : ca-central-1

Slug : wow-gateway-api-k8s · Série : WOW (17/50) · Mot-clé SEO : Kubernetes Gateway API · Publish : READY (WP-CLI)

← Précédent : Linkerd mesh léger · → Suivant : Karpenter EKS · Aussi : Ingress + Gateway API · EKS Ingress · cert-manager

Prérequis

  • Cluster lab 1.29+ (kind, k3d, minikube, k3s ou EKS jetable) avec kubectl admin
  • Helm 3 et accès réseau pour pull d’images / charts
  • Bases Services ClusterIP — Services Kubernetes · Deployment
  • Lecture utile : Ingress NGINX et Gateway API (contexte Ingress)
  • Lab jetable : namespace + LoadBalancer éventuel ; budget d’alerte si cloud
  • Coût : ~0 € en local ; sur EKS/ca-central-1, un NLB/ALB de contrôleur peut facturer des cents/heure — teardown obligatoire
kubectl version --client
kubectl cluster-info
helm version

Vérifiez toujours un cluster lab, jamais la prod.

Ce que nous allons construire

Lab Gateway API (WOW 17/50) — ca-central-1 si cloud
  ├── CRDs Gateway API (standard-install)
  ├── Contrôleur Envoy Gateway (Helm)
  ├── App : Deployment + Service ClusterIP
  ├── GatewayClass + Gateway (listener HTTP)
  ├── HTTPRoute (host/path → Service)
  ├── TLS aperçu + migration Ingress
  └── Nettoyage + checklist 2026

(Schéma — alt : « Client HTTP → Gateway → HTTPRoute → Service ClusterIP → Pods ».)

Objectif : un point d’entrée L7 moderne sans annotations Ingress propriétaire, avec délégation claire plateforme / apps.

Étape 1 — Pourquoi Gateway API en 2026 ?

Ingress (networking.k8s.io/v1) reste partout, mais l’API est limitée (HTTP surtout, annotations vendor, peu de rôles). Gateway API est le modèle recommandé pour les nouveaux designs d’entrée.

Approche Rôle En 2026
Service LB / NodePort Entrée L4 Simple ; cher en multi-apps
Ingress Host/path HTTP(S) Héritage ; dépend du contrôleur
Gateway API Listeners + routes typées, rôles Cible nouveaux clusters

Contexte ingress-nginx : le projet communautaire a quitté la maintenance active (SIG Network / SRC ; fin des releases après mars 2026). Les charts restent utilisables en lab/héritage, mais ne sont plus une cible durable. Apprenez Gateway API (Envoy Gateway, NGINX Gateway Fabric, Istio/Contour, contrôleurs cloud) pour les greenfields.

Pitch DEH : « GatewayClass / Gateway / HTTPRoute — moins d’annotations, plus de GitOps. »

Étape 2 — Installer les CRDs Gateway API

Sans CRDs, kubectl apply d’un Gateway échoue. Installez le canal standard (aligné sur votre cluster — lisez les notes de release) :

# Exemple : pinnez une release officielle kubernetes-sigs/gateway-api
export GWAPI_VER=v1.2.1
kubectl apply -f "https://github.com/kubernetes-sigs/gateway-api/releases/download/${GWAPI_VER}/standard-install.yaml"
kubectl get crd | grep gateway.networking.k8s.io

Attendu : CRDs gatewayclasses, gateways, httproutes, etc. Le canal experimental ajoute TCPRoute/UDPRoute/TLSRoute — inutile pour ce lab HTTP.

Étape 3 — Contrôleur : Envoy Gateway (Helm)

Les CRDs seules ne programment rien. Il faut un implémentation qui enregistre une GatewayClass.

helm repo add envoy-gateway https://gateway.envoyproxy.io
helm repo update

helm upgrade --install eg oci://docker.io/envoyproxy/gateway-helm 
  --version v1.3.2 
  --namespace envoy-gateway-system 
  --create-namespace 
  --wait

kubectl -n envoy-gateway-system get pods
kubectl get gatewayclass

Adaptez le tag chart si besoin. Attendu : pods Ready ; une GatewayClass (souvent eg).

Prod : pinnez chart + image, RBAC minimal, NetworkPolicy egress, et sur cloud (ca-central-1) prévoyez le Service type LoadBalancer du data plane + tags Owner=lab.

Sur kind, un port-forward ou mapping NodePort peut remplacer l’EXTERNAL-IP.

Étape 4 — App démo (Deployment + ClusterIP)

kubectl create namespace gw-lab

# manifests/web.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: gw-lab
  labels: { app: web }
spec:
  replicas: 2
  selector:
    matchLabels: { app: web }
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: nginx
          image: nginx:1.27-alpine
          ports: [{ name: http, containerPort: 80 }]
          resources:
            requests: { cpu: 50m, memory: 64Mi }
            limits: { cpu: 200m, memory: 128Mi }
          readinessProbe:
            httpGet: { path: /, port: http }
            initialDelaySeconds: 2
            periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: gw-lab
spec:
  type: ClusterIP
  selector: { app: web }
  ports: [{ name: http, port: 80, targetPort: http }]

kubectl apply -f manifests/web.yaml
kubectl -n gw-lab rollout status deploy/web
kubectl -n gw-lab get deploy,svc,endpoints

Attendu : 2 Pods Running, Endpoints non vides. Le Gateway ne remplace pas le Service : il route vers lui.

Étape 5 — Gateway + HTTPRoute

Remplacez gatewayClassName par le nom réel (kubectl get gatewayclass).

# manifests/gateway.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web-gw
  namespace: gw-lab
spec:
  gatewayClassName: eg
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web
  namespace: gw-lab
spec:
  parentRefs:
    - name: web-gw
  hostnames:
    - web.lab.local
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: web
          port: 80

kubectl apply -f manifests/gateway.yaml
kubectl -n gw-lab get gateway,httproute
kubectl -n gw-lab describe gateway web-gw
kubectl -n gw-lab describe httproute web

Attendu : Gateway Accepted/Programmed (conditions) ; HTTPRoute Accepted avec parentRef vers web-gw.

Test lab :

# EXTERNAL-IP du Service data plane Envoy (nom selon chart)
kubectl -n envoy-gateway-system get svc
# kind : kubectl -n envoy-gateway-system port-forward svc/<envoy-svc> 8080:80
curl -sS -H "Host: web.lab.local" "http://127.0.0.1:8080/" | head

Points clés : parentRefs lie la route au Gateway ; backendRefs = Service (pas d’IP Pod) ; allowedRoutes contrôle qui peut attacher des routes (Same / All / Selector).

Étape 6 — TLS et aperçu cert-manager

En prod, un listener HTTPS référence un Secret TLS (souvent via cert-manager). Lab rapide :

openssl req -x509 -nodes -days 7 -newkey rsa:2048 
  -keyout tls.key -out tls.crt -subj "/CN=web.lab.local"
kubectl -n gw-lab create secret tls web-tls --cert=tls.crt --key=tls.key

Ajoutez un listener HTTPS (port 443, certificateRefs vers web-tls) selon le guide de votre contrôleur. Pour le renouvellement auto, voir cert-manager Let’s Encrypt — jamais de clé dans Git.

Étape 7 — Migration Ingress → Gateway et bonnes pratiques

  1. Inventoriez Ingress (kubectl get ingress -A) : hosts, paths, TLS, annotations critiques
  2. Mappez : IngressClass → GatewayClass ; règles host/path → HTTPRoute ; TLS → listener HTTPS + Secret
  3. Cohabitez Ingress + Gateway pendant la bascule (deux points d’entrée ou cutover DNS)
  4. GitOps : versionnez Gateway (plateforme) et HTTPRoute (apps) — Argo CD
  5. Sur EKS, lisez aussi EKS Ingress : ALB Ingress Controller vs Gateway côté cloud
  6. Nouveaux clusters 2026 : designer Gateway API d’abord ; Ingress = héritage / labs pédagogiques

Vérification de fin de lab

  1. CRDs Gateway API présentes ; GatewayClass listable
  2. Contrôleur Envoy Gateway Ready
  3. Deploy web + Service ClusterIP + Endpoints
  4. Gateway + HTTPRoute Accepted ; curl avec Host: web.lab.local OK
  5. Pas de secrets réels dans le repo 
kubectl get gatewayclass
kubectl -n gw-lab get gateway,httproute,deploy,svc

Nettoyage

kubectl delete -f manifests/gateway.yaml --ignore-not-found
kubectl delete -f manifests/web.yaml --ignore-not-found
kubectl delete ns gw-lab --ignore-not-found
helm uninstall eg -n envoy-gateway-system --ignore-not-found
kubectl delete ns envoy-gateway-system --ignore-not-found
# Optionnel : retirer les CRDs Gateway API seulement si aucun autre lab ne les utilise
rm -f tls.key tls.crt

Sur cloud ca-central-1 : vérifiez qu’aucun LoadBalancer orphelin ne reste facturé.

Coûts

Poste Ordre de grandeur
kind / k3d / minikube ~0 €
EKS + NLB contrôleur (ca-central-1) control plane + LB (cents/h) — teardown
Secrets / certificats lab 0 € (auto-signé)

Erreurs fréquentes

Symptôme Cause Correction
CRD not found CRDs absentes standard-install.yaml
Gateway not programmed Mauvais gatewayClassName / contrôleur down get gatewayclass ; pods envoy-gateway-system
HTTPRoute not accepted parentRef / namespace Aligner name + allowedRoutes
404 / connection refused Host / EXTERNAL-IP curl -H Host: ; port-forward kind
Backend empty Service / selectors get endpoints
LB qui reste Oubli teardown cloud Delete Gateway/Helm + check AWS ca-central-1

Quiz (5 questions)

1. Gateway API sépare surtout :
– A. Pods et Nodes
– B. GatewayClass, Gateway et routes (ex. HTTPRoute)
– C. Namespaces et Labels

2. Qui gère typiquement le Gateway (listeners) ?
– A. Uniquement le développeur front
– B. L’équipe plateforme / ops
– C. etcd

3. Une HTTPRoute pointe vers :
– A. Une IP Pod en dur
– B. Un Service (backendRefs)
– C. Un ConfigMap

4. En 2026, pour un nouveau design d’entrée HTTP :
– A. ingress-nginx v1.7 forever
– B. Gateway API + contrôleur maintenu
– C. NodePort public sans TLS

5. Region lab cloud DEH :
– A. us-east-1
– B. ca-central-1
– C. eu-west-3

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

FAQ

Gateway API remplace-t-il complètement Ingress ?

Pour les nouveaux designs, oui c’est la cible. Ingress reste supporté longtemps : cohabitation et migration progressive.

Faut-il Istio pour utiliser Gateway API ?

Non. Istio peut implémenter Gateway API, mais Envoy Gateway, NGINX Gateway Fabric, Contour, etc. suffisent pour HTTP(S).

Standard vs experimental ?

Standard : GatewayClass, Gateway, HTTPRoute, ReferenceGrant… Experimental : TCP/UDP/TLS routes — ajoutez seulement si besoin.

kind sans EXTERNAL-IP ?

Normal. Utilisez kubectl port-forward vers le Service du data plane, ou un mapping NodePort.

Pourquoi ca-central-1 ici ?

Standard DevOps Elastic Hayway pour les labs cloud. Le cluster local n’impose pas la region ; EKS/LB oui.

Lien avec le service mesh ?

Mesh = est-ouest ; Gateway API = nord-sud. Complémentaires — Istio · Linkerd.

Pour aller plus loin

Maillage série WOW
← Précédent Linkerd mesh léger (WOW 16)
→ Suivant Karpenter sur EKS (WOW 18)
Aussi Ingress+Gateway · cert-manager · Argo CD

Meta publication (SEO)

  • Title SEO : Kubernetes Gateway API 2026 : remplacer Ingress (guide FR)
  • Meta description (≤ 160) : Gateway API K8s 2026 : GatewayClass, Gateway, HTTPRoute, lab Envoy Gateway, TLS, migration Ingress. Lab ca-central-1, FAQ et quiz DEH.
  • Focus keyword : Kubernetes Gateway API
  • Secondary : Gateway API Kubernetes, HTTPRoute, GatewayClass, Envoy Gateway
  • Cover alt : Trafic HTTP vers Gateway API Kubernetes (Gateway et HTTPRoute)
  • Catégorie : WOW / Kubernetes · Niveau : Intermédiaire
  • Schema : HowTo + FAQPage + Article
  • URL cible : https://devopelastichayway.com/tutoriels/wow-gateway-api-k8s/
  • Parent WP : /tutoriels/ ID 5463
  • Statut : READY — feu vert Maître WP-CLI
  • Region lab : ca-central-1

← Catalogue Tutoriels

Pour aller plus loin — hubs live

Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.

© 2023 devopelastichayway.com All rights reserved.