Open the cluster → Load Balancers tab in my.cubepath.com.
Lists every load balancer targeting this cluster's worker nodes, with its status, plan, IP, listeners and target count. You can deploy a new one straight from here.
Where it fits
A load balancer is the outer half of getting internet traffic into the cluster. The full path is:
Internet → Load Balancer → worker nodes → ingress controller → your Service → pods
The load balancer gives you one stable public IP in front of a set of workers that come and go. That's the point: with autoscaling on, individual nodes are disposable, so you can't put DNS on a worker's address. You point DNS at the load balancer instead.
The ingress controller inside the cluster then does the host- and path-based routing to the right Service.
Deploy one
Click through to deploy a load balancer targeting this cluster. Configure its listeners for the ports your ingress controller exposes — typically 80 and 443.
NoteThe load balancer targets worker nodes, not pods. If a node has no ingress controller pod on it, the traffic still lands there and gets forwarded internally. That's normal Kubernetes behaviour, not a misconfiguration.
When you don't need one
- Internal-only clusters. If the cluster serves other services on a private network and nothing from the internet, skip it entirely.
- A single non-production node. For a dev cluster, a NodePort on a worker's public IP is cheaper. Don't build DNS or anything permanent on it.
TipIf traffic reaches the load balancer but returns errors, check the target count here first. A load balancer with zero healthy targets is the most common cause, and it usually means the ingress controller isn't running rather than anything wrong with the balancer.