Ingress et Cloud Load Balancing

Sur un Kubernetes générique, un objet Ingress est interprété par un Ingress Controller qui tourne lui-même en pod dans le cluster (ex. ingress-nginx — un reverse proxy applicatif). Sur GKE, le comportement par défaut est différent et propre au cloud managé.

---

GKE Ingress (GCE Ingress Controller)

Le contrôleur natif GKE ne déploie aucun pod proxy : il traduit l’objet Ingress en ressources Cloud Load Balancing provisionnées directement sur l’infrastructure GCP (forwarding rules, backend services, health checks) — le trafic ne transite jamais par un pod interne dédié au routage.

	ingress-nginx (générique)	GKE Ingress (GCE)
Où tourne le routage	Dans des pods du cluster	En dehors du cluster, sur Cloud Load Balancing
Consommation de ressources cluster	Oui (CPU/mémoire des pods proxy)	Non
Portée	Ce que le proxy expose	Global anycast par défaut (voir Réseau GCP)
Portabilité	Identique sur tout Kubernetes	Spécifique à GKE

Gateway API

Successeur standardisé de l’Ingress (multi-vendor, porté par SIG-Network — voir Gateway API pour le détail complet de l’API, ses objets et ses fonctionnalités avancées). Là où Ingress est un objet unique et rigide (host + path → service, tout le reste passant par des annotations propriétaires non portables d’un contrôleur à l’autre), Gateway API découpe le même besoin en plusieurs objets, chacun avec un propriétaire naturel :

Objet	Rôle	Propriétaire typique
GatewayClass	Le type d’implémentation utilisé (ex. GKE, Istio…)	Admin infra/plateforme
Gateway	L’instance concrète : IP, ports, certificats TLS	Équipe infra/plateforme
HTTPRoute (ou TCPRoute, TLSRoute…)	Les règles de routage vers les Services	Équipe applicative

• RBAC fin : l’équipe applicative peut créer/modifier son HTTPRoute sans avoir les droits de toucher au Gateway partagé (IP publique, certificats) — impossible à isoler proprement avec un Ingress unique.
• Fonctionnalités standardisées : pondération de trafic entre versions, réécriture d’URL, matching sur headers sont définis dans l’API elle-même, pas via des annotations propres à chaque contrôleur — un HTTPRoute reste donc largement portable d’une implémentation à l’autre.
• Multi-protocole : gère aussi du TCP/TLS brut, ce qu’Ingress (pensé HTTP uniquement) ne permettait pas.

GKE fournit un Gateway Controller natif (même logique que GKE Ingress : traduction en Cloud Load Balancing, sans pod proxy) — recommandé pour les nouveaux déploiements.

Ingress et Gateway API ne sont pas des produits GCP : ce sont des specs Kubernetes génériques, seul le contrôleur qui les implémente change selon l’environnement — GKE n’étant qu’une implémentation parmi d’autres :

	Sur GKE	On-premise / self-managé
Contrôleur Ingress	GKE Ingress (GCE) → Cloud Load Balancing	ingress-nginx : pods proxy dans le cluster
Contrôleur Gateway API	GKE Gateway Controller → Cloud Load Balancing	Istio, Envoy Gateway, Contour, Kong… : pods proxy (Envoy le plus souvent) dans le cluster
IP publique pour type: LoadBalancer	Automatique (IP GCP)	Généralement absent nativement — nécessite un outil comme MetalLB pour attribuer des IP

---

Container-native load balancing (NEG)

Par défaut, un Load Balancer classique route vers les nœuds (puis kube-proxy fait le dernier saut vers le pod). Avec les Network Endpoint Groups (NEG), activés par défaut sur un cluster VPC-native, le Load Balancer route directement vers l’IP du pod :

• Élimine le double saut nœud → pod, réduit la latence.
• Health checks au niveau du pod, pas du nœud.
• Prérequis : cluster en mode VPC-native (alias IP ranges), quasi systématique sur les clusters GKE créés depuis plusieurs années.

---

Certificats TLS

Approche	Gestion	Portée
Google-managed certificates	Émission et renouvellement automatiques par Google, liés à un Ingress/Gateway	GKE uniquement
cert-manager	Déployé en pod, gère Let’s Encrypt ou une CA interne	Portable sur tout Kubernetes, y compris GKE

---

En relation avec

• GKE — Vue d’ensemble — hub GKE
• Réseau Kubernetes — Vue d’ensemble — ingress-nginx et cert-manager génériques
• Réseau GCP — Cloud Load Balancing global anycast en détail, mode VPC-native requis pour le container-native load balancing