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.