A purpose-built data plane
XLB makes the backend decision and routes each connection through its optimized kernel fast path.
XLB vs MetalLB
Go beyond Service IP advertisement.
MetalLB brings LoadBalancer Services to bare-metal Kubernetes by allocating and advertising addresses. XLB solves the performance problem after traffic arrives. It discovers Ready Pods, selects the backend, and routes packets in the Linux kernel for services handling millions of requests per second.
Direct Ready Pod discoveryMillions of RPSBuilt-in autoscaling metrics
Why teams choose XLB
A better load-balancing tier at serious scale.
MetalLB and XLB address different parts of Kubernetes networking. MetalLB focuses on address allocation and network announcement. XLB focuses on the backend-selection and packet-forwarding path where performance, latency, and capacity are determined.
Automatic Pod updates
Point XLB to a Kubernetes Service. Ready Pods enter and leave the local backend pool automatically.
Scale the LB tier itself
Exported CPU and network metrics can drive Kubernetes autoscaling across multiple independent XLB instances.
| What matters | MetalLB | XLB |
|---|---|---|
| Primary job | Allocate external Service addresses and announce them through Layer 2 or BGP | Select application backends and route TCP packets at extreme scale |
| Traffic distribution | Traffic reaches a Kubernetes node, then kube-proxy or the cluster network forwards it to Pods | XLB selects a Ready Pod and rewrites packets in its own kernel fast path |
| Layer 2 mode | One node attracts traffic for a Service address at a time | Multiple independent XLB instances can serve and autoscale behind your network entry design |
| BGP mode | Routers spread connections across Kubernetes nodes before the final Pod hop | XLB is the load-balancing data plane and directly maintains the backend pool |
| Backend discovery | Kubernetes-native Service address management | Kubernetes Service selectors and Ready Pod discovery, or static backends |
| Performance target | Provide external reachability for bare-metal Services | Highest possible IPv4 and TCP throughput with lower, consistent latency |
| Autoscaling | Kubernetes deployment model for controller and speakers | CPU and network metrics for horizontal scaling of the XLB tier |
| Monitoring | Prometheus metrics and Kubernetes operational visibility | Built-in console plus premade Grafana and Datadog configurations through OpenTelemetry |
| Product model | Open source Kubernetes project | Supported commercial product with a flat negotiated license |
Different layer, bigger outcome
Own the path from connection to Pod.
Advertising a Service IP gets traffic to the cluster. It does not by itself create a new packet-forwarding data plane. MetalLB’s documentation describes Layer 2 and BGP modes as ways to deliver traffic to a node, where Kubernetes networking makes the final hop. XLB takes direct responsibility for the high-scale backend-selection path.
Direct backend selection
Every XLB instance watches the current Ready Pod pool and makes the backend decision directly in its local fast path.
Kernel-speed packet routing
XDP processes packets before the normal userspace proxy path, keeping load-balancing work short and predictable at peak traffic.
Useful visibility from day one
Inspect traffic, connections, backend distribution, and capacity locally, then use Grafana or Datadog for cluster-wide history and alerts.
Common questions
XLB and MetalLB.
What is the main difference between XLB and MetalLB?
MetalLB primarily allocates and announces external Service addresses for bare-metal Kubernetes clusters. Traffic then reaches a node and Kubernetes networking performs the final distribution to Pods. XLB is a purpose-built Layer 4 data plane that selects a Ready Pod and routes packets itself, with extreme throughput as the primary design goal.
Is XLB a high-performance Kubernetes load balancer?
Yes. XLB watches a Kubernetes Service, discovers Ready Pods, and updates the backend pool automatically. It performs backend selection and packet rewriting in the Linux kernel and supports multiple load-balancer instances that autoscale from CPU and network metrics.
Can XLB run outside Kubernetes?
Yes. The same XLB product can run on Kubernetes nodes, bare-metal Linux servers, or virtual machines. Backends can come from a Kubernetes Service or a simple static configuration.
How is XLB monitored in a Kubernetes cluster?
Each instance has a built-in monitoring console. XLB also exports OpenTelemetry metrics and includes premade Grafana and Datadog configurations for durable, cluster-wide dashboards. CPU and network metrics can feed Kubernetes autoscaling policies.
Official product references
Competitor details on this page are based on the vendor’s own documentation.
Prove it with your workload
See what your load balancer could cost.
Bring your current topology, traffic profile, or cloud bill. We’ll scope a representative XLB evaluation.