MetalLB has become the de facto standard for providing LoadBalancer-type Services in private cloud Kubernetes environments. Its implementation is straightforward and focused, with a gossip-based distributed leader election ensuring quick VIP failover independent of Kubernetes’ state. However, this specialization also means it lacks some critical production-ready features, which led me to explore alternatives like LoxiLB.
Limitations of MetalLB
Despite its name, MetalLB doesn’t handle any data plane forwarding. Strictly speaking, it only provides VIP advertisement capabilities, relying entirely on kube-proxy or its alternatives for forwarding. While this allows MetalLB to focus on various VIP advertisement methods and maintain maximum compatibility with Kubernetes, it also inherits kube-proxy’s functional limitations.
Lack of Active Health Checks
This is a long-standing Kubernetes issue. Service endpoint health depends on Pod ReadinessProbe/LivenessProbe, which require the node’s kubelet to function. During power failures or kernel crashes, kubelet can’t update Pod status until node-not-ready timeout occurs (often minutes in large clusters), causing service access failures during this window.
While not strictly MetalLB’s fault, its inability to actively probe Pod health or modify status leaves it vulnerable to this mechanism. Though Pod ReadinessGates allow external controllers to manage health status, MetalLB offers no out-of-the-box solution, creating production environment risks.
Inadequate Monitoring
Another kube-proxy limitation. Most kube-proxy implementations lack traffic-level monitoring, meaning MetalLB’s metrics contain no traffic data. Deploying an LB with virtually no data plane monitoring in production seems overly optimistic.
LoxiLB’s Improvements
LoxiLB is an eBPF-based LB designed for telecom scenarios, implementing both control and data planes as a complete LB solution. While packed with features (especially for SCTP), we’ll focus on how it addresses MetalLB’s gaps.
Active Health Checks
LoxiLB supports configurable health checks per Service, including ping, TCP, UDP, SCTP, HTTP, HTTPS with timeout/retry settings. While not revolutionary, MetalLB’s complete lack of this functionality makes LoxiLB’s offering notable.
Monitoring Capabilities
Here eBPF shines. LoxiLB includes built-in Metrics and Grafana dashboards, and its self-contained data plane makes adding custom metrics relatively straightforward.
Potential Concerns
While LoxiLB is impressive (its SCTP implementations helped me understand the protocol better), some areas need attention:
- Leader election still uses Kubernetes’ native mechanism, unlike MetalLB’s decoupled approach.
- Documentation, though extensive, is disorganized—many configurations require searching, and some formatting issues exist.
- As a CNCF sandbox project, its community activity remains limited. While clearly mature internally, low adoption could pose future risks.
Conclusion
MetalLB remains excellent at VIP advertisement and high availability, but requires additional components for production readiness. LoxiLB offers a complete LB solution, though its community is still developing and needs broader participation.