Kube-vip as a Static Pod
Static pods are a Kubernetes pod that is ran by the
kubelet on a single node, and is not managed by the Kubernetes cluster itself. This means that whilst the pod can appear within Kubernetes it can't make use of a variety of kubernetes functionality (such as the kubernetes token or
configMaps). The static pod approach is primarily required for kubeadm, this is due to the sequence of actions performed by
kubeadm. Ideally we want
kube-vip to be part of the kubernetes cluster, for various bits of functionality we also need
kube-vip to provide a HA virtual IP as part of the installation.
The sequence of events for this to work follows:
- Generate a
kube-vipmanifest in the static pods manifest folder
kubeadm init, this generates the manifests for the control plane and wait to connect to the VIP
kubeletwill parse and execute all manifest, including the
kube-vipstarts and advertises our VIP
kubeadm initfinishes succesfully.
Kube-Vip as HA, Load-Balancer or both
When generating a manifest for
kube-vip we will pass in the flags
--services these will enable the various types of functionality within
With both enabled
kube-vip will manage a virtual IP address that is passed through it's configuration for a Highly Available Kubernetes cluster, it will also "watch" services of
type:LoadBalancer and once their
spec.LoadBalancerIP is updated (typically by a cloud controller) it will advertise this address using BGP/ARP.
Generating a Manifest
This section details creating a number of manifests for various use cases
Set configuration details
Configure to use a container runtime
The easiest method to generate a manifest is using the container itself, below will create an alias for different container runtimes.
alias kube-vip="ctr run --rm --net-host docker.io/plndr/kube-vip:0.3.1 vip /kube-vip"
alias kube-vip="docker run --network host --rm plndr/kube-vip:0.3.1"
This configuration will create a manifest that starts
kube-vip providing controlplane and services management, using leaderElection. When this instance is elected as the leader it will bind the
vip to the specified
interface, this is also the same for services of
kube-vip manifest pod \ --interface $INTERFACE \ --vip $VIP \ --controlplane \ --services \ --arp \ --leaderElection | tee /etc/kubernetes/manifests/kube-vip.yaml
This configuration will create a manifest that will start
kube-vip providing controlplane and services management. Unlike ARP, all nodes in the BGP configuration will advertise virtual IP addresses.
Note we bind the address to
lo as we don't want multiple devices that have the same address on public interfaces. We can specify all the peers in a comma seperate list in the format of
kube-vip manifest pod \ --interface $INTERFACE \ --vip $VIP \ --controlplane \ --services \ --bgp \ --localAS 65000 \ --bgpRouterID 192.168.0.2 \ --bgppeers 192.168.0.10:65000::false,192.168.0.11:65000::false | tee /etc/kubernetes/manifests/kube-vip.yaml