LoadBalancer service type in Kubernetes - Commands & Configuration

Introduction

Sometimes you want your app to be reachable from outside your cluster. The LoadBalancer service type creates a network load balancer that routes external traffic to your app automatically.

When you want to expose a web app running in Kubernetes to the internet with a stable IP address.

When you need to distribute incoming traffic evenly across multiple app instances.

When you want cloud provider integration to automatically create a load balancer for your service.

When you want to avoid manually configuring external routers or firewalls.

When you want a simple way to get external access without complex networking setup.

Config File - loadbalancer-service.yaml

loadbalancer-service.yaml

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

This file defines a Service named example-loadbalancer that exposes pods with label app: example-app.

The type: LoadBalancer tells Kubernetes to create an external load balancer.

The service listens on port 80 and forwards traffic to port 8080 on the pods.

Commands

This command creates the LoadBalancer service in your Kubernetes cluster using the configuration file.

Terminal

kubectl apply -f loadbalancer-service.yaml

Expected Output

service/example-loadbalancer created

This command checks the status of the LoadBalancer service and shows its external IP once assigned.

Terminal

kubectl get services example-loadbalancer

Expected Output

NAME                  TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE

example-loadbalancer   LoadBalancer   10.96.123.45    34.123.45.67    80:31234/TCP   10s

This command shows detailed information about the LoadBalancer service, including endpoints and events.

Terminal

kubectl describe service example-loadbalancer

Expected Output

Name:                     example-loadbalancer

Namespace:                default

Labels:                   <none>

Annotations:              <none>

Selector:                 app=example-app

Type:                     LoadBalancer

IP:                       10.96.123.45

LoadBalancer Ingress:     34.123.45.67

Port:                     <unset>  80/TCP

TargetPort:               8080/TCP

Endpoints:                192.168.1.10:8080,192.168.1.11:8080

Session Affinity:         None

Events:

  Type    Reason                Age   From                Message

  ----    ------                ----  ----                -------

  Normal  EnsuringLoadBalancer  10s   service-controller  Ensuring load balancer

  Normal  EnsuredLoadBalancer   5s    service-controller  Ensured load balancer

Key Concept

If you remember nothing else from this pattern, remember: the LoadBalancer service type automatically creates an external IP to route traffic to your app pods.

Common Mistakes

Using LoadBalancer service type on a local Kubernetes cluster without cloud provider support.

Local clusters like minikube or kind do not support automatic external load balancers, so the EXTERNAL-IP stays pending.

Use NodePort or port forwarding for local clusters, or use a cloud Kubernetes service for LoadBalancer support.

Not labeling pods with the selector labels defined in the service.

The service cannot find any pods to route traffic to, so no endpoints are available.

Ensure pods have the correct labels matching the service selector.

Summary

Create a LoadBalancer service YAML file to expose your app externally.

Apply the service with kubectl apply to create it in the cluster.

Check the service status and external IP with kubectl get services.

Use kubectl describe to see detailed info and troubleshoot.

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