kube-vip: A Floating VIP and Load Balancer for Kubernetes Control Planes and Services

The gap kube-vip fills on bare metal and edge clusters

A Kubernetes API server needs a stable address. On a cloud provider that address is a managed load balancer in front of the control plane nodes. On bare metal, in a virtualised environment, or on a Raspberry Pi cluster, there is no such thing, so the address has to come from somewhere else. The README describes kube-vip as a small self-contained Highly-Available option for all environments, listing bare metal, edge (arm / Raspberry PI) and virtualisation as the targets. The same component also implements Service type LoadBalancer, which is otherwise left unimplemented when no cloud provider is present. So the project covers two jobs that usually need separate tooling: a floating VIP for the API server and address allocation plus load balancing for Services. The README is explicit that replicating this with other tools would take at least two pieces of software, a VIP tool such as Keepalived or UCARP plus a load balancer such as HAProxy or Nginx, each with its own configuration and, in some organisations, its own team. kube-vip is written in Go, which the README gives as the reason it is small and easy to build for multiple architectures, including ARM, where packaged alternatives may not exist.

How the VIP moves: leader election, raft, ARP and BGP

The mechanism is a virtual IP that one node advertises at a time. The README lists two ways to decide which node holds it: Kubernetes leader election via client-go, or raft. The choice matters. Leader election leans on the Kubernetes API and the coordination it already provides; raft is a consensus protocol that does not depend on the API server being reachable, which is relevant when the VIP is what makes the API server reachable in the first place. The README does not explain when to prefer one over the other, and that is a real gap for anyone designing a control plane. Advertisement is a second axis. ARP is Layer 2: the elected node answers ARP for the VIP, so traffic reaches it on the local segment. BGP is Layer 3: the node announces the address to routers, which lets the VIP exist across subnets. The README lists both for the control plane and notes that Service load balancing uses leader election for ARP and multiple nodes with BGP. That asymmetry is worth noticing. With BGP, several nodes can carry Service traffic at once; with ARP, one node holds the address. The go.mod confirms the implementation surface: gobgp for BGP, netlink and nftables for the data path, ipvs from cloudflare, go-conntrack, and dhcp for address acquisition. Service addresses can come from pools per namespace or globally, from existing DHCP, or be exposed to a gateway via UPnP. The README also claims an egress feature, where a service load balancer acts as both ingress and egress for a pod. That is a notable claim and the README gives no configuration example for it, so treat it as something to read up on at kube-vip.io before relying on it.

Installing kube-vip and getting a first Service address

The README does not carry install steps; it states that all documentation of usage and architecture lives at https://kube-vip.io, and points at the upgrade guide for in-place upgrades of a static Pod or DaemonSet. The repository does show how to build the binary and the container image. The Makefile sets VERSION to v1.2.4 and builds with static linker flags, and the Dockerfile builds in a golang stage and copies the binary into a scratch image with only CA certificates alongside it, which matches the README's point about the container holding nothing else. To build the binary yourself, the Makefile's build target is the entry point:

make build

The result is a kube-vip executable in the repository root. The Makefile's demo target builds and pushes a multi-architecture image across the platform list linux/amd64, linux/arm64, linux/arm/v7, linux/ppc64le and linux/s390x:

docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7,linux/ppc64le,linux/s390x --push -t $(REPOSITORY)/$(TARGET):$(DOCKERTAG) .

For a development cluster the README gives a kind workflow: create a kind cluster from testing/kind.yaml, apply the RBAC manifest from https://kube-vip.io/manifests/rbac.yaml, create a load balancer range ConfigMap, apply the CCM manifest, then run skaffold dev from the repository root. The README notes a real constraint here: the project has an issue compiling on macOS, and asks that it be compiled on a Linux distribution. If you are on a Mac, use a Linux VM or container for the build rather than fighting the toolchain.

SELinux, IPVS modules and the failure you will hit first

The README's troubleshooting section documents a failure mode that is easy to misread as a bug in kube-vip. On nodes with SELinux enforcing, the container may be blocked from requesting kernel modules. The symptoms listed are the kube-vip pod entering Error or CrashLoopBackOff, logs showing ensure IPVS kernel modules are loaded, and audit denials for module_request from container_t. The fix the README recommends is to load the modules on every node that can run kube-vip before deploying it:

sudo modprobe ip_vs
sudo modprobe ip_vs_rr

To persist across reboots, the README suggests a file such as /etc/modules-load.d/kube-vip-ipvs.conf containing ip_vs and ip_vs_rr. It states a preference for preloading only the required modules rather than enabling the SELinux domain_kernel_load_modules boolean for containers. That preference is a security judgement as much as an operational one, and it is the kind of detail that separates a project with production users from one without. There is a second documented edge case. Some Gateway API controllers create LoadBalancer Services that intentionally have no Endpoints or EndpointSlices. By default kube-vip gates on endpoints. To reconcile such a Service you opt in with the annotation kube-vip.io/allow-reconcile-without-endpoints set to "true", and the README states this works only with externalTrafficPolicy: Cluster, has no effect for Local, and that the default endpoint-gated behaviour is unchanged for Services without the annotation. If you run a Gateway API implementation and see a Service stuck without an address, this annotation is the first thing to check.

Where kube-vip is the wrong tool

kube-vip is not an ingress controller and does not route HTTP by host or path. It hands out a VIP and balances at the transport layer. If what you need is TLS termination, virtual hosts or path-based routing, that belongs to an ingress or Gateway API implementation, and kube-vip would sit underneath it providing the address. The second boundary is the environment. The README's own framing is bare metal, edge and virtualisation, with a note that the alternative to kube-vip is a cloud provider's load balancer. On a managed Kubernetes service you already have a Service type LoadBalancer implementation, and adding kube-vip means running a component that duplicates it and competes for the same address space. Third, the control plane mode assumes you are assembling the cluster yourself, with kubeadm static Pods or a DaemonSet on K3s and similar distributions. If your distribution already ships a control plane VIP mechanism, kube-vip is redundant. Finally, the documentation that would answer the hard questions, such as when to choose raft over leader election, is not in the README; it is on the project site. If you cannot read that site and its architecture pages before deployment, you are guessing at the most consequential setting.

kube-vip compared with MetalLB, Keepalived and HAProxy

The closest comparison is MetalLB, which also implements Service type LoadBalancer for clusters without a cloud provider, and which people search for alongside kube-vip. The difference in scope is the control plane. MetalLB addresses Services only; kube-vip was, in the README's words, originally created to provide a HA solution for the Kubernetes control plane and later grew the load balancer role. If you need the API server VIP and the Service addresses from one component, kube-vip covers both, while MetalLB leaves the control plane to something else. The other comparison is the Keepalived plus HAProxy pair the README names as the traditional alternative. Keepalived handles the VIP with VRRP, HAProxy balances traffic, and you configure both. kube-vip folds them into one binary that watches the Kubernetes API, which means the configuration lives in Kubernetes objects rather than in two daemon configs. The trade-off is that you inherit kube-vip's own model, including its leader election or raft choice and its ARP or BGP choice, instead of the more widely documented VRRP setup. Nginx and Traefik come up in searches too, but those are proxies for application traffic; kube-vip does not replace them, it gives them an address to listen on.

Maintenance, licensing and what an upgrade costs

kube-vip is licensed under Apache-2.0, which permits commercial use and modification with the usual conditions around notices and patent grants; that is a summary of the licence identifier, not legal advice, and anyone embedding it in a product should read the LICENSE file in the repository. The repository is not archived, and the last push was on 2026-09-21, three days before this was written, with v1.2.4 released on 2026-09-16. That is a short gap between release and push, which suggests ongoing work rather than a frozen project. The Makefile pins VERSION to v1.2.4, so a build from source reports the release it corresponds to, and the linker flags embed the git revision as well. Upgrades are the operational cost to plan for. The README links a dedicated upgrade guide for in-place upgrades of a static Pod or DaemonSet, and the existence of that guide is a signal that the upgrade path is not just a re-apply. The go.mod pins Kubernetes client libraries at v0.36.4 and Go at 1.26.4, while the Dockerfile builds with golang:1.27.1-alpine3.23, so the build environment and the module requirement are not the same version. Anyone building a custom image should check that combination against their own toolchain before assuming it will compile unchanged.

Editorial conclusion

Adopt kube-vip when you run Kubernetes on hardware you own and need a control plane VIP plus Service type LoadBalancer addresses without a cloud provider. Do not adopt it expecting a full ingress controller or a managed load balancer with health checking beyond what the Service exposes; it is a VIP and L4 load balancer, not a proxy for HTTP routing. Before rolling it out, verify that your nodes can load the IPVS kernel modules under SELinux, decide between leader election and raft for the control plane, and confirm whether you want ARP (Layer 2) or BGP (Layer 3) for the VIP.

Frequently asked questions

Official sources

1. kube-vip/kube-vip on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases