Load balancing

Loopback offers managed load balancers with IPv4/IPv6 front ends, algorithms (for example round-robin, least connections), health checks, TLS termination concepts, and access control via allowed and blocked origin CIDR lists on services. The same product object backs load balancers at different scopes; the API surface you call depends on whether the LB is attached to a project, a workspace, or (in multi-cluster operator setups) a management cluster context.

Scopes

Project-level
Project load balancer APIs (nested targets, services). Share an edge across multiple workspaces in the same project when your architecture calls for it.

Workspace-level
Workspace load balancer APIs under the owning project. Use when the VIP and backends are owned by one environment.

Cluster-level (operator)
Additional surfaces exist for load balancers tied to Kubernetes management clusters. Most tenant documentation focuses on project and workspace scopes; cluster scope is a platform concern unless your operator exposes it to you.

Object structure (conceptual)

• Load balancer - front IP, algorithm, state, organization and optional project/workspace references.
• Target - backend host or endpoint membership, weights, health configuration.
• Service - listener definition (ports, protocols), linkage to targets, optional LBFW-related hooks where the deployment supports them, and origin allow/block CIDR lists (validated CIDR notation).

Security and edge policy

Allowed and blocked origin lists are not a full WAF by themselves; they are IP-layer filters at the LB edge. Pair with Firewalls on hosts for defense in depth.

Reconciliation

Load balancers appear as reconcilable entities in the scheduler (backend sync, certificate refresh triggers). Expect eventual convergence after API changes.

Related reading

• Project resources
• Workspace load balancers
• Networking overview
• Monitoring and alerts
• Technical verification