Want a streamlined service
type: LoadBalancer solution with a focus on high availability for your Kubernetes cluster on metal? Kube-Vip might just be the answer you’ve been looking for.
Kube-Vip takes a lightweight and multi-architecture approach to Kubernetes load balancing. It focuses on providing both highly available (HA) networking endpoints and additional functionality for underlying network services by creating support for not only a HA control plane but also service
type: LoadBalancer functionality.
Kube-Vip provides various solutions for load balancing inside and outside a Kubernetes cluster. This guide will be focused on the features and integrations of Kube-Vip Kubernetes service
type: LoadBalancer that work with Equinix Metal. We will be exploring Kube-Vip’s key features and deployment considerations.
Kube-Vip provides a decoupled centralized
type: LoadBalancer solution for Kubernetes. It enables you to handle both the life cycles of Virtual IPs (VIPs) for high availability (HA) and for Kubernetes load balancing. Being able to handle load balancing within and outside of a cluster using one tool can streamline your load balancing solution.
While Kube-Vip does provide solutions for load balancing inside and outside a Kubernetes cluster this guide will be focused on the features and integrations of Kube-Vip Kubernetes service
type: LoadBalancer that work with Equinix Metal.
So, why use Kube-Vip for service
type: LoadBalancer on metal? Well, here are a couple key reasons to consider:
Easy manifest deployment.
Supports management via BGP or ARP functionality.
Supported by core Equinix Metal integration (CCM, Packet API).
For more information on Kube-Vip architecture, see the official in-depth Kube-Vip architecture guide. Please note that you can find the
type: LoadBalancer instructions under the Load Balancing (Inside a cluster) section in the architecture guide.
Kube-Vip provides a high availability solution for Kubernetes service
type: LoadBalancer on metal by providing key features such as:
Leader election for ARP (Layer 2)
Multiple nodes with BGP
Address pools per namespace or global
Addresses via an existing network DHCP
Address exposure to gateway via UPNP
Vender API Integrations
For more information on Kube-Vip features find more information on the features section of the Kube-Vip official github project.
Kube-Vip was updated to support BGP as a VIP failover mechanism in version 0.1.8. This allows nodes that are selected as leaders to update their peers in order for traffic to be routed through the newly elected node. Flags have been added in order to enable functionality such as:
Enabling BGP support within Kube-Vip
Showing local AS number
Showing the local router address
Showing the AS number for a BGP peer
Showing the address of a BGP peer
Kube-Vip has Equinix-Metal-specific integration support that allows the usage of the Equinix Metal API to determine the BGP configuration being used for the nodes in the cluster. As long as the BGP flag is enabled,
--bgp in Kube-Vip you can pass the following Equinix-Metal-specific flags:
The example below, taken from the Kube-Vip documentation, shows the flags being used to start all pods in active mode, which will allow nodes to advertise the VIP to the routers when a service is exposed.
\- name: vip_packet value: "true" \- name: vip_packetproject value: "My Project" \- name: PACKET_AUTH_TOKEN value: "XXYZZYVVY"
Alternatively, when coupled with the Equinix Metal integration, Cloud Controller Manager (CCM), Kube-Vip can read the node annotations written by the CCM (the Equinix Metal BGP configuration). This allows Kube-Vip to inherit the BGP configuration with minimal or no input from whomever is deploying Kube-Vip.
Kube-Vip also offers additional BGP features that are key to any metal setup. Features such as:
Equinix Metal CCM config maps support
For more information on Kube-Vip BGP support please visit the Kube-Vip official documentation.
So, what do you need to get started? Kube-VIP works on all core Linux-based operating systems, though for reference, most of its official documentation uses Ubuntu as the example OS.
While Kube-Vip offers a few ways to deploy a service
type: LoadBalancer, you can find a general getting started guide for getting a sample Kube-Vip
type: LoadBalancer, please see the Kube-Vip official documentation.
The simplest way to deploy Kube-Vip is by using the subcommand
manifest pod|daemonset to deploy a pod/daemonset. You can find additional information on deploying Kube-Vip manifests on the official Kube-Vip hybrid guide.
type: LoadBalancer deployments:
Address Resolution Protocol (ARP) is a protocol that enables us to find out the layer 2 link or MAC address that is associated with the given IP Address. You can find additional information about using ARP with Kube-Vip’s official ARP deployment guide.
In order to get ARP up and running on Kube-Vip, ipvs has to have strict ARP enabled. You can do this by following the commands listed on the Kube-Vip ARP deployment guide or shown below:
Checking the strict ARP value:
\$ kubectl describe configmap -n kube-system kube-proxy \| grep ARP strictARP: false
Then enabling the strictARP value if false:
\$ kubectl get configmap kube-proxy -n kube-system -o yaml \| \\ sed -e "s/strictARP: false/strictARP: true/" \| \\ kubectl apply -f - -n kube-system
Border Gateway Protocol (BGP) is an industry standard for exchanging routing and reachability information among systems. Using BGP opens up a lot of possibilities for your Kubernetes network such as routable pod and service IPs which wouldn't be available in most cloud environments.
You can find Kube-Vip’s official BGP deployment guide on their website kube-vip.io.
Kube-Vip provides a flexible solution for your HA service
type: LoadBalancer needs. You can find additional resources and information on Kube-Vip and Kubernetes load balancing below: