Understanding Ingress, Backend Services, and NEGs in GKE (Google Kubernetes Engine)

Overview

When deploying applications in Kubernetes on Google Cloud,

understanding how traffic reaches your pods is key.

In GKE, external HTTP(S) traffic is typically routed through a Google Cloud Load Balancer,

which works closely with three main components:

• Ingress
• Backend Service
• NEG (Network Endpoint Group)

Let’s break down each of these and how they fit together.

🔹 1. Ingress – The Entry Point and Routing Rules

In Kubernetes, an Ingress is a high-level resource that defines how external HTTP(S) traffic should be routed to internal services.

Example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80

This rule means:

When a request comes to myapp.example.com/api, route it to api-service inside the cluster.

In GKE:

• The Ingress is interpreted by the Ingress Controller (usually GKE’s native controller or NGINX).
• GKE uses this to configure a Google Cloud HTTP(S) Load Balancer.
• The routing rules are converted into a URL Map within the load balancer.

🔹 2. Backend Service – The Routing Hub

A Backend Service is a Google Cloud construct that:

• Receives requests from the URL Map
• Performs health checks
• Distributes traffic to a group of endpoints

You can think of it as the middle layer:

It doesn’t hold the endpoints itself — it connects to them through NEGs.

What it manages:

• Load balancing policies
• Session affinity (optional)
• Backend (NEG) configuration
• Health checks

In the context of Kubernetes:

• For every Kubernetes Service referenced by Ingress, GKE creates a Backend Service in Google Cloud.
• The backend service points to one or more NEGs that hold the actual Pod IPs or VM IPs.

🔹 3. NEG (Network Endpoint Group) – The Real Targets

A NEG is a group of actual endpoints where the load balancer sends traffic. Each entry in a NEG is an IP:Port combination — it could be:

• A Pod IP and container port (for container-native load balancing)
• A Node IP and NodePort (in older setups using VM-based NEGs)

Types of NEGs in GKE:

• GCE_POD: Direct Pod IPs (used with container-native load balancing)
• GCE_VM_IP_PORT: Node IP and port (used in default Ingress backends)

Why NEGs matter:

• They enable direct traffic routing to Pods (bypassing kube-proxy)
• They support fine-grained health checks at the Pod level
• They are required for HTTP(S) Load Balancers in GCP

How They Connect (Traffic Flow)

Here’s the simplified flow of how a request from the internet reaches a pod:

User
 ↓
Google Cloud HTTP(S) Load Balancer
 ↓
URL Map (from Ingress rules)
 ↓
Backend Service (handles routing, health checks)
 ↓
NEG (list of actual Pod or VM IPs)
 ↓
Pod (your application)

Summary Table

🔍 Practical Notes

• GKE automatically creates one Load Balancer per Ingress (unless you configure otherwise).
• If your Ingress doesn’t specify ingressClassName: nginx, it may default to the GCE controller, which provisions a Google-managed load balancer.
• NEGs must be healthy and populated for traffic to flow to your pods.
• You can inspect these with:

gcloud compute backend-services describe [name] --global
gcloud compute network-endpoint-groups describe [neg-name] --zone=[zone]