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
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
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
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
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 |