Why#
I’ve used kube-vip and MetalLB in my homelab for many years. MetalLB is often recommended when you search for how to get a floating IP for a k8s Service. When I launched my homelab k8s cluster about 3 years ago I found MetalLB as a result of its popularity and chose it. MetalLB was managing a floating virtual IP (VIP) for my Kubernetes Services. However MetalLB does not provide the ability to float a VIP for the control plane kube-api, therefore I used kube-vip.
After using kube-vip for some time I noticed that they have the kube-vip-cloud-controller. Odd name for something I’m running at home and not in the “cloud”, but hey, maybe now I can say I run my own cloud?
Anyway, the kube-vip cloud-controller does what MetalLB was already doing for me. I’ve been happy with kube-vip and my MetalLB manifests weren’t version controlled so I was in a 2 birds with 1 stone situation. I could add the kube-vip-cloud-controller manifests to git and replace MetalLB with kube-vip.
kube-vip vs MetalLB#
I am no MetalLB guru but I know a lot about kube-vip, since I deployed it at a previous company in BGP mode in multiple on-prem k8s clusters. I’ve read that MetalLB does offer more features than kube-vip, but for me none of those features were needed. If you are more of a network engineer and know what MetalLB features kube-vip doesn’t have, feel free to send me an email and I’ll add them to this post.
After deploying kube-vip I did notice one advantage of kube-vip: memory usage.
MetalLB has 2 components: the speaker and the controller.
Here is the memory usage for the controller and the speaker. The controller was using around
70 MiB, and the speaker was around 37 MiB. I had 1 controller and 5 speakers (DaemonSet).
For a total of 255 MiB, almost a quarter of a gig. Not much in the grand scheme of things,
but especially with RAM prices being so high nowadays, it all adds up.
Now let’s take a look at the memory for kube-vip. kube-vip also has 2 components, the cloud controller (similar to the MetalLB controller), and the main kube-vip program (similar to the MetalLB speaker).
The kube-vip controller is using around 25 MiB, and the kube-vip pods are using around 24 MiB. I have the same amount of pods as I did with MetalLB, 1 controller, 5 regular kube-vip pods for a total of 144 MiB, a savings of over 100 MiB.
Below is the CPU usage for everything, but it is low enough that it is not worth going into detail.
Conclusion#
So kube-vip is now providing a floating IP for my control plane nodes and any Services I have in my Kubernetes cluster. kube-vip is saving me about 100 MiB in memory. Both of these reasons are why I switched from using MetalLB to kube-vip.
kube-vip has a bunch of other cool features that I’ve never tried out like egress and WireGuard mode as well. If you haven’t heard of kube-vip, check it out kube-vip.io.