Container-native load balancing

Container-native load balancing enables several kinds of load balancers to target Pods directly and to evenly distribute their traffic to Pods.

Container-native load balancing leverages a data model called network endpoint groups (NEGs). NEGs are collections of network endpoints represented by IP-port pairs.

When NEGs are used with GKE Ingress, the Ingress controller facilitates the creation of all aspects of the L7 load balancer. This includes creating the virtual IP address, forwarding rules, health checks, firewall rules, and more.

For more flexibility, you can also create standalone NEGs. In this case, you are responsible for creating and managing all aspects of the L7 load balancer.

Benefits

Container-native load balancing offers the following benefits:

Pods are core objects for load balancing
kube-proxy configures nodes' iptables rules to distribute traffic to Pods. Without container-native load balancing, load balancer traffic travels to the node instance groups and gets routed via iptables rules to Pods which might or might not be in the same node. With container-native load balancing, load balancer traffic is distributed directly to the Pods which should receive the traffic, eliminating the extra network hop. Container-native load balancing also helps with improved health checking since it targets Pods directly.

Comparison of default behavior (left) with container-native load balancer behavior.
Improved network performance
Because the container-native load balancer talks directly with the Pods, and connections have fewer network hops, both latency and throughput are improved.
Increased visibility
With container-native load balancing, you have visibility into the latency from the HTTP(S) load balancer to Pods. The latency from the HTTP(S) load balancer to each Pod is visible, which were aggregated with node IP-base container-native load balancing. This makes troubleshooting your services at the NEG-level easier.
Support for advanced Load Balancing features
Container-native load balancing offer native support in Google Kubernetes Engine for several features of HTTP(S) Load Balancing, such as integration with Google Cloud services like Google Cloud Armor, Cloud CDN, and Identity-Aware Proxy. It also features load balancing algorithms for accurate traffic distribution.
Support for Traffic Director
The NEG data model is required to use Traffic Director, Google Cloud's fully managed traffic control plane for service mesh.

Pod readiness

For relevant Pods, the corresponding Ingress controller manages a readiness gate of type cloud.google.com/load-balancer-neg-ready. The Ingress controller polls the load balancer's health check status, which includes the health of all endpoints in the NEG. When the load balancer's health check status indicates that the endpoint corresponding to a particular Pod is healthy, the Ingress controller sets the Pod's readiness gate value to True. The kubelet running on each Node then computes the Pod's effective readiness, considering both the value of this readiness gate and, if defined, the Pod's readiness probe.

For container-native load balancing through ingress, Pod readiness gates are automatically enabled in:

  • v1.13 GKE clusters running v1.13.8 and higher
  • v1.14 GKE clusters running v1.14.4 and higher
  • v1.15 and higher

Readiness gates control the rate of a rolling update. GKE versions listed above automatically add readiness gates to Pods. When you initiate a rolling update, as GKE creates new Pods, an endpoint for each new Pod is added to a NEG. When the endpoint is healthy from the perspective of the load balancer, the Ingress controller sets the readiness gate to True. Thus, a newly created Pod must at least pass its readiness gate before GKE removes an old Pod. This ensures that the corresponding endpoint for the Pod has already passed the load balancer's health check and that the backend capacity is maintained.

If a Pod's readiness gate never indicates that the Pod is ready, due to a bad container image or a misconfigured load balancer health check, the load balancer won't direct traffic to the new Pod. If such a failure occurs while rolling out an updated Deployment, the rollout stalls after attempting to create one new Pod because that Pod's readiness gate is never True. See the troubleshooting section for information on how to detect and fix this situation.

Without container-native load balancing and readiness gates, GKE can't detect if a load balancer's endpoints are healthy before marking Pods as ready. In previous Kubernetes versions, you control the rate that Pods are removed and replaced by specifying a delay period (minReadySeconds in the Deployment specification).

Requirements

Container-native load balancers through ingress on GKE have the following requirements:

Google Kubernetes Engine version

Container-native load balancers are generally available in:

  • v1.13 GKE clusters running v1.13.8 and higher
  • v1.14 GKE clusters running v1.14.4 and higher
  • v1.15 and higher
VPC-native

To use container-native load balancing, clusters must be VPC-native. To learn more, refer to Creating VPC-native clusters using Alias IPs.

HTTP load balancing

To use container-native load balancing, your cluster must have HTTP load-balancing enabled. GKE clusters have HTTP load-balancing enabled by default; you must not disable it.

Restrictions

Container-native load balancers do not work with legacy networks.

Limitations

Container-native load balancers do not support internal TCP/UDP load balancers or network load balancers.

Pricing

You are charged for the HTTP(S) load balancer provisioned by the Ingress that you create in this guide. For load balancer pricing information, refer to Load balancing and forwarding rules on the VPC pricing page.

What's next