From URL to Pod: Understanding GKE Load Balancers, Backend Services, and NEGs

Overview

Scenario: GKE-native Ingress (with `gce` Ingress Class)

We assume the following:

You're using GKE's built-in HTTP(S) load balancer (created by the gce ingress controller).
Your Kubernetes Service has been annotated to enable NEGs.
You’ve exposed your application to the internet using an Ingress.

Step-by-Step Flow

1. User Enters the URL

The user opens a browser and visits:

https://myapp.example.com

DNS resolves this domain to an external IP address (e.g. 34.102.13.75).

2. GCP HTTP(S) Load Balancer Receives the Request

This IP belongs to a GCP global HTTP(S) Load Balancer automatically created by the gce ingress controller. It acts as the public entry point for the application.

The load balancer listens on ports 80 and 443.
It uses URL maps to decide where traffic should be routed based on the host and path.

3. Load Balancer Routes to a Backend Service

The load balancer forwards the request to a GCP Backend Service based on the Ingress rules and URL map.

The backend service performs health checks.
It knows how to route to NEGs or managed instance groups.

4. Backend Service Uses NEGs

The Network Endpoint Group (NEG) contains a list of endpoints that traffic can be forwarded to.

Each endpoint is an IP:Port of a Kubernetes Pod, such as 10.84.3.176:3000.
These IPs come from the subnet that the GKE pods live in.

5. Traffic Reaches the Pod

Once the backend service forwards the request to an endpoint in the NEG, the request is sent directly to the pod. This enables container-native load balancing.

6. Pod Responds

Your application running inside the pod handles the request and sends the response back through the same path—NEG → Load Balancer → User.

Glossary

Component	Description
Load Balancer	The public-facing entry point that receives traffic.
URL Map	Defines rules for routing traffic based on host/path.
Backend Service	Manages health checks and distributes traffic to NEGs.
NEG	A list of IP:Port entries pointing to pods.
Pod	The actual containerized app that serves requests.
Subnet	A range of IPs in your VPC where the pods get their addresses.

Visual Flow (Text Diagram)

Browser
  ↓
DNS → myapp.example.com → 34.102.13.75
  ↓
GCP HTTP(S) Load Balancer (Frontend IP)
  ↓
URL Map → Backend Service (manages health + load balancing)
  ↓
NEG (Network Endpoint Group with pod IPs/ports)
  ↓
Pod (e.g., 10.84.3.176:3000)
  ↓
App handles request → returns response

Final Notes

The Load Balancer is not part of your subnet but connects to it to reach GKE nodes or pods.
You can verify backend services with:

gcloud compute backend-services list

NEGs are created when you annotate your Service properly, e.g.:

annotations:
  cloud.google.com/neg: '{"ingress": true}'

This setup enables efficient, scalable, and direct traffic routing to your containers in GKE.