A network endpoint group (NEG) groups backend endpoints or services for load-balancing traffic. In GKE, NEGs enable container-native load balancing: a load balancer sends traffic directly to Pod IPs rather than first sending it to a node’s IP address and NodePort. section 7.2.1 section 10.2.1
The distinction matters when an Ingress serves Pods. Without a NEG, traffic reaches a node and the GKE Dataplane forwards it to the selected Pod—possibly on another node. Those extra hops add latency and complexity. With a NEG, Pod readiness gates let the load balancer assess health from its own perspective, accounting for events such as Pod startup, Pod loss, and VM loss. section 10.2.1 section 10.2.1
For Ingress for Anthos, NEGs represent backends deployed on Anthos clusters. Google-managed controller instances route to a NEG according to service availability across clusters in the same Anthos fleet. MultiClusterIngress and MultiClusterService objects reside on a designated config cluster, which serves as centralized configuration storage for the controller. section 7.2.1
Enable a NEG for a Service
Where container-native load balancing is not enabled by default, annotate the Service with `cloud.google.com/neg: '{"ingress": true}'`. Apply this per Service rather than assuming every cluster creates NEGs automatically. section 10.2.1
kind: Service
...
annotations:
cloud.google.com/neg: ‘{"ingress": true}’ #1
...
The Service listing shows the annotation used to enable a NEG for Ingress traffic. section 10.2.1
For Services created in GKE clusters at version 1.17.6-gke.7 or later, container-native load balancing is enabled by default only when the cluster is VPC-native, does not use a shared VPC, and does not use GKE network policy. Check those conditions before relying on direct-to-Pod routing; otherwise, enable it explicitly for the relevant Services. section 10.2.1
