LoadBalancer

NodePort gets traffic into the cluster, but it comes with a noticeable rough edge. The port is 30080, not 80. Users have to type a port number in the URL. You also have to tell them which node IP to use, and node IPs change when nodes are replaced or restarted. For any real production service that end users access directly, that is not acceptable.

In cloud environments, there is a cleaner solution. The LoadBalancer Service type instructs the cloud provider to provision an external load balancer in front of the cluster and assign it a stable public IP. Traffic hitting that IP on port 80 reaches the load balancer, which routes it into the cluster transparently. Users never see node ports or node IPs.

LoadBalancer is a superset of NodePort, which is itself a superset of ClusterIP. Creating a LoadBalancer Service automatically creates a NodePort and a ClusterIP as well. The cloud load balancer routes traffic into the cluster via the NodePort. From there, the Service forwards it to the Pods as usual. Each layer adds a capability without removing the previous one.

Let’s create one:

nano lb-svc.yaml

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

kubectl apply -f lb-svc.yaml
kubectl get service web-lb

In the simulator, the EXTERNAL-IP column will show <pending>. That is expected: there is no cloud provider connected to this emulated cluster, so no load balancer can be provisioned. On a real cloud cluster running on GKE, EKS, or AKS, the external IP typically appears within a minute.

Even without an external IP, the Service is fully functional inside the cluster. Inspect it to confirm:

kubectl describe service web-lb

Note that NodePort and ClusterIP are already assigned in the output. Internal Pods can reach the Service via its ClusterIP. The NodePort is open on all nodes. The only thing missing is the external IP.

Why does the cloud load balancer route through the NodePort rather than going directly to Pods? Because the load balancer lives outside the cluster network and cannot reach Pod IPs. The NodePort is the reachable address on the node’s public network interface. The load balancer hits a node on that port, then kube-proxy forwarding takes over inside the cluster.

Clean up before continuing:

kubectl delete service web-lb

LoadBalancer is the simplest path to a stable external IP on cloud infrastructure, but it comes with a per-Service cost and relies on cloud provider integration. The next lesson introduces named ports, a small but resilient feature that keeps Service configuration correct when container port numbers change.