Demo Configure container native load balancing using Ingress

In this tutorial, you’ll learn how to set up container-native load balancing for your GKE applications using Ingress and Network Endpoint Groups (NEGs). We’ll cover:

1. Creating a custom subnet in your VPC
2. Provisioning a VPC-native GKE cluster with IP aliasing
3. Deploying a simple HTTP server
4. Exposing it via Ingress backed by a NEG
5. Viewing the resulting Load Balancer and NEGs
6. Scaling the deployment and validating load balancing

This end-to-end guide uses Google Cloud Platform commands, Kubernetes manifests, and Console walkthroughs.

1. Create a custom subnet

First, create a /24 subnet in the default VPC in us-west1:

gcloud compute networks subnets create gke-deep-dive-subnet \
  --network=default \
  --region=us-west1 \
  --range=10.10.0.0/24

You can verify the new subnet under VPC networks > default VPC in the Cloud Console.

2. Provision a VPC-native GKE cluster

Set your Compute region and zone, then create a GKE cluster with IP aliasing enabled on the custom subnet:

gcloud config set compute/region us-west1
gcloud config set compute/zone us-west1-a

gcloud container clusters create gke-deep-dive \
  --num-nodes=1 \
  --disk-type=pd-standard \
  --disk-size=10 \
  --enable-ip-alias \
  --subnetwork=gke-deep-dive-subnet

3. Deploy the HTTP server application

We’ll deploy a basic HTTP server that responds with its Pod hostname.

3.1 Deployment manifest

Create a file named gke-deep-dive-app.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gke-deep-dive-app
  labels:
    app: gke-deep-dive-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gke-deep-dive-app
  template:
    metadata:
      labels:
        app: gke-deep-dive-app
    spec:
      containers:
        - name: gke-deep-dive
          image: gcr.io/google-containers/serve_hostname
          ports:
            - containerPort: 80
              protocol: TCP

Apply and verify:

kubectl apply -f gke-deep-dive-app.yaml
kubectl get pods

3.2 Service manifest

Expose the Deployment as a ClusterIP Service annotated for NEGs. Save as gke-deep-dive-svc.yaml:

apiVersion: v1
kind: Service
metadata:
  name: gke-deep-dive-svc
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    app: gke-deep-dive-app
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 80

Apply and confirm:

kubectl apply -f gke-deep-dive-svc.yaml
kubectl get svc

3.3 Ingress manifest

Create gke-deep-dive-ing.yaml to route HTTP traffic via Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gke-deep-dive-ing
spec:
  defaultBackend:
    service:
      name: gke-deep-dive-svc
      port:
        number: 80

Apply the Ingress:

kubectl apply -f gke-deep-dive-ing.yaml
kubectl get ingress

Once you have the IP, browse to:

http://<EXTERNAL_IP>

You should see the hostname of the serving Pod.

3.4 Resource manifest overview

4. View Load Balancer and NEG

In the Cloud Console, go to Network services > Load balancing. You’ll see an HTTP(S) Load Balancer created for your Ingress:

Click the Load Balancer name to view both frontend and backend configurations:

Select the backend service to inspect the NEG:

5. Scale and verify load balancing

Increase the Deployment to three replicas:

kubectl scale deployment gke-deep-dive-app --replicas=3
kubectl get deployment gke-deep-dive-app

Refresh your browser at the Ingress IP. You’ll see responses cycling through the three Pod hostnames, demonstrating container-native load balancing via Ingress + NEGs.

Links and References

• GKE documentation
• Kubernetes Ingress Guide
• Network Endpoint Groups
• VPC-Native Clusters (IP Aliasing)
• Google Cloud Console – Load Balancing