In our announcement post we introduced the Isovalent Load Balancer as a software-first alternative to legacy appliance-based load balancing. Built on the foundations of eBPF and Cilium, Isovalent delivers L3 to L7 traffic management with high performance, deep observability, and the flexibility to run anywhere, inside Kubernetes, on bare metal, or in virtual machines. This post takes you inside Isovalent’s Load Balancer architecture, walks through the data path in detail, and shows how you can deploy and operate the load balancer using Kubernetes-native workflows. By the end, you will see exactly how the load balancer handles a request from client to backend, and why it delivers the speed, control, and visibility that traditional load balancers cannot. Why Modern Platforms Need a New Load Balancer Model Most legacy load balancers are either physical appliances or virtual editions of those appliances. They tend to sit outside your platform, and scaling them means adding more units or replacing them with a bigger model. Configuration often lives in proprietary interfaces that don’t integrate well with automation, and deep observability requires extra tools bolted on. Isovalent Load Balancer flips that model. It runs on the same infrastructure as your workloads, in Kubernetes, on VMs, or even bare metal, and manages everything using Kubernetes-style APIs. If you need more capacity, you add more Tier 1 or Tier 2 nodes (discussed further in the next section). If you need new routes or TLS policies, you apply a CRD. And because it’s built on Cilium and eBPF, by the creators of those technologies, you get high-speed packet handling without the complexity of traditional networking stacks. Isovalent’s software load balancer architecture The load balancer uses a two-tier architecture that separates high-performance packet processing from application-aware traffic management. Tier 1 (T1): Speed and Scale at L3/L4 Tier 1 is where the load balancer’s raw throughput lives. Packets hit a T1 node and thanks to XDP, don’t even need to be processed in the kernel! That means there’s no detour through the Linux networking stack, no iptables rules to parse, and no kube-proxy. Maglev hashing picks the Tier 2 node consistently, even when you’re adding or removing capacity. T1 nodes advertise your service VIPs using BGP, so they’re reachable from anywhere in your network. For rapid failover, you can pair BGP with BFD to detect link or node failures in milliseconds. Tier 2 (T2): Application Awareness at L7 Tier 2 is where the load balancer gets smart about traffic. These nodes run a hardened Envoy integrated with Cilium with additional enhancements and extended features, to make routing decisions based on hostnames, paths, HTTP methods or other L7 metadata. This is also where TLS termination happens, so your application servers don’t have to spend cycles on encryption. You can send /api requests to one backend pool and /media requests to another, or enforce application-layer policies before requests reach your workloads. Because T1 and T2 scale independently, you can grow your L7 inspection capacity without affecting raw L3/L4 throughput. Scale the functions you need, independently Because the tiers scale independently, you can add more T1 nodes for raw throughput without increasing your L7 processing footprint, or scale out T2 for more TLS and routing capacity without overprovisioning L3/L4 nodes. And with Direct Server Return (DSR), return traffic skips the load balancer entirely and goes straight back to the client, reducing round trip latency. Everything is controlled using Kubernetes CRDs; VIPs, backend pools, services, and IP pools. The Isovalent Load Balancer controllers reconcile those resources into eBPF maps for T1 and Envoy configs for T2. We’ll dive more into configuring and managing the load balancer with examples later in this walkthrough blog post. Deployment options for Isovalent Load Balancer The Isovalent Load Balancer is designed to work in a wide range of environments. Whether you run workloads entirely inside Kubernetes, in a fleet of virtual machines/bare metal machines, or across both, the load balancer can be deployed in a way that fits your operational model. There are two main approaches: standalone mode and in-cluster mode. Standalone Mode In standalone mode, the load balancer runs as a set of virtual appliances or is deployed to bare metal machines, independent from any Kubernetes control plane. This is a good fit when your team manages its own VM infrastructure, such as VMware vSphere or a public cloud IaaS platform. The Isovalent Load Balancer operator connects directly to the VM management API to create and remove virtual machines, as well as configure network attachments. Each load balancer “instance” is made up of one or more dataplane VMs and is managed end-to-end by the load balancer control plane. Instances are fully independent; any load balancer instance can send traffic to any reachable destination. This gives you flexibility in how you place and scale them, without coupling to a particular cluster. In-Cluster Mode In-cluster mode assumes you already have a Kubernetes cluster running Isovalent Networking for Kubernetes (Enterprise-grade Cilium as the CNI). In this setup, Isovalent Load Balancer runs as a single instance per cluster, and you control where dataplane functions live by creating deployments within the cluster. This approach lets you map load balancer based roles directly to Kubernetes nodes. For example, you might dedicate certain nodes to Tier 1 L3/L4 load balancing, and others to Tier 2 L7 proxying. VIPs are associated with specific deployments, giving you the ability to separate tenants or workloads cleanly inside the same cluster. Backend workload selection can be workloads inside the Kubernetes cluster itself, or alternatively workloads outside of the cluster such as Bare Metal and Virtual Machines, or cloud instances running in your preferred private or public cloud provider. Walking the Data Path: How a Packet Moves Through Isovalent Load Balancer When client traffic heads for a service, the Isovalent Load Balancer first makes sure it reaches the right entry point. This is done by advertising the service’s VIP through BGP or by using gratuitous ARP. If you use BGP, then, additionally BFD can be enabled to speed up convergence in failover scenarios. The first hop in the data path is a Tier 1 (T1) node. This is where the load balancer’s high-speed, stateless layer 4 load balancing happens. Using eBPF and XDP, packets are processed right at the NIC without ever hitting the CPU of the T1 node. The T1 node applies consistent hashing to choose one of the healthy Tier 2 nodes, encapsulates the original client packet inside an IP-in-IP (IPIP) header, and sends it along. Because the original client IP is preserved in the inner header, Isovalent Load Balancer can use Direct Server Return (DSR) so that responses go straight back to the client without retracing their steps through the T1 Nodes. On the Tier 2 (T2) side, the node removes the IPIP header and passes the packet to a local L4/L7 proxy. This proxy applies your configured load-balancing algorithm to pick one of the healthy backends, then forwards the request over a dedicated L4 session. That dedicated path ensures the backend’s response arrives back at the same T2 node, which then reverse-proxies it and sends it directly to the client, again using DSR to avoid unnecessary hops. Health checks run at two levels. T1 and T2 continuously verify each other’s availability, while T2 independently checks the health of each backend. T2 aggregates these results and shares them with T1 so that only healthy targets are ever selected. How do I configure and manage the Isovalent Load Balancer? Before you start creating VIPs and services, it helps to understand the Isovalent Load Balancer data model. This model defines how different Kubernetes Custom Resources (CRDs) fit together to describe your load balancer’s topology and behavior. At the core, there are a few CRDs you will work with most often: LBVIP: Defines the virtual IP and port clients connect to. LBService: Describes how a virtual IP (VIP) maps to one or more backends. It includes details like the service port, protocol, and routing rules. LBDeployment: Defines where and how the load balancers dataplane components are deployed. This can be linked to specific nodes, tiers (T1 or T2), or environments. BGP CRDs: Configure how VIPs are announced to your network. In addition, BGP CRDs define how the load balancer announces VIPs to the physical network, ensuring clients can reach services from outside the cluster. The LBService objects link to backends through LBBackendPool definitions, which list endpoints and health checks. Think of it in two parts. Configuring how traffic is handled: LBService: The service definition clients connect to, describing ports, protocols, and routing rules. LBBackendPool: The set of application servers or endpoints that serve requests, along with their health check settings. Together, these define the L4/L7 load balancing behavior, much like you would configure in other traditional or public cloud platform load balancers (ELB, etc).] Configuring the infrastructure: LBDeployment: Specifies where Isovalent Load balancer dataplane components run, and in which tier (T1 or T2). BGP CRDs: Control how VIPs are advertised into your network so clients can reach them from outside the cluster. These determine the physical and logical placement of the load balancer and how it connects to the wider network. Here’s a minimal example showing how these resources work together: In this example: The LBVIP resource defines the virtual IP and port clients will connect to. The LBService ties them together, specifying the load balancing algorithm and linking the VIP to the backend pool. The LBBackendPool lists the actual application servers and how load balancers will check their health. The IsovalentBGPAdvertisement configuration ensures that the LBVIP IP Address is advertised to the datacenter using BGP. This Kubernetes-native model means you can manage the Isovalent Load Balancer entirely through GitOps, storing all configuration in version control and applying changes using kubectl or CI/CD pipelines. Once your LBService and LBBackendPool are deployed, you can verify their status directly with the Cilium CLI. This lets you confirm BGP advertisements, backend health, and VIP assignments without digging through multiple logs. Want to see the Isovalent Load Balancer configuration hands-on? This video by Dean takes you step by step through multiple use-case examples. Built for Every Manifestation of Platform Engineering The Isovalent Load Balancer is purpose-built for teams running Kubernetes platforms, hybrid environments, and developer self-service workflows. It supports: GitOps-based delivery using CRDs and YAML Native integration with Kubernetes Gateway API and Ingress Identity-aware access control and L7 policy enforcement Flexible deployment models across VMs, containers, and cloud environments Isovalent Load Balancer is not just another networking component. It is a foundational part of your service connectivity strategy. It delivers: End-to-end performance from L3 through L7, powered by eBPF and Envoy Declarative, cloud-native configuration that fits seamlessly into your workflows Built-in observability to monitor every connection and decision Elastic scalability to handle growth without re-architecting What This Means for Your Platform Adopting the Isovalent Load Balancer translates directly into measurable outcomes: Operational consistency: one load balancing solution for containers, VMs, and hybrid services Reduced complexity: replace multiple appliances and proxies with a single control plane Improved developer experience: self-service service publishing with clear policies and predictable behavior Faster troubleshooting: real-time flow visibility and health status for every VIP and backend Future-ready architecture: scale horizontally, integrate with automation, and avoid hardware lock-in Try the Isovalent Load Balancer Today We’ve created a hands-on lab that walks you through installing, configuring, and operating the Isovalent Load Balancer. No local setup required; just launch the lab in your browser and explore the Isovalent Load Balancer in action.