Load Balancing GKE Traffic Ingress

In this guide, you’ll learn how Kubernetes Ingress routes incoming HTTPS traffic to applications running in a Google Kubernetes Engine (GKE) cluster. We’ll cover external and internal load balancers, then introduce container-native load balancing with Network Endpoint Groups (NEGs).

Kubernetes Ingress Overview

Kubernetes Ingress lets you define HTTP(S) routing rules based on hostnames and paths. In GKE:

Ingress resource → Provisions an external or internal application load balancer
Service definitions → Determine backend Pods and ports

By customizing your Ingress manifest, you control TLS termination, virtual hosts, and URL-based routing.

External Load Balancer

An external application load balancer routes internet traffic to your GKE Services and Pods. When you create an Ingress for external HTTPS:

GKE provisions a global HTTP(S) load balancer
TLS is terminated at the load balancer
Requests are forwarded to Service backends

Use an external load balancer when exposing public-facing applications.

Internal Load Balancer

An internal application load balancer handles traffic within the same VPC or cluster. For an internal HTTPS Ingress:

GKE creates a regional, proxy-based load balancer
It uses an internal IP address on your Service
Connections are terminated and proxied to backend Pods

Backend Pods see the load balancer as the request source, not the original client.

The image is a diagram illustrating the architecture of an internal load balancer within a Google Kubernetes Engine (GKE) setup, showing components like GKE clusters, pods, and internal clients. It also mentions elements of an external load balancer, such as forwarding rules and health checks.

Warning

Any manual edits to load balancer components (forwarding rules, target proxies, etc.) made outside GKE can be overwritten when the cluster updates. The GKE Ingress controller fully manages these resources according to your Ingress manifest.

Container-Native Load Balancing

GKE’s container-native load balancing uses NEGs to attach Pods directly as backends. This eliminates extra network hops and improves performance:

Routes traffic from the load balancer straight to Pod IPs
Bypasses NodePort and kube-proxy hops
Performs Pod readiness checks at the load balancer

The image is a diagram illustrating the architecture of an internal load balancer within a Google Kubernetes Engine (GKE) cluster, showing components like pods, internal clients, and the GKE control plane.

Comparing Load Balancer Options

Load Balancer Type	Scope	Traffic Path	Health Checks
External HTTP(S)	Global, Internet	Client → LB → Service → Pod	HTTP(S) at LB
Internal HTTP(S)	Regional, VPC	Client → Internal LB → Service → Pod	HTTP(S) at LB
Container-Native (NEG-based)	Global or Regional	Client → LB → Pod (direct via NEG)	Pod readiness at LB

Watch Video