Skip to content
longbridge docs

Load balancers

Give a Kubernetes Service its own public IP — the platform allocates a dedicated IPv4 and routes it to your nodes over the encrypted fabric, with no cloud credentials in your cluster.

A managed load balancer turns a standard Service of type: LoadBalancer into a dedicated public IPv4 address, routed to your nodes over the encrypted fabric. You write the Kubernetes you’d write anywhere — a kubectl apply, a Helm chart, an operator — and an external address appears on the Service. There’s no cloud-controller-manager to install and no cloud credentials in your cluster.

Early access. Public ingress is rolling out. During this phase the range of public ports you can expose is limited (and growing) — if a Service has an external IP but won’t answer on a port like 443, that’s the likely cause. IPv4 only for now; IPv6 and dual-stack are planned.

Turn it on

Managed load balancers are off by default — a stray type: LoadBalancer does nothing until you opt in. That’s deliberate: it keeps you from exposing a workload to the internet by accident, and from a surprise on the bill.

Enable it per cluster in the Console:

  1. Open the cluster, find the Load balancers card, and choose Enable.
  2. Confirm the cost. This is the Public ingress add-on — a paid feature (see Sizes & pricing).

That’s the whole switch. Turning it back off releases every public IP the cluster holds and costs nothing — your workloads keep running, they just lose their external address.

Expose a service

With the add-on on, create a Service of type: LoadBalancer the usual way:

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - port: 15000        # the public port
      targetPort: 8080   # your container's port
kubectl apply -f web-service.yaml
kubectl get svc web
# NAME   TYPE           EXTERNAL-IP    PORT(S)
# web    LoadBalancer   65.109.x.x     15000:31872/TCP

Within a few seconds the Service gets an EXTERNAL-IP — a dedicated public IPv4 that’s yours for as long as the Service exists. Point an A record at it and you’re live. Delete the Service and the IP is released.

How it works

Each type: LoadBalancer Service gets its own public IPv4 — not a shared, port-multiplexed address — so you get a clean IP:port endpoint per service. Traffic arrives at that IP and is forwarded to your nodes over the same encrypted fabric they already use to reach the control plane, at layer 4 and never decrypted in transit.

The part worth knowing: nothing in your cluster holds cloud credentials. Your cluster only declares intent — a Service object. The platform watches for it and does the allocation, the routing, and the metering on its side. A stolen kubeconfig can create a Service; it can’t reach into a cloud account.

What it costs

Public ingress is a paid add-on: a flat monthly price with an included traffic allowance, metered only beyond it — Sizes & pricing has the current numbers. Your live load balancers and their usage appear in the Console under Usage. Disabling the add-on is a clean €0 — no IPs, no charge.

Limits & considerations

  • One dedicated IPv4 per Service. A misconfigured chart that spun up a dozen type: LoadBalancer Services would otherwise allocate a dozen paid IPs, so each cluster has a limit on how many it can hold (shown in the Console). Past the limit, new Services stay <pending> with an event explaining why. To raise it, contact support.
  • IPv4 today. IPv6 and dual-stack are planned; for now every load balancer is IPv4.
  • Ports (early access). Public ports are currently limited to the 10000–20000 range — the full range, including 80 and 443, is rolling out. Pick a port in that range for now (the example above uses 15000).
  • You bring the backend. A load balancer routes to a node running your Service’s pods. With no node joined, or no pod behind the selector, the IP is allocated but nothing answers — join a node first.

Troubleshooting

  • Service stuck on <pending>. Either the add-on isn’t enabled for this cluster (turn it on in the Console), or you’re at the per-cluster limit (the Console shows used / max).
  • It has an EXTERNAL-IP but won’t connect. Check the public port is in the supported range (early access), that DNS points at the right IP, and that a pod actually matches the Service selector on a running node.

Where to next

  • Sizes & pricing — what the add-on costs and what’s included.
  • Join a node — a load balancer needs a node behind it to reach.