LoadBalancer service type in Kubernetes - Step-by-Step Execution

Process Flow - LoadBalancer service type

Create Service YAML with type LoadBalancer

↓

kubectl apply -f service.yaml

↓

Kubernetes requests cloud provider

↓

Cloud provider provisions external LoadBalancer

↓

External IP assigned to Service

↓

Clients access Service via External IP

↓

LoadBalancer forwards traffic to Pods

↓

Service works

This flow shows how creating a LoadBalancer service in Kubernetes triggers cloud provider actions to expose the service externally.

Execution Sample

Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

This YAML defines a LoadBalancer service exposing pods with label app=my-app on port 80 externally.

Process Table

Step	Action	Kubernetes State	Cloud Provider Action	Result
1	Apply service YAML	Service object created with type LoadBalancer	None yet	Service pending external IP
2	Kubernetes requests cloud provider	Service status pending	Provision external LoadBalancer	LoadBalancer resource created
3	Cloud provider creates LoadBalancer	Service status updating	Assign external IP	External IP assigned to Service
4	Service ready	Service has external IP	LoadBalancer forwards traffic	Clients can access service externally
5	Client sends request	Request received by LoadBalancer	Forward to pod endpoints	Pods receive traffic
6	Pods respond	Response sent back through LoadBalancer	Response forwarded to client	Client receives response
7	End	Service running with external IP	LoadBalancer active	Operation complete

💡 Service has external IP and traffic flows through LoadBalancer to pods

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
Service Object	None	Created with type LoadBalancer	Pending external IP	External IP assigned	Ready with external IP
External IP	None	None	None	Assigned (e.g. 34.68.12.34)	Assigned (e.g. 34.68.12.34)
LoadBalancer Status	None	None	Provisioning	Active	Active

Key Moments - 3 Insights

Why does the Service not have an external IP immediately after creation?

Because Kubernetes must first request the cloud provider to create the LoadBalancer, which takes time. See execution_table step 2 and 3 where the external IP is assigned only after provisioning.

What happens if the cloud provider does not support LoadBalancer services?

The Service will remain without an external IP and stay in pending state. This is shown in execution_table step 2 where the cloud provider action is required but may not happen.

How does traffic reach the pods from the external IP?

The LoadBalancer forwards incoming traffic to the pods selected by the Service selector. This is shown in execution_table steps 5 and 6.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the external IP assigned to the Service?

A Step 3

B Step 5

C Step 1

D Step 7

💡 Hint

Check the 'External IP assigned to Service' result in the rows.

According to variable_tracker, what is the state of the Service Object after Step 2?

A External IP assigned

B Created with type LoadBalancer

C Pending external IP

D Ready with external IP

💡 Hint

Look at the 'Service Object' row under 'After Step 2' column.

If the cloud provider fails to provision the LoadBalancer, what will happen to the Service status?

A Service will have an external IP

B Service will remain pending without external IP

C Service will be deleted automatically

D Service will switch to ClusterIP type

💡 Hint

Refer to key_moments about cloud provider support and execution_table step 2.

Concept Snapshot

LoadBalancer Service in Kubernetes:
- type: LoadBalancer exposes service externally
- Kubernetes requests cloud provider to create LoadBalancer
- External IP assigned after provisioning
- Traffic flows from external IP to pods
- Requires cloud provider support

Full Transcript

This visual execution shows how a Kubernetes Service of type LoadBalancer works. First, you create a Service YAML with type LoadBalancer and apply it. Kubernetes then asks the cloud provider to create an external LoadBalancer. The cloud provider provisions it and assigns an external IP to the Service. Clients can then access the Service using this external IP. The LoadBalancer forwards traffic to the pods selected by the Service. The execution table traces each step from creation to traffic flow. The variable tracker shows how the Service object and external IP change state. Key moments clarify common confusions like why the external IP is not immediate and what happens if the cloud provider does not support LoadBalancer. The quiz tests understanding of when the external IP is assigned and the Service status during provisioning.

Practice

1. What does the LoadBalancer service type do in Kubernetes?

easy

A. It creates multiple internal IPs for the service.

B. It only exposes the service inside the cluster without external access.

C. It exposes the service externally with a cloud provider's load balancer and a single external IP.

D. It automatically scales the number of pods based on load.

Solution

1. Step 1: Understand LoadBalancer service purpose

   The LoadBalancer service type is designed to expose a Kubernetes service externally using a cloud provider's load balancer.

2. Step 2: Identify the external IP behavior

   It provides a single external IP address that routes traffic to the service pods.

3. Final Answer:

   It exposes the service externally with a cloud provider's load balancer and a single external IP. -> Option C

4. Quick Check:

   LoadBalancer = external IP + cloud load balancer [OK]

Hint: LoadBalancer = external IP + cloud load balancer [OK]

Common Mistakes:

• Confusing LoadBalancer with ClusterIP (internal only)
• Thinking it creates multiple external IPs
• Assuming it auto-scales pods

2. Which of the following is the correct YAML snippet to create a LoadBalancer service in Kubernetes?

easy

A. apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: NodePort
ports:
- port: 80
selector:
app: my-app

B. apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: ExternalName
ports:
- port: 80
selector:
app: my-app

C. apiVersion: v1
kind: Pod
metadata:
name: my-service
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: my-app

D. apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: my-app

Solution

1. Step 1: Identify correct kind and type

   The resource must be kind: Service and spec.type: LoadBalancer to create a LoadBalancer service.

2. Step 2: Check YAML correctness

   apiVersion: v1 kind: Service metadata: name: my-service spec: type: LoadBalancer ports: - port: 80 selector: app: my-app correctly uses kind: Service and type: LoadBalancer with proper ports and selector.

3. Final Answer:

   YAML with kind: Service and type: LoadBalancer -> Option D

4. Quick Check:

   LoadBalancer service YAML uses kind: Service + type: LoadBalancer [OK]

Hint: LoadBalancer service YAML: kind Service + type LoadBalancer [OK]

Common Mistakes:

• Using kind: Pod instead of Service
• Using wrong service type like NodePort or ExternalName
• Missing selector or ports section

3. Given this service YAML with type LoadBalancer, what will kubectl get svc my-service show for the EXTERNAL-IP field after creation?

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: my-app

medium

A. An external IP address like 34.68.123.45

B. <none>

C. Pending

D. ClusterIP address like 10.0.0.1

Solution

1. Step 1: Understand LoadBalancer external IP assignment

   When a LoadBalancer service is created, the cloud provider assigns an external IP address to the service, visible in EXTERNAL-IP field.

2. Step 2: Recognize typical EXTERNAL-IP values

   Initially, EXTERNAL-IP may show Pending, but after provisioning, it shows an actual external IP like 34.68.123.45.

3. Final Answer:

   An external IP address like 34.68.123.45 -> Option A

4. Quick Check:

   LoadBalancer EXTERNAL-IP = cloud IP address [OK]

Hint: LoadBalancer EXTERNAL-IP shows cloud IP, not ClusterIP [OK]

Common Mistakes:

• Expecting <none> or ClusterIP in EXTERNAL-IP field
• Confusing Pending state as final
• Thinking LoadBalancer does not assign external IP

4. You created a LoadBalancer service but kubectl get svc shows EXTERNAL-IP as "Pending" indefinitely. What is the most likely cause?

medium

A. The Kubernetes cluster is not running on a cloud provider that supports LoadBalancer.

B. The service selector does not match any pods.

C. The service type is incorrectly set to ClusterIP.

D. The pod containers do not expose the correct port.

Solution

1. Step 1: Understand LoadBalancer external IP provisioning

   LoadBalancer service requires cloud provider support to provision an external IP and load balancer.

2. Step 2: Identify cause of Pending EXTERNAL-IP

   If the cluster runs on bare metal or unsupported environment, the external IP stays Pending indefinitely.

3. Final Answer:

   The Kubernetes cluster is not running on a cloud provider that supports LoadBalancer. -> Option A

4. Quick Check:

   Pending EXTERNAL-IP means no cloud LB support [OK]

Hint: Pending EXTERNAL-IP means no cloud load balancer support [OK]

Common Mistakes:

• Blaming pod selector or ports for EXTERNAL-IP Pending
• Confusing service type ClusterIP with LoadBalancer
• Ignoring cluster environment limitations

5. You want to expose a Kubernetes app externally with a LoadBalancer service, but your cluster runs on bare metal without cloud support. Which approach will work best?

hard

A. Use ClusterIP service type and access pods internally only.

B. Change service type to NodePort and use external node IP with the node port.

C. Use LoadBalancer service type and wait for external IP assignment.

D. Delete the service and expose pods directly with hostPort.

Solution

1. Step 1: Recognize LoadBalancer limitation on bare metal

   LoadBalancer service requires cloud provider support, which bare metal lacks, so it won't get an external IP.

2. Step 2: Choose alternative external exposure method

   NodePort exposes the service on each node's IP at a static port, allowing external access without cloud load balancer.

3. Final Answer:

   Change service type to NodePort and use external node IP with the node port. -> Option B

4. Quick Check:

   Bare metal + external access = NodePort service [OK]

Hint: Bare metal clusters use NodePort for external access, not LoadBalancer [OK]

Common Mistakes:

• Expecting LoadBalancer to work without cloud support
• Using ClusterIP which is internal only
• Exposing pods directly with hostPort is less flexible