Ingress for Internal HTTP(S) Load Balancing

This page explains how Ingress for Internal HTTP(S) Load Balancing works in Google Kubernetes Engine (GKE). You can also learn how to set up and use Ingress for Internal HTTP(S) Load Balancing.

In GKE, the internal HTTP(S) load balancer is a proxy-based, regional, Layer 7 load balancer that enables you to run and scale your services behind an internal load balancing IP address. GKE Ingress objects support the internal HTTP(S) load balancer natively through the creation of Ingress objects on GKE clusters.

For general information about using Ingress for load balancing in GKE, see HTTP(S) load balancing with Ingress.

Benefits of using Ingress for the internal HTTP(S) load balancer

Using GKE Ingress for Internal HTTP(S) Load Balancing provides the following benefits:

  • A highly available, GKE-managed Ingress controller.
  • Load balancing for internal, service-to-service communication.
  • Container-native load balancing with Network Endpoint Groups (NEG).
  • Application routing with HTTP and HTTPS support.
  • High-fidelity Compute Engine health checks for resilient services.
  • Envoy-based proxies that are deployed on-demand to meet traffic capacity needs.

Support for Google Cloud features

Ingress for Internal HTTP(S) Load Balancing supports a variety of additional features.

Required networking environment

The internal HTTP(S) load balancer provides a pool of proxies for your network. The proxies evaluate where each HTTP(S) request should go based on factors such as the URL map, the BackendService's session affinity, and the balancing mode of each backend NEG.

A region's internal HTTP(S) load balancer uses the proxy-only subnet for that region in your VPC network to assign internal IP addresses to each proxy created by Google Cloud.

By default, the IP address assigned to a load balancer's forwarding rule comes from the node's subnet range assigned by GKE instead of from the proxy-only subnet. You can also manually specify an IP address for the forwarding rule from any subnet when you create the rule.

The following diagram provides an overview of the traffic flow for internal HTTP(S) load balancer.

Ingress for Internal HTTP(S) Load Balancing diagram

Here's how the internal HTTP(S) load balancer works:

  1. A client makes a connection to the IP address and port of the load balancer's forwarding rule.
  2. A proxy receives and terminates the client's network connection.
  3. The proxy establishes a connection to the appropriate endpoint (Pod) in a NEG, as determined by the load balancer's URL map, and backend services.

Each proxy listens on the IP address and port specified by the corresponding load balancer's forwarding rule. The source IP address of each packet sent from a proxy to an endpoint is the internal IP address assigned to that proxy from the proxy-only subnet.

The GKE Ingress Controller manages deployment of firewall rules, so you do not need to manually deploy them.

What's next