Cloud Native 7 min read

Why OpenELB Is the Next‑Generation Load Balancer for Bare‑Metal Kubernetes

OpenELB, the CNCF‑sandboxed load‑balancer plugin from KubeSphere, offers BGP and Layer‑2 based traffic distribution, CRD‑driven IP pool management, and seamless integration with Kubernetes, K3s and edge environments, positioning itself as a lightweight, community‑driven alternative to MetalLB for on‑premise deployments.

Qingyun Technology Community
Qingyun Technology Community
Qingyun Technology Community
Why OpenELB Is the Next‑Generation Load Balancer for Bare‑Metal Kubernetes

OpenELB, an open‑source load‑balancer plugin originally named PorterLB, entered the CNCF Sandbox on November 10, 2023.

Key capabilities include:

Load balancing based on BGP and Layer 2 modes

Router ECMP‑based load balancing

IP address pool management

CRD‑driven BGP configuration

A survey of more than 5,000 KubeSphere users revealed that roughly 36% deploy Kubernetes on bare‑metal servers, and many run clusters in offline data‑centers or edge locations, making external LoadBalancer services difficult to expose.

OpenELB addresses this gap by providing an easy‑to‑use EIP and IP‑pool management solution for private environments, enabling “LoadBalancer”‑type services without relying on public‑cloud LB plugins.

Adoption is already strong: companies such as Benlai Life, Suzhou TV, Vision Components, Yunzhi Tianxia, Jollychic, QingCloud, Baiwang, and Rocketbyte have deployed OpenELB in production, with early versions used by Benlai Life since late 2019.

Compared with MetalLB, which also joined the CNCF Sandbox, OpenELB follows a more Kubernetes‑native approach, using CRDs for configuration instead of ConfigMaps, and leverages the standard gobgp library for BGP routing.

Cloud‑Native Architecture

Both address management and BGP configuration are expressed as CRDs, making the plugin friendly to users familiar with kubectl and allowing advanced users to extend functionality via the Kubernetes API.

Flexible Address Management

OpenELB introduces an EIP CRD that stores allocation status in a sub‑resource Status, preventing conflicts between replicas and simplifying programming logic.

Using gobgp to Publish Routes

Low development cost with active gobgp community support

Access to rich gobgp features

Dynamic configuration via BgpConf/BgpPeer CRDs

Compatibility with gobgp protobuf API for future extensions

OpenELB also provides status objects for detailed BGP neighbor information.

Simple Architecture and Low Resource Footprint

The solution runs as a standard Deployment; high availability is achieved by multiple replicas. In BGP mode each replica establishes a session with the router, while in Layer 2 mode replicas elect a leader via Kubernetes leader‑election to answer ARP/NDP.

Installation and Usage

OpenELB can be installed on any standard Kubernetes, K3s, or their derivatives using a single YAML manifest or Helm chart. It is also available in the KubeSphere App Store for one‑click deployment. Documentation: https://openelb.github.io/docs/getting-started/installation/

Future Roadmap

VIP‑mode high availability based on Keepalived

LoadBalancer for kube‑apiserver

Enhanced BGP policies and configuration

VIP Group support

IPv6 support

Standalone UI for EIP and IP‑Pool management

Integration with KubeSphere Console and Prometheus metrics

With CNCF’s neutral backing, OpenELB aims to become a 100% community‑driven project, inviting users to contribute requirements and feedback.

Edge computingKubernetesBGPLoad BalancerOpenELB
Qingyun Technology Community
Written by

Qingyun Technology Community

Official account of the Qingyun Technology Community, focusing on tech innovation, supporting developers, and sharing knowledge. Born to Learn and Share!

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.