kube-vip 0.7.0 causes nodes to lose connection and interfaces would lose IPs

[Michaelpalacce]

I am writing this, with the full understanding that it's very vague. I was pretty much the whole day trying to debug what is happening and came to the realization that kube-vip was somehow causing k3s node eth0 interfaces to lose connection.

This lead to a bunch of other issues, of course. I don't have the necessary knowledge to figure out what exactly was happening, but outside of connection loss, this was causing entire network slowdowns, and it was also affecting other devices not connected to k3s at all (like my phone's Wi-Fi).

To Reproduce
Steps to reproduce the behavior:

1. Set up a fresh cluster k3s v 1.29.0
2. Get values from here
3. Helm install with provided values.

Expected behavior
Create a virtual ip that I can use

Screenshots
Can't do this now... at this point, I redid my cluster and restored all my backups. I realize this is not helpful, still deciding to post this if anyone else finds this.

Environment (please complete the following information):

• OS/Distro: Ubuntu Server 20.04
• Kubernetes Version: v.1.28.3, v.1.28.5, v.1.29.0
• Kube-vip Version: 0.7.0 (works with 0.6.4)

Kube-vip.yaml:

image:
    repository: ghcr.io/kube-vip/kube-vip
    tag: "v0.6.4"

config:
    address: "192.168.1.2"

env:
    vip_interface: ""
    vip_arp: "true"
    lb_enable: "true"
    lb_port: "6443"
    vip_cidr: "32"
    cp_enable: "true"
    svc_enable: "true"
    vip_leaderelection: "false"

[Michaelpalacce]

This is still observed with both 0.7.1 and 0.7.2, not sure if anything is changed... Essentially when I run these versions the whole cluster loses connection internally and etcd goes haywire trying to elect a new leader constantly

[Michaelpalacce]

Should be reopened @thebsdbox

[Cellebyte]

@Michaelpalacce you should not run cp_enable and svc_enable with the same daemonset when you disable the leader election when you use vip_arp.

[Michaelpalacce]

So enabling leader election would solve the problem? Will try it out.

@Cellebyte if you can, can you please explain why this is a bad thing?

[Michaelpalacce]

This is what happens immediately:

This is what I went for:

        image:
            repository: ghcr.io/kube-vip/kube-vip
            tag: "v0.7.2"

        config:
            address: "192.168.1.2"
        env:
            vip_interface: ""
            vip_arp: "true"
            lb_enable: "true"
            lb_port: "6443"
            vip_cidr: "32"
            cp_enable: "true"
            svc_enable: "true"
            vip_leaderelection: "true"

[Cellebyte]

If you disable leader election and use the arp mode together with svc_enable. Kube-vip will announce an IP from every node. Which unfortunately does not work with arp. As it has no possibility for multiple endpoints being announced in the same layer2 network.

[Michaelpalacce]

I see, thank you for the explanation!

However, there is still an issue it seems?

[Cellebyte]

@Michaelpalacce then please elaborate the issue :)