What does XLB require me to configure?

Configure the listen address, port mappings, and either a static backend list or a Kubernetes namespace and Service. OpenTelemetry export and shutdown timing are optional.

Does XLB update Kubernetes backends automatically?

Yes. XLB follows the Service selector, adds Ready Pods, and stops assigning new connections to Pods that become unready or start terminating. The backend pool stays current as the application scales and rolls.

Does XLB need a separate control plane or virtual IP system?

No. Each XLB process uses the host’s existing address and gets backends from a file or Kubernetes. There is no separate cluster for virtual IPs, BGP advertisements, failover state, or load-balancer configuration.

Operations / deploy and forget

Deploy once. Stop tuning the load balancer.

One process, a small configuration, and no separate control plane. Point XLB at a backend list or Kubernetes Service and it keeps routing as your application scales, rolls, and changes.

Completely tuning freeAutomatic backendsNo control plane

The complete setup

Tell XLB where to listen and where the backends live.

XLB is completely tuning free. There are no worker counts, buffer sizes, socket settings, connection pools, or thread models to adjust as traffic grows. The backend source is either a short IP list or a Kubernetes Service.

Read the configuration reference

xlb.yamlkubernetes

listen: auto
ports:
  - local_port: 443
    remote_port: 8443

provider:
  kubernetes:
    namespace: production
    service: api

ActiveBackends follow the Service automatically

Day-two operations

Remove load-balancer work from the backlog.

HAProxy and NGINX can perform well, but extreme scale turns the proxy tier into a system your team must continuously size, tune, automate, and support. XLB has a much smaller operating surface.

TUNING / 01

Completely tuning free

No worker, thread, buffer, socket, or connection-profile tuning before deployment or as traffic increases.

CONTROL / 02

No separate control plane

No extra cluster for virtual IPs, BGP advertisements, failover state, or load-balancer configuration.

BACKENDS / 03

No backend list maintenance

In Kubernetes, XLB follows Service selection, Pod readiness, termination, scaling, and rolling updates.

SCALE / 04

No shared state to rework

Run and autoscale multiple XLB instances across nodes for capacity and redundancy.

Kubernetes lifecycle

Your application changes. XLB follows it.

The Kubernetes provider continuously reconciles the Pods selected by your Service. There is no generated proxy configuration to distribute and no reload cycle to manage.

01
Service selects PodsUse the routing definition your application already has.
02
XLB follows readinessOnly ready, non-terminating Pods receive new connections.
03
The pool updates locallyScale and roll the application without editing XLB configuration.

Operations questions

What deploy and forget means in practice.

What do I actually configure?

A listen address, one to eight port mappings, and either a static backend list or Kubernetes namespace and Service. OpenTelemetry export and shutdown timing are optional.

Do Kubernetes backend changes require a reload?

No. XLB keeps the local backend set current as Pod readiness, termination, and Service selection change. There is no proxy configuration generation or reload step.

Does XLB require tuning as traffic grows?

No. XLB is completely tuning free. There are no worker counts, thread models, buffer sizes, socket profiles, or connection pools to retune as traffic increases.

Can we still observe and alert on XLB?

Yes. XLB exports metrics through OpenTelemetry over gRPC or HTTP/protobuf so the load-balancing tier can use your existing collection, dashboard, and alerting systems.

Simplify the tier

Deploy the load balancer once.

We’ll map XLB to your Kubernetes Service or bare-metal backends and validate it against your peak traffic.

Plan an evaluation