Vue d'ensemble de la série K8S Envoy Gateway : une entrée de trafic plus moderne qu'Ingress

Si vous avez déjà géré du trafic externe sur Kubernetes, il y a de fortes chances que vous ayez commencé par Ingress. Ça fonctionne, et pour beaucoup de scénarios c'est sincèrement suffisant. Mais dès que les exigences deviennent plus complexes — plusieurs listeners, gouvernance multi-équipes, gRPC, TCP, TLS passthrough, politiques de trafic plus fines — vous finissez inévitablement dans une situation où "tenir le tout en vie avec des annotations" devient la norme. Le YAML commence à ressembler à une incantation, et les personnes qui le maintiennent ont l'impression de briser un sceau.

C'est là que Gateway API + Envoy Gateway entre en jeu : c'est le nouvel outillage. Il ne rend pas les choses plus compliquées ; il sépare proprement des responsabilités qui étaient auparavant entremêlées, ce qui rend beaucoup plus facile de raisonner sur le trafic entrant, les règles de routage, les paramètres TLS, les types de protocole et la répartition des responsabilités entre équipes.

Qu'est-ce que c'est, exactement

Disons-le clairement en une phrase :

Envoy Proxy : le plan de données qui reçoit réellement le trafic et transfère les requêtes, aussi appelé Gateway Proxy
Envoy Gateway : le plan de contrôle qui gère Envoy Proxy pour vous
Gateway API : l'interface standard que vous utilisez dans Kubernetes pour déclarer les règles de trafic

Pensez-y comme ceci :

Gateway API est l'endroit où vous écrivez vos besoins
Envoy Gateway est le responsable qui traduit et délègue
Envoy Proxy est le vrai gardien posté à la porte

L'avantage de cette séparation, c'est que vous n'avez pas besoin de fabriquer à la main une configuration Envoy bas niveau, ni de mémoriser toutes les annotations privées de différents contrôleurs. Vous déclarez des ressources Kubernetes, et Envoy Gateway les traduit en une configuration que Envoy Proxy peut réellement exécuter.

Gateway vs Ingress : quelle différence

La réponse courte : Ingress n'est pas obsolète, mais Gateway API est mieux adaptée aux systèmes de taille moyenne à grande qui ont besoin de plus de gouvernance.

Comparaison	Ingress	Gateway API
Modèle Ingress	Combine généralement entrée et routage dans un seul objet	Sépare `GatewayClass`, `Gateway` et `Route`
Expressivité	Principalement HTTP/HTTPS ; les fonctions avancées reposent sur des annotations	Prise en charge native de plusieurs types de routes et champs plus clairs
Modèle d'extension	Beaucoup de capacités dépendent d'annotations privées propres au contrôleur	Champs standard, plus points d'extension via des CRD
Prise en charge des protocoles	Surtout centré sur HTTP/Web	Prend en charge `HTTPRoute`, `GRPCRoute`, `TCPRoute`, `TLSRoute`
Responsabilité d'équipe	Facile de mélanger config plateforme et config applicative	Mieux adapté aux équipes plateforme pour l'entrée et aux équipes applicatives pour les routes
Portabilité	Les annotations sont souvent liées à un contrôleur spécifique	Plus standardisé, meilleure lisibilité entre implémentations

Si vos besoins sont simplement :

Un seul site web ou une API simple
Un routage basique par chemin/hôte
Une petite équipe

Alors Ingress reste parfaitement acceptable. Mais si vos besoins commencent à inclure :

Une même entrée qui sert plusieurs protocoles
Plusieurs listeners, domaines ou certificats
HTTP et gRPC qui coexistent
Une séparation entre l'entrée plateforme et les autorisations de routage applicatif
Une configuration qui ressemble à une vraie API, pas à une liste de souhaits via annotations

Alors Gateway API commencera à devenir très attirante.

Pourquoi ne pas simplement utiliser Ingress

L'objectif officiel de Gateway API est de résoudre plusieurs points de douleur fréquents avec Ingress à grande échelle :

Meilleure expressivité : le routage, TLS, les politiques de trafic et les types de protocole sont définis plus clairement
Meilleure portabilité : moins de dépendance aux annotations privées propres aux contrôleurs
Séparation des rôles plus naturelle : les équipes plateforme possèdent l'entrée, les équipes applicatives possèdent les routes

Par exemple, les configurations Ingress ressemblent souvent à ceci :

metadata:
  annotations:
    some.ingress.controller/rewrite-target: /
    some.ingress.controller/auth-type: basic
    some.ingress.controller/ssl-redirect: "true"

Ce n'est pas que ça ne marche pas, mais quand les besoins grossissent, les annotations deviennent facilement une sorte de magie noire YAML mystérieuse. Gateway API fait remonter ces besoins dans de vrais champs. Ça se lit comme une "configuration", pas comme une "liste de souhaits".

La structure en couches

La page de concepts officielle découpe Envoy Gateway en trois couches ; cela vaut la peine de les mémoriser comme carte mentale :

User Configuration : les ressources Gateway API et les CRD d'extension Envoy Gateway que vous écrivez
Envoy Gateway Controller : lit ces ressources et les traduit en configuration exécutable
Envoy Proxy : le plan de données qui gère réellement le trafic en direct

En pratique, vous passerez l'essentiel de votre temps à modifier la "couche déclarative", pas à vous connecter en SSH sur des instances de proxy pour ajuster une config bas niveau. C'est toute l'élégance d'une approche native Kubernetes.

Ce que vous allez apprendre dans cette série

Cette série suit un ordre "on construit d'abord, puis on approfondit" — 10 articles au total, y compris cette vue d'ensemble :

Démarrage rapide : installer Envoy Gateway et faire passer votre première requête HTTP de bout en bout
Concepts de base : comprendre GatewayClass, Gateway, Listener et Envoy Proxy
Routage HTTP en pratique : approfondissement de HTTPRoute — hôte, chemin, header, filter, timeout
TLS et sécurité : configurer HTTPS, comprendre certificateRefs, la terminaison TLS et TLSRoute
Bonnes pratiques : les habitudes clés avant de passer en production
Antisèche des types de routes : décider rapidement entre HTTPRoute, GRPCRoute, TCPRoute et TLSRoute
Guide de conception des listeners : modèles de conception multi-port, multi-hostname et multi-ingress
Multi-namespace et responsabilité d'équipe : maîtriser allowedRoutes, ReferenceGrant et la gouvernance d'une entrée partagée
Guide du status et du débogage : lire Accepted, ResolvedRefs, Programmed et suivre le chemin de dépannage le plus court

Si vous voulez simplement sentir à quoi ressemble Envoy Gateway, passez directement à l'article suivant. Le faire tourner vaut mieux que mémoriser tous les termes d'abord ; un peu comme aller à la salle, y aller pour de vrai vaut mieux que regarder 30 vidéos YouTube avant.

Les ressources principales que vous allez rencontrer

Les débutants trébuchent souvent parce qu'ils supposent que Gateway API ne contient que Gateway et HTTPRoute. En réalité, c'est toute une famille de ressources.

`GatewayClass`

Définit "quelle implémentation de Gateway utiliser dans ce cluster". Pour Envoy Gateway, l'essentiel est que controllerName pointe vers le bon contrôleur.

`Gateway`

Définit "à quoi ressemble l'entrée". Par exemple : quels ports ouvrir, quels protocoles écouter, comment le TLS est rattaché, quelles routes sont autorisées.

`Listener`

Listener est l'une des unités les plus importantes à l'intérieur d'un Gateway. Pensez-y comme un point d'entrée exposé vers l'extérieur sur le Gateway ; chaque point définit :

port
protocol
hostname
TLS config
allowedRoutes

Beaucoup de gens voient Gateway comme une boîte noire, mais ce qui détermine réellement le comportement de l'entrée, c'est chaque listener individuel qu'il contient.

La famille Route

HTTPRoute : trafic HTTP/HTTPS — le plus courant
GRPCRoute : trafic gRPC — peut faire du matching sur service/method
TCPRoute : trafic TCP brut — n'interprète pas la sémantique HTTP
TLSRoute : route en fonction du SNI TLS — courant pour le TLS passthrough

Ce que toutes les routes ont en commun : Elles n'"ouvrent pas la porte" — elles décident "comment router le trafic une fois qu'il est entré".

Modèle mental minimal

Gardez cette carte en tête :

GatewayClass  # Which Gateway implementation to use in this cluster
Gateway       # Which listeners this ingress opens
Listener      # A port / protocol / hostname / TLS slot
Route         # How to distribute traffic once it enters
Service       # The backend actually serving requests in the cluster
Envoy Proxy   # The data plane that ultimately handles the traffic

Un exemple minimal ressemble à ceci :

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: demo
spec:
  parentRefs:
    - name: eg
  hostnames:
    - "www.example.com"
  rules:
    - backendRefs:
        - name: backend
          port: 3000

Vous n'avez pas besoin de mémoriser chaque champ maintenant. Comprenez simplement ce qu'il fait :

parentRefs : à quel Gateway cette règle se rattache
hostnames : quel domaine doit correspondre à cette règle
backendRefs : vers quel Service envoyer le trafic

En un coup d'oeil : quand utiliser quelle route

Besoin	Ressource recommandée
Sites web, API REST, routage par header/chemin	`HTTPRoute`
Routage par service/method gRPC	`GRPCRoute`
Services TCP purs (protocole personnalisé ou non HTTP)	`TCPRoute`
Conserver un TLS de bout en bout, ne pas déchiffrer au niveau du Gateway	`TLSRoute`

Cette matrice de décision est très pratique. Avant d'écrire du YAML, demandez-vous :

"Est-ce que je traite du trafic HTTP, gRPC, ou du TCP/TLS brut ?"

Résumé en une ligne

Envoy Gateway n'est pas juste un terme de plus à mémoriser : c'est une façon d'élever le trafic externe Kubernetes de "ça marche à peu près" à "quelque chose qui ressemble à un système d'ingénierie".

💡 Si c'est votre première fois avec cette pile, n'essayez pas d'apprendre tous les CRD d'un coup. Installez-la, faites passer votre première requête, puis revenez sur les concepts : le taux d'absorption est bien meilleur comme ça.

Étape suivante

Dans le prochain article, on met les mains dedans : installer Envoy Gateway dans votre cluster et faire passer votre premier Gateway + HTTPRoute : 👉 Démarrage rapide