Kubernetes LoadBalancer: Your App's Public Entry Point
A Kubernetes LoadBalancer Service automatically provisions a cloud provider's load balancer to expose your app externally. It's the simplest way to get a public IP, but creating one per service is expensive and inflexible. Use an Ingress for more control.
WHY IT EXISTS Pods are ephemeral and have internal-only IP addresses. While other Service types like ClusterIP and NodePort provide stable access, they are either internal-only or clumsy for public traffic. The LoadBalancer Service type was created to automate provisioning a stable, public-facing entry point for your application using native cloud provider infrastructure.
THE MENTAL MODEL A LoadBalancer Service is like a work order you give to your cloud provider via Kubernetes. You declare "I need a public entrance for this app," and Kubernetes tells AWS, GCP, or Azure to build one of their own load balancers, assign it a public IP, and connect it to your cluster nodes.
HOW IT WORKS You define a Service manifest with type: LoadBalancer. The Kubernetes cloud-controller-manager, which is specific to your cloud environment, detects this request. It then makes API calls to the underlying cloud platform (e.g., AWS, GCP, Azure) to provision a network load balancer. This new load balancer gets a stable, public IP address and is automatically configured to forward traffic to a high-numbered port (the NodePort) on every node in your cluster. From there, kube-proxy routes the traffic to the correct pods backing the service.
WHEN TO USE IT Use it for simple, direct exposure of a single service to the public internet. It's excellent for getting a stateful application like a database a stable external endpoint, or for quick development and testing where you need a public IP without complex configuration.
WHEN NOT TO USE IT Avoid using it when cost is a concern. Each LoadBalancer Service typically provisions a new, dedicated, and billable cloud load balancer, which gets expensive quickly. Also, avoid it for applications requiring path-based routing (e.g., /api vs /app), SSL termination, or virtual hosting. An Ingress is the proper tool for these use cases, as it can manage traffic for many services behind a single load balancer.
ONE CANONICAL EXAMPLE A team deploys a web server using a Kubernetes Deployment. To make it accessible from the internet, they create a Service YAML file. In the spec section, they set type: LoadBalancer and include a selector that matches the labels on their web server pods. After applying the manifest, kubectl get svc will first show the service with a <pending> external IP. After a minute, the cloud provider finishes provisioning, and the command will show a public IP address in the EXTERNAL-IP column.
Read the original → kubernetes.io
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.