Idea to consolidate kube-vip installation methods

[rptaylor]

kube-vip can be installed via this helm chart, or a static YAML generation technique that seems a bit unconventional at first but makes sense as a way to define static pods (potentially required for control-plane LB depending how you do it).

The benefits of consolidating on helm as the installation method would be:

• avoid duplication of code, effort, documentation
• avoid risk of divergence or something getting missed or out of sync between the two methods
• avoid dependence on container-runtime specific details (e.g. Docker vs containerd)
• leverage a widely adopted tool for installing/templating/lifecycle management of Kubernetes apps

Notably, Cilium took a helm-first / helm-only installation approach - there is a cilium CLI that you can use to install, but under the hood it just uses Helm.

This could be achieved by adapting the installation steps in https://kube-vip.io/docs/installation/static/#generating-a-manifest to something like:

alias kube-vip-generate="helm template --repo https://kube-vip.github.io/helm-charts kube-vip kube-vip"

kube-vip-generate --set installMode=staticPod,env.vip_interface=$INTERFACE,config.address=$VIP,env.cp_enable=true,env.svc_enable=true,env.vip_leaderelection=true \
    | tee /etc/kubernetes/manifests/kube-vip.yaml

Notes:

• All of the --set args could of course be replaced by -f myvalues.yaml , as Helm values are usually set
• All of this is possible now, except for the hypothetical new value installMode which would be very easy to add, and used to control which chart templates are activated, e.g. "daemonSet" by default for the current behaviour, or alternatively "staticPod" which would generate the static pod YAML using a new template in the chart instead of the generator code in the kube-vip binary.
• The hard part would be porting the YAML generator code to Helm chart logic
• Depending on how people choose to use the static YAML generator, or how literally you interpret the documentation, this might imply installing the Helm CLI would be required on k8s nodes. However:
  • Personally, whether I'm doing 'helm template' or 'ctr run' or any other command to generate a YAML file, I would still only do it once and then use another mechanism (e.g. ansible, git, scp or some parallel copy command) to copy the output to the k8s nodes to ensure consistency. Especially considering the need to prepare for the template generation with env vars or a config file, no matter which way you do it, I still think it is best to do it just one time in one place, then install the output onto the k8s nodes as a separate out-of-band step.
  • Moreover I would anyway suggest that running commands on a management node is preferable to doing things on a k8s cluster node, and Helm is much easier/lighter to install than containerd, so overall this approach is more flexible and allows you to do the required steps anywhere, e.g. on your laptop or workstation.

[rptaylor]

This would benefit from a solution for helm/helm#31269

[rptaylor]

#91 is another example of an important fix that only went into the kube-vip YAML generator code and not the Helm chart, illustrating the cost and risk of two separate approaches.

[rptaylor]

It looks like the same duplication exists for KVCP too: https://github.com/kube-vip/kube-vip-cloud-provider/blob/main/manifest/kube-vip-cloud-controller.yaml