GKE Ingress with Load Balancer in GCP - Step-by-Step Execution

Process Flow - GKE Ingress with Load Balancer

Create GKE Cluster

↓

Deploy Application Pods

↓

Create Service (NodePort or ClusterIP)

↓

Create Ingress Resource

↓

GKE Controller Creates Load Balancer

↓

External Traffic Routed to Load Balancer

↓

Load Balancer Forwards to Ingress Controller

↓

Ingress Routes Traffic to Service/Pods

↓

User Accesses Application via Load Balancer IP/URL

This flow shows how deploying an Ingress in GKE triggers creation of a Load Balancer that routes external traffic to your app pods.

Execution Sample

GCP

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f ingress.yaml
kubectl get ingress my-ingress

Deploy app, service, and ingress; then check the ingress status and external IP.

Process Table

Step	Command	Action	Result/Output
1	kubectl apply -f deployment.yaml	Create Deployment with app pods	deployment.apps/my-app created
2	kubectl apply -f service.yaml	Create Service exposing pods	service/my-service created
3	kubectl apply -f ingress.yaml	Create Ingress resource	ingress.networking.k8s.io/my-ingress created
4	GKE Controller	Detects Ingress, provisions Load Balancer	Load Balancer provisioning started
5	kubectl get ingress my-ingress	Check Ingress status	ADDRESS=34.123.45.67 HOSTS=example.com
6	User accesses http://34.123.45.67	Traffic routed via Load Balancer to pods	Application responds with homepage
7	Load Balancer health checks pods	Ensures pods are healthy	Pods marked healthy, traffic flows
8	Pods scale or update	Ingress and Load Balancer update routing	Traffic continues uninterrupted
9	End	All components running and serving traffic	Ingress IP stable, app accessible

💡 Ingress IP assigned and Load Balancer active, traffic routing established

Status Tracker

Resource	Initial State	After Deployment	After Service	After Ingress	Final State
Deployment	Not present	Pods running	Pods running	Pods running	Pods running
Service	Not present	Not present	Service created	Service created	Service created
Ingress	Not present	Not present	Not present	Ingress created	Ingress active with IP
Load Balancer	Not present	Not present	Not present	Provisioning started	Active with external IP

Key Moments - 3 Insights

Why does the Load Balancer IP appear only after creating the Ingress?

The Load Balancer is created by GKE only when an Ingress resource is applied, as shown in execution_table step 4 and 5.

What happens if the pods are unhealthy during Load Balancer health checks?

The Load Balancer stops sending traffic to unhealthy pods to avoid errors, ensuring only healthy pods serve requests (step 7).

Does the Service type affect the Load Balancer creation?

No, the Load Balancer is created by the Ingress controller regardless of Service type; Service just routes traffic internally (step 3 and 4).

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the Load Balancer start provisioning?

A Step 2

B Step 4

C Step 6

D Step 1

💡 Hint

Check the 'Action' column for Load Balancer provisioning in execution_table step 4.

According to variable_tracker, what is the state of the Ingress resource after applying the service.yaml?

A Not present

B Ingress created

C Ingress active with IP

D Pods running

💡 Hint

Look at the 'Ingress' row and 'After Service' column in variable_tracker.

If the pods become unhealthy, what does the Load Balancer do according to the key moments?

A Continues sending traffic to all pods

B Deletes the pods

C Stops sending traffic to unhealthy pods

D Creates new pods automatically

💡 Hint

Refer to key_moments about Load Balancer health checks and traffic routing.

Concept Snapshot

GKE Ingress with Load Balancer:
- Deploy app pods and Service
- Create Ingress resource
- GKE provisions external Load Balancer
- Load Balancer routes external traffic to pods
- Health checks ensure traffic only to healthy pods
- Ingress IP appears after Load Balancer is ready

Full Transcript

This visual execution shows how deploying an Ingress in Google Kubernetes Engine triggers the creation of an external Load Balancer. First, you deploy your application pods and expose them with a Service. Then, when you create an Ingress resource, GKE detects it and starts provisioning a Load Balancer. The Load Balancer gets an external IP address, which you can see by checking the Ingress status. User traffic to this IP is routed through the Load Balancer to the Ingress controller, which forwards it to your pods. The Load Balancer performs health checks to ensure only healthy pods receive traffic. If pods become unhealthy, the Load Balancer stops sending traffic to them, maintaining application availability. This process allows external users to access your application securely and reliably through a single IP address managed by GKE.

Practice

1. What is the main purpose of using an Ingress with a Load Balancer in GKE?

easy

A. To restrict access to the cluster nodes only

B. To expose multiple services through a single external IP address

C. To create multiple IP addresses for each pod

D. To manage internal DNS records automatically

Solution

1. Step 1: Understand Ingress role in GKE

   Ingress allows routing external traffic to multiple services inside the cluster using one IP.

2. Step 2: Recognize Load Balancer function

   The Load Balancer created by Ingress exposes a single external IP to route traffic.

3. Final Answer:

   To expose multiple services through a single external IP address -> Option B

4. Quick Check:

   Ingress + Load Balancer = Single IP for many services [OK]

Hint: Ingress combines services under one IP address [OK]

Common Mistakes:

• Thinking each pod gets its own IP
• Confusing internal DNS with external exposure
• Assuming Load Balancer creates multiple IPs

2. Which annotation is used in a GKE Ingress resource to specify the creation of a Google Cloud HTTP(S) Load Balancer?

easy

A. cloud.google.com/load-balancer-type: 'internal'

B. kubernetes.io/ingress.class: 'nginx'

C. kubernetes.io/ingress.class: 'gce'

D. networking.gke.io/load-balancer: 'external'

Solution

1. Step 1: Identify GKE Ingress annotation for Load Balancer

   The annotation 'kubernetes.io/ingress.class: gce' tells GKE to use Google Cloud Load Balancer.

2. Step 2: Differentiate from other ingress classes

   'nginx' is for NGINX ingress controller, not GCP Load Balancer.

3. Final Answer:

   kubernetes.io/ingress.class: 'gce' -> Option C

4. Quick Check:

   Use 'gce' annotation for GCP Load Balancer [OK]

Hint: Use 'kubernetes.io/ingress.class: gce' for GCP Load Balancer [OK]

Common Mistakes:

• Using 'nginx' instead of 'gce' annotation
• Confusing internal vs external load balancer annotations
• Using non-existent annotation keys

3. Given this Ingress YAML snippet, what will happen when a user visits http://example.com/api?

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

medium

A. Traffic to /api goes to api-service; all other paths go to web-service

B. Traffic to /api goes to web-service; all other paths go to api-service

C. All traffic goes to api-service regardless of path

D. Ingress will reject traffic because of conflicting paths

Solution

1. Step 1: Analyze path rules in Ingress

   The rule for path '/api' with pathType Prefix directs matching requests to 'api-service'.

2. Step 2: Understand default path routing

   The path '/' with Prefix matches all other requests and routes them to 'web-service'.

3. Final Answer:

   Traffic to /api goes to api-service; all other paths go to web-service -> Option A

4. Quick Check:

   Specific path matches first, then default [OK]

Hint: Specific paths route before general '/' path [OK]

Common Mistakes:

• Assuming '/' path overrides /api
• Thinking all traffic goes to one service
• Believing Ingress rejects overlapping paths

4. You created an Ingress with annotation kubernetes.io/ingress.class: nginx in GKE but no external IP is assigned. What is the likely cause?

medium

A. GKE does not create a Google Cloud Load Balancer for 'nginx' ingress class

B. The Ingress resource is missing the service port definition

C. The cluster nodes are not labeled correctly

D. The Ingress controller is automatically created and running

Solution

1. Step 1: Understand Ingress class annotation effect

   Annotation 'nginx' tells GKE to use NGINX ingress controller, which does not create a GCP Load Balancer automatically.

2. Step 2: Recognize Load Balancer creation requirements

   Only 'gce' ingress class triggers Google Cloud Load Balancer creation with external IP.

3. Final Answer:

   GKE does not create a Google Cloud Load Balancer for 'nginx' ingress class -> Option A

4. Quick Check:

   'nginx' ingress needs separate controller, no auto Load Balancer [OK]

Hint: Use 'gce' annotation for auto Load Balancer in GKE [OK]

Common Mistakes:

• Assuming 'nginx' creates GCP Load Balancer automatically
• Blaming missing service port for no IP
• Thinking cluster node labels affect Load Balancer creation

5. You want to expose two services, frontend and backend, on the same IP but different paths using GKE Ingress with a Load Balancer. Which YAML snippet correctly configures this?

hard

A. apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: multi-service-ingress
annotations:
kubernetes.io/ingress.class: "gce"
spec:
rules:
- http:
paths:
- path: /frontend
pathType: Prefix
backend:
service:
name: frontend
port:
number: 80
- path: /backend
pathType: Prefix
backend:
service:
name: backend
port:
number: 80

B. apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: multi-service-ingress
spec:
rules:
- host: "*"
http:
paths:
- path: /frontend
backend:
serviceName: frontend
servicePort: 80
- path: /backend
backend:
serviceName: backend
servicePort: 80

C. apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: multi-service-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: example.com
http:
paths:
- path: /frontend
pathType: Prefix
backend:
service:
name: frontend
port:
number: 80
- path: /backend
pathType: Prefix
backend:
service:
name: backend
port:
number: 80

D. apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: multi-service-ingress
annotations:
kubernetes.io/ingress.class: "gce"
spec:
rules:
- host: example.com
http:
paths:
- path: /frontend
pathType: Prefix
backend:
service:
name: frontend
port:
number: 80
- path: /backend
pathType: Prefix
backend:
service:
name: backend
port:
number: 80

Solution

1. Step 1: Confirm correct annotation for GCP Load Balancer

   Options A and D use 'kubernetes.io/ingress.class: gce', which is correct for GKE Load Balancer.

2. Step 2: Check pathType and host usage

   apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: multi-service-ingress annotations: kubernetes.io/ingress.class: "gce" spec: rules: - host: example.com http: paths: - path: /frontend pathType: Prefix backend: service: name: frontend port: number: 80 - path: /backend pathType: Prefix backend: service: name: backend port: number: 80 uses 'Prefix' pathType with a host, ensuring precise routing for /frontend and /backend paths on example.com.

3. Step 3: Identify deprecated or incorrect syntax

   apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: multi-service-ingress spec: rules: - host: "*" http: paths: - path: /frontend backend: serviceName: frontend servicePort: 80 - path: /backend backend: serviceName: backend servicePort: 80 uses deprecated 'serviceName' and 'servicePort' keys and lacks annotation; apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: multi-service-ingress annotations: kubernetes.io/ingress.class: "nginx" spec: rules: - host: example.com http: paths: - path: /frontend pathType: Prefix backend: service: name: frontend port: number: 80 - path: /backend pathType: Prefix backend: service: name: backend port: number: 80 uses 'nginx' ingress class, not GCE; apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: multi-service-ingress annotations: kubernetes.io/ingress.class: "gce" spec: rules: - http: paths: - path: /frontend pathType: Prefix backend: service: name: frontend port: number: 80 - path: /backend pathType: Prefix backend: service: name: backend port: number: 80 is missing host and incomplete.

4. Final Answer:

   Option D correctly configures two services on same IP with prefix path matching and GCE Load Balancer -> Option D

5. Quick Check:

   Use 'gce' annotation + prefix paths + host for precise multi-service routing [OK]

Hint: Use 'gce' annotation and prefix pathType for multi-service routing [OK]

Common Mistakes:

• Using 'nginx' annotation instead of 'gce'
• Using deprecated serviceName/servicePort keys
• Not specifying host or using wrong pathType