Ingress et Gateway API
| Fiche express | |
|---|---|
| Type | Exposition nord-sud (Ingress historique / successeur Gateway API) |
| Statut Gateway API | GA depuis v1.0 (oct. 2023) · v1.5 (fév. 2026) |
| Apports Gateway API | Séparation des rôles · canary natif · gRPC/TCP/UDP |
| Voir aussi | Réseau Kubernetes — Modèle et primitives · Service mesh et mTLS · Cilium et eBPF |
Exposition maîtrisée du trafic nord-sud (de l'extérieur vers les services du cluster). Deux modèles : l'Ingress historique et la Gateway API, son successeur. La Gateway API est GA depuis la v1.0 (octobre 2023) ; version courante v1.5 (février 2026), recommandée pour les nouveaux clusters.
Ingress
Ressource historique pour exposer du HTTP/HTTPS via un Ingress Controller (NGINX, Traefik, HAProxy…). Limites structurelles :
- Fonctions avancées via annotations spécifiques au contrôleur → non portables.
- Pas de séparation des rôles : infra et routage applicatif dans un même objet.
- HTTP/HTTPS seulement (pas de TCP/UDP/gRPC natif), pas de matching par en-tête ni de traffic splitting standard.
Gateway API
Modèle successeur, conçu autour de la séparation des rôles et d'un modèle d'extension standardisé. Ressources :
<mermaid> flowchart TD
GC[GatewayClass
fournisseur / infra] --> GW[Gateway
écouteurs, ports, TLS] GW --> HR[HTTPRoute
règles de routage] HR --> S1[Service A] HR --> S2[Service B]
</mermaid>
- GatewayClass — type d'infrastructure (géré par l'opérateur de cluster).
- Gateway — points d'écoute (ports, protocole, TLS) — équipe plateforme.
- *Route (HTTPRoute, GRPCRoute, TCPRoute…) — règles de routage — équipe applicative.
Apports : routage par en-tête, traffic splitting pondéré (canary) natif, gRPC/TCP/UDP, TLS backend (BackendTLSPolicy), et couverture est-ouest (profil mesh). Portabilité : le cœur (Gateway/Route) est cohérent entre implémentations.
Ingress vs Gateway API
| Critère | Ingress | Gateway API |
|---|---|---|
| Statut | Stable, en maintenance | GA (v1.0 oct. 2023), actif |
| Séparation des rôles | Non | Oui (Class / Gateway / Route) |
| Fonctions avancées | Annotations non portables | Champs standard |
| Protocoles | HTTP/HTTPS | HTTP, gRPC, TCP, UDP, TLS |
| Canary / split | Non standard | Natif (poids) |
| Est-ouest (mesh) | Non | Oui (profil mesh) |
| Recommandation | Existant à maintenir | Nouveaux clusters |
Choix d'implémentation
Nombreuses implémentations conformes : Istio, Envoy Gateway, NGINX, Contour, et Cilium (intégré au CNI). En stack RKE2/Cilium, utiliser l'implémentation Gateway API de Cilium évite un composant supplémentaire.
Migration : inutile de migrer un Ingress qui fonctionne « pour le principe ». Adopter la Gateway API sur les nouveaux besoins (multi-tenant, canary, gRPC) et migrer progressivement.