Services Loadbalancer

In Kubernetes, a Service of type LoadBalancer provides a single external IP or hostname that routes traffic to Pods running in the cluster. This is especially useful for exposing front-end applications (for example, a voting app and a result app) that are running on worker nodes. Previously we looked at the NodePort Service, which exposes each Service on a high port on every node in the cluster. For a four-node cluster, exposing both frontends with NodePort yields many possible node IP:port combinations, for example:

http://192.168.56.70:30035
http://192.168.56.71:30035
http://192.168.56.72:30035
http://192.168.56.73:30035
http://192.168.56.70:31061
http://192.168.56.71:31061
http://192.168.56.72:31061
http://192.168.56.73:31061

Note: even if a Pod for the voting app is scheduled only on nodes with IPs 192.168.56.70 and 192.168.56.71, the NodePort Service is exposed on every node IP in the cluster. All node IPs will accept and forward traffic to the Service. End users typically expect a single URL such as http://example-vote.com or http://example-result.com. There are two main approaches to provide that single address:

Provision an external load balancer yourself (for example, a VM running HAProxy or NGINX) and point DNS to it; it then forwards to node IPs and NodePorts.
Let Kubernetes request a cloud provider–managed load balancer by using type: LoadBalancer on the Service. This is the simpler option when running on a supported cloud platform.

If you run your cluster on a supported cloud provider (for example, Google Cloud, AWS, or Azure), Kubernetes will ask the cloud controller to provision and configure an external load balancer on your behalf. The cloud load balancer receives a single external IP (or hostname) and forwards traffic to your cluster nodes and Services.

A Kubernetes architecture diagram for an example "Voting App" on Google Cloud Platform, showing a load balancer routing traffic to two services (voting-app and result-app) across multiple nodes (IPs 192.168.56.70–73). Each node hosts deployments and pods (voting-app with a Python icon, result-app with a Node.js icon).

On local or unsupported platforms (for example, VirtualBox, bare-metal without a cloud controller, or some local tools), type: LoadBalancer does not automatically provision an external load balancer. In those environments, a LoadBalancer Service typically falls back to behaving like a NodePort Service unless you provide an external load balancer or use a special solution:

Use a dedicated reverse proxy (HAProxy, NGINX) in front of the cluster.
Use MetalLB, which provides LoadBalancer semantics for bare-metal clusters: https://metallb.universe.tf
Use platform-specific solutions or local cluster features (for example, minikube and kind have mechanisms/plugins to simulate LoadBalancer behavior).

If you need a single external IP or hostname and you run on a supported cloud provider, set type: LoadBalancer for the Service and Kubernetes will request the cloud load balancer. For unsupported environments, consider alternatives such as an external reverse proxy, MetalLB, or the platform-specific plugins provided by minikube and kind.

A minimal Service manifest that requests a cloud load balancer looks like this:

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

After applying the manifest, the cloud provisioner will create the external load balancer and the Service will gain an external IP or hostname. You can confirm this with:

kubectl get svc voting-service

Example output:

NAME             TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
voting-service   LoadBalancer   10.0.0.123     34.68.123.45    80:30035/TCP   5m

Users can now reach the application through the external IP (or a DNS name that points to that IP/hostname) instead of a list of node IP:port pairs. Comparison: NodePort vs LoadBalancer

Feature	NodePort	LoadBalancer
External single IP/hostname	No — many nodeIP:port combos	Yes — single external IP/hostname provided by cloud
Requires external proxy to provide single endpoint	Yes	No (when supported by cloud provider)
Works on bare-metal/local clusters without extra components	Yes	Only if you provide a load balancer implementation (MetalLB, external proxy, etc.)
Typical use case	Simple testing, small clusters, or internal tooling	Public-facing services on cloud environments

Summary

Use NodePort when you need a simple way to expose a Service on cluster nodes or when running in unsupported environments.
Use LoadBalancer to get a single external IP/hostname automatically when running on a supported cloud provider.
For bare-metal or local clusters that need LoadBalancer semantics, consider MetalLB or an external reverse proxy.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Services Loadbalancer

Watch Video

Practice Lab