PureLB

PureLB is a Kubernetes LoadBalancer implementation for bare-metal Linux clusters, aimed at operators who need externally reachable services without a cloud load-balancer controller. It suits teams comfortable managing Kubernetes networking and, when needed, BGP; its open-source model is attractive, but the Linux, CNI and operational requirements rule out simpler hosted approaches.

Overview

PureLB allocates IP addresses from configured pools and announces them for Kubernetes LoadBalancer services. You define pools and node-agent settings with Kubernetes Custom Resource Definitions, then install with kubectl manifests or Helm; Helm is the project’s recommended production route. It is a Layer 4 solution for self-hosted, bare-metal environments rather than a managed service.

Its address model gives operators a meaningful choice. Local addresses are attached to host interfaces, and a Kubernetes Lease election selects one node to announce each address. If that node fails, another can take over. Remote addresses are placed on a dummy interface on every node and advertised with BGP, allowing an upstream router to spread traffic across nodes with ECMP. That makes the remote mode a better fit for routed data centers, while local mode is the more contained option when a shared Layer 2 network is sufficient.

Key features

• Flexible pools: Local, remote and Netbox pools are supported, with each ServiceGroup using exactly one pool type. The separation keeps behavior explicit, but requires planning when services need different announcement methods.
• Dual-stack support: ServiceGroups can contain IPv4 and IPv6 pools, including dual-stack deployments.
• BGP included: The default installation includes a k8gobgp sidecar for remote-address announcements. You can disable BGP during installation if it is not part of your network design.
• Operational visibility: The Allocator and LBNodeAgent publish Prometheus metrics on port 7472 at /metrics. The optional kubectl-purelb plugin reports pool utilization, service status, election state, BGP sessions, data-plane health and configuration validation.
• NetBox caveat: PureLB can request addresses from NetBox, but the integration is described as unsupported, untested with recent NetBox versions and potentially unreliable. Treat it as an experiment, not a production dependency.
• Security split: The Allocator runs non-root with a read-only filesystem and no capabilities. LBNodeAgent must run as root with NET_ADMIN and NET_RAW on the host network, a necessary privilege boundary for its Linux networking work.

Pricing

PureLB is free and open source under the Apache License 2.0. There are no paid tiers, seat charges or subscription renewals. The trade-off is operational responsibility: you provide the Kubernetes cluster, Linux nodes, networking and support process. Help is offered through the Kubernetes Slack #purelb-users channel and GitHub Issues.

Platforms

PureLB runs on Linux and is designed for self-hosted Kubernetes. The cluster must have an operational CNI, and the nodes must be Linux because PureLB uses the Linux netlink API. macOS appears as a supported platform in the directory, but the product’s stated runtime requirements center on Linux Kubernetes nodes, so macOS is not a substitute for that deployment environment.

Who it's for

Choose PureLB when you operate bare-metal Kubernetes and need LoadBalancer services backed by address pools you control. It is particularly suitable for teams with routed infrastructure that can consume BGP and ECMP, or for smaller installations that prefer lease-based local announcements. Dual-stack operators also get a native fit.

Look elsewhere if you want a managed endpoint, cloud-native provisioning, or a controller that avoids host-level networking privileges. NetBox-dependent designs should wait until that integration is dependable in their environment.

Pros and cons

Pros

• Free Apache-licensed software removes licensing and per-service costs.
• Local and BGP-based remote announcements cover both simpler Layer 2 setups and routed data centers.
• IPv4, IPv6 and dual-stack pools support mixed network estates.
• Prometheus metrics and the kubectl-purelb plugin expose practical capacity and health signals.

Cons

• Linux nodes and a functioning CNI are mandatory, limiting portability.
• LBNodeAgent requires root, NET_ADMIN, NET_RAW and host networking.
• Each ServiceGroup accepts only one pool type, so mixed announcement strategies need separate groups.
• NetBox integration is unsupported and may fail with recent releases.

Alternatives

MetalLB is the closest Kubernetes-focused alternative when you want an open-source load-balancing project without relying on PureLB’s NetBox integration. HAProxy Community Edition fits Linux operators who need a free TCP and HTTP proxy rather than Kubernetes address allocation. Linux Virtual Server is a GPL-licensed Linux option for conventional virtual-server routing.

Pick AWS Elastic Load Balancing when a web or API-managed AWS service is preferable to operating bare-metal networking; its free tier includes 750 shared Classic/Application Load Balancer hours and 15 GB of processing for new AWS customers. VMware Workstation Pro is a free choice for running virtual machines on Windows or Linux hosts, not a direct Kubernetes LoadBalancer replacement. Array APV is a paid alternative across API, Linux, self-hosted and web environments. F5 BIG-IP APM is a paid platform with a free trial and broad platform coverage when enterprise access-management infrastructure is the priority. kube-vip is another free, Linux self-hosted Kubernetes option.

For more choices, browse the Load Balancing Software list.

Verdict

PureLB is a strong fit for Kubernetes operators who want free, self-hosted Layer 4 service exposure with explicit local or BGP-based control, especially in bare-metal Linux and dual-stack networks. Choose it for that network-level flexibility and its useful monitoring hooks. Look elsewhere if you need managed provisioning, non-Linux nodes, minimal host privileges or reliable NetBox automation.