Load balancers

A load balancer spreads traffic over VMs in one VPC and stops sending to a VM that fails its health checks. A public load balancer gets a public IPv4 address; an internal one only has an address inside its VPC.

• Listeners are ports on the load balancer. tcp passes bytes through, so TLS (HTTPS) ends on your VMs. http reads requests and adds an X-Forwarded-For header with the client’s address.
• Target groups are VMs with a port, an algorithm (round_robin, least_connections or source_ip, which keeps each client on the same VM) and a health check (TCP or HTTP: path, expected status codes, interval and thresholds).
• Targets are VMs of the same project and the same VPC as the load balancer. A load balancer never reaches any other network.

Each load balancer runs on two nodes inside your VPC. If one fails, the other keeps serving.

Its own address inside the VPC comes from 100.68.0.0/16, outside your subnets, so it never takes one of your addresses. VMs in the VPC reach it through their default gateway, with no setting on your side.

Before you start

• A public load balancer is reached through its VPC’s NAT gateway, as a VM’s public IP is. Create one first.
• The VMs’ security groups must let the load balancer in on the target port (and the health check port). By default the load balancer joins the VPC’s default security group, whose members reach each other: VMs in that group need nothing more. With your own groups, add a rule from one of the load balancer’s groups.
• Your VMs must listen on their IPv4 address.

Create one

Console

Network → Load balancers → Create. Pick public or internal, the subnet, a listener (protocol and port), the VMs and their port, and the health check. The form shows the monthly cost before you create it.

CLI

tebib lb create web --listen http:80 --target-port 8080 \
  --target vm-aaaaaaaaaaaa --target vm-bbbbbbbbbbbb \
  --health-path /healthz --wait
tebib lb show <LB ID>            # the public address, listeners, health summary
tebib lb targets <LB ID>         # every target and its health

--internal makes an internal load balancer. --public-ip <IP ID> uses an address you already allocated instead of a new one. For several target groups or protocols at once, pass the whole request with --from-file lb.json.

Health

Each target shows one of:

Health	Meaning
healthy	Every load balancer node sees it pass its checks. It gets traffic.
unhealthy	It fails its checks (the reason says how: no answer, refused, wrong HTTP status). No traffic.
initial	Not checked yet.
unavailable	The VM has no IPv4 address yet, or is being deleted.
unused	No listener forwards to its target group.

A new target gets traffic at once and leaves at its first failed check. After that it needs the healthy threshold (3 checks by default) of passes to come back.

Change it

tebib lb target add <LB ID> <GROUP ID> <VM ID> [--port 9000]
tebib lb target remove <LB ID> <GROUP ID> <TARGET ID>
tebib lb target-group update <LB ID> <GROUP ID> --algorithm least_connections --health-interval 30
tebib lb listener add <LB ID> --protocol tcp --port 443 --target-group <GROUP ID>
tebib lb set-security-groups <LB ID> --security-group <SG ID>

Changes reach the nodes one at a time, so the load balancer keeps serving while they do. Deleting a VM takes it out of every target group.

Delete

tebib lb delete <LB ID> --yes --wait

A public address the load balancer allocated is released with it. One you gave at create time stays in your project, unattached.

Billing and limits

A load balancer is billed by the hour while it exists, public or internal. A public one also bills its public IPv4 address, and its internet traffic out counts as egress, as for VMs. Processed traffic is not billed. See Quotas and tiers: a project holds 2 load balancers unless raised; an organization 1, 3 or 5 by trust tier. Each load balancer takes up to 10 listeners, 10 target groups and 50 targets.