Un Network Endpoint Group (NEG) est un ensemble de destinations de trafic (endpoints) qu’un Cloud Load Balancer peut cibler directement — sans cette fonctionnalité, un Load Balancer route vers des instances entières, pas vers des cibles plus fines.
Types de NEG
| Type | Cible | Cas d’usage |
|---|---|---|
| Zonal NEG (GCE_VM_IP_PORT) | IP:port d’une VM précise | Plusieurs services sur une même VM, chacun sur son port |
| Serverless NEG | Cloud Run, Cloud Functions, App Engine | Exposer un service serverless derrière un Load Balancer avec Cloud CDN/Cloud Armor |
| GKE NEG (container-native) | IP d’un pod directement | Load balancing GKE sans double saut nœud → pod, nécessite un cluster VPC-native — voir Ingress et Cloud Load Balancing |
| Internet NEG / Hybrid NEG | Endpoint hors GCP (autre cloud, on-premise) | Load balancing hybride multi-cloud |
Pourquoi c’est important sur GKE
Sans NEG, le Load Balancer route vers un nœud puis kube-proxy fait le dernier saut vers le pod — latence supplémentaire, health checks au niveau nœud plutôt que pod. Avec les NEG (activées par défaut sur un cluster VPC-native, voir vNIC et IP alias ranges), le trafic va directement à l’IP du pod.
En relation avec
- Cloud Load Balancing — hub, les NEG sont la cible d’un Backend Service
- Ingress et Cloud Load Balancing — container-native load balancing sur GKE en détail
- Pas d’équivalent direct côté AWS — un Target Group ALB/NLB peut cibler des IP, mais sans la même intégration native aux pods Kubernetes