Skip to main content
In this lesson, we’ll explore the Kubernetes Service type LoadBalancer. We begin with a quick recap of NodePort, then introduce LoadBalancer and demonstrate how to provision a cloud load balancer automatically.

1. Recap: Kubernetes NodePort Service

A NodePort exposes a Service on a static port (the NodePort) on every node in your cluster. For example, if you expose the voting app on port 31000 and the result app on port 32000, external users can reach them via:
  • http://<node-ip>:31000
  • http://<node-ip>:32000
Even if your Pods run only on nodes with IPs 10.0.0.70 and 10.0.0.71, they remain accessible on the same port across all nodes in the cluster.

2. Limitations of NodePort

While NodePort is straightforward, it has some drawbacks:
  • No single friendly URL for end users
  • Manual management of external load balancer infrastructure
  • Exposure of high-range ports (30000–32767)
Managing separate load balancer VMs (HAProxy, NGINX, etc.) increases operational overhead.

3. Introducing the LoadBalancer Service

On supported cloud platforms (GCP, AWS, Azure), setting type: LoadBalancer in your Service manifest will:
  1. Provision a native cloud load balancer
  2. Configure forwarding rules to cluster nodes
  3. Distribute traffic across Service endpoints
Here’s a sample voting-service.yaml:
Apply it with:
The image is a diagram of an example voting app architecture on Google Cloud Platform, showing nodes, pods, and services with a load balancer. It includes URLs for the voting and result apps.
type: LoadBalancer only works on supported cloud environments. In unsupported setups (e.g., VirtualBox), Kubernetes falls back to assigning a NodePort without provisioning an external load balancer.

4. Comparing Service Types

Watch Video