liveBook · Manning

Container-native load balancing

As explained in Google Anthos in Action

Container-native load balancing sends load-balancer traffic directly to pod endpoints instead of routing it through cluster nodes.

Container-native load balancing sends traffic from a GKE HTTP load balancer directly to Pod IPs through network endpoint groups (NEGs). Without NEGs, Ingress traffic reaches a node’s NodePort first; the GKE Dataplane then forwards it to a Pod, potentially on another node. Direct routing removes those extra hops and simplifies the traffic path. section 10.2.1

Pod readiness gates also let the load balancer assess health from outside the cluster, rather than relying only on in-cluster probes. Awareness of Pod startup, Pod loss, and VM loss helps keep traffic stable. section 10.2.1

For Services, container-native load balancing is enabled by default when all of these conditions hold:

  • The Service was created in a GKE 1.17.6-gke.7 or later cluster. section 10.2.1
  • The cluster is VPC-native, does not use Shared VPC, and does not use GKE network policy. section 10.2.1

Service annotation

A Service manifest can specify `cloud.google.com/neg: '{"ingress": true}'` to request a NEG for Ingress traffic. section 10.2.1

How Google Anthos in Action covers it

How deep it goes
Explains traffic paths, readiness gates, default-enablement conditions, and a Service annotation without detailing NEG internals.
Examples
Shows a Service annotation that requests a NEG for Ingress.
What it assumes
Assumes familiarity with GKE Services, Ingress, Pods, and load balancers.
What you can do after
Operate/configure it by checking default-enablement conditions and adding the NEG Service annotation.
How it connects
Connects network endpoint groups with Ingress, NodePort, GKE Dataplane, and Pod readiness gates.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Google Anthos in Action. The section links point to the parts of the book it draws on.