Démarrage rapide d'Envoy Gateway : faites passer votre première requête en 10 minutes

Le but de cet article est simple : laisser de côté la philosophie et faire tourner Envoy Gateway tout de suite. Si vous atteignez le service d'exemple avec succès, vous aurez déjà fait plus que tous ceux qui sont encore bloqués sur la page d'accueil de la documentation.

Prérequis

Vous avez besoin d'au moins un cluster Kubernetes fonctionnel, par exemple :

• En local : kind, minikube, k3d
• Dans le cloud : EKS, GKE, AKS
• Homelab : K3s + MetalLB fonctionne aussi

Il vous faudra également :

• kubectl
• helm
• Un cluster capable de provisionner une adresse LoadBalancer, ou un cluster où l'utilisation de port-forward vous convient

⚠️ Si votre cluster ne prend pas en charge LoadBalancer, la documentation officielle recommande de l'associer à MetalLB. Ne pas avoir d'adresse externe n'est pas la fin du monde : vous testerez simplement via port-forward.

Étape 1 : installer Envoy Gateway

Installez le plan de contrôle :

helm install eg oci://docker.io/envoyproxy/gateway-helm \
  --version v1.7.0 \
  -n envoy-gateway-system \
  --create-namespace

Attendez qu'il soit prêt :

kubectl wait --timeout=5m -n envoy-gateway-system \
  deployment/envoy-gateway \
  --for=condition=Available

Une fois cette étape terminée, le contrôleur Envoy Gateway tourne dans votre cluster. Il peut désormais lire les ressources Gateway API et générer la configuration Envoy correspondante.

Étape 2 : appliquer les ressources officielles du quickstart

Le dépôt officiel fournit un exemple groupé qui inclut :

• GatewayClass
• Gateway
• HTTPRoute
• Une application backend d'exemple

Appliquez-le directement :

kubectl apply -f \
  https://github.com/envoyproxy/gateway/releases/download/v1.7.0/quickstart.yaml \
  -n default

Voyez cela comme l'équipe officielle qui vous prépare une scène de démonstration complète. Faites-la d'abord fonctionner, puis démontez-la ensuite pour comprendre les détails.

Étape 3 : vérifier que le trafic circule

Option A : le cluster possède un LoadBalancer

Récupérez l'adresse du Gateway :

export GATEWAY_HOST=$(kubectl get gateway/eg -o jsonpath='{.status.addresses[0].value}')

Envoyez une requête :

curl --verbose \
  --header "Host: www.example.com" \
  http://$GATEWAY_HOST/get

Si vous obtenez un HTTP 200, cela signifie :

• Le Gateway sert correctement d'entrée
• Le HTTPRoute a bien été attaché
• Le service backend est correctement ciblé par le routage

Option B : pas de LoadBalancer — utiliser port-forward

Trouvez le service Envoy :

export ENVOY_SERVICE=$(kubectl get svc -n envoy-gateway-system \
  --selector=gateway.envoyproxy.io/owning-gateway-namespace=default,gateway.envoyproxy.io/owning-gateway-name=eg \
  -o jsonpath='{.items[0].metadata.name}')

Redirigez le port local 8888 vers le port 80 du Gateway :

kubectl -n envoy-gateway-system port-forward service/${ENVOY_SERVICE} 8888:80

Dans un autre terminal :

curl --verbose \
  --header "Host: www.example.com" \
  http://localhost:8888/get

C'est le chemin de test local. Cela donne un peu l'impression d'entrer par la porte de derrière, mais si cela valide le routage, c'est très bien ; parfois, l'ingénierie consiste d'abord à "faire marcher", puis à rendre ça élégant.

Où regarder quand ça casse

Les problèmes les plus courants ne viennent pas du fait qu'Envoy Gateway serait cassé, mais du fait qu'un maillon de la chaîne ne s'est pas connecté :

Commandes utiles :

kubectl get pods -n envoy-gateway-system
kubectl get gatewayclass
kubectl get gateway -A
kubectl get httproute -A
kubectl get svc,pod -n default

Pour creuser le status du Gateway :

kubectl get gateway/eg -o yaml

Les points clés à vérifier :

• status.addresses
• Les conditions du listener
• Si les routes ont été acceptées

Ce que vous venez réellement de faire

Vous n'avez exécuté que quelques commandes, mais vous avez complété toute une chaîne de bout en bout :

1. Installation de Envoy Gateway
2. Création d'un GatewayClass pour indiquer au cluster quel contrôleur de gateway utiliser
3. Création d'un Gateway qui déclare le port et le protocole d'entrée
4. Création d'un HTTPRoute qui route le trafic vers le service backend
5. Envoy Gateway a traduit ces déclarations en configuration que Envoy Proxy peut exécuter

C'est exactement pour cela que Gateway API vaut la peine d'être utilisé. Vous écrivez des ressources Kubernetes, vous ne maintenez pas à la main une pile de fichiers de configuration proxy.

Étape suivante

Maintenant que votre première requête circule, l'article suivant explique ce que chacune de ces ressources fait réellement, afin de construire le bon modèle mental : 👉 Concepts de base