kube-vip-cloud-controller ignoring range in config map
Describe the bug The IP given for the service is the IP of the physical host and not from the config-map range and then later changes back to the correct range.
To Reproduce Steps to reproduce the behavior:
- Create a 3 node
k3scluster withksupon raspberry pi 5's - Follow these steps to get a working cluster VIP https://kube-vip.io/docs/usage/k3s/
- Then follow these steps to for kube-vip-cloud-controller https://kube-vip.io/docs/usage/cloud-provider/
- Deploy and expose
hello-nodeworkload https://kubernetes.io/docs/tutorials/hello-minikube/
Expected behavior I started writting this issue because the service IP was from the physcial host and not the range from the config-map. But as I was writing it, I double checked and it has changed back to the config map?
root@kube-1:/home/shadycuz# kubectl -n kube-system describe configmaps kubevip
Name: kubevip
Namespace: kube-system
Labels: <none>
Annotations: <none>
Data
====
range-global:
----
192.168.4.110-192.168.4.150
BinaryData
====
Events: <none>
root@kube-1:/home/shadycuz# kubectl expose deployment hello-node --type=LoadBalancer --port=8080
service/hello-node exposed
root@kube-1:/home/shadycuz# kubectl get service hello-node
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-node LoadBalancer 10.43.253.73 192.168.4.102,192.168.4.103 8080:30465/TCP 11s
root@kube-1:/home/shadycuz# kubectl get service hello-node
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-node LoadBalancer 10.43.253.73 192.168.4.110 8080:30465/TCP 8m8sI was thinking maybe I didn't need to set up both the daemonset and the cloud-controller deployment? But now I'm thinking I didn't give the cloud-controller enough time to do its job and the physcial IP's were just placeholders?
Screenshots If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):
- OS/Distro: raspbian lite ARM64
- Kubernetes Version: v1.33.3+k3s1
- Kube-vip Version: 1.0.0
Kube-vip.yaml:
If Possible add in your kube-vip manifest (please remove anything that is confidential)
Which one? The one for the cluster VIP or the cloud-controller one?
Additional context
I have checked and I can reach the service on all 3 Ip's. Seems like maybe I shouldn't be able to reach them on http://192.168.4.103:8080/ and http://192.168.4.102:8080/
101 is the IP to kube-1... 102 to kube-2 etc.
EDIT:
I do see mention of my service in the daemon-set logs, not sure if thats to be expected:
2025/08/06 11:19:57 INFO Starting Kube-vip Manager with the ARP engine
2025/08/06 11:19:57 INFO Start ARP/NDP advertisement
2025/08/06 11:19:57 INFO Starting ARP/NDP advertisement
2025/08/06 11:19:57 INFO Starting UPNP Port Refresher
2025/08/06 11:19:57 INFO beginning services leadership namespace=kube-system "lock name"=plndr-svcs-lock id=kube-2
I0806 11:19:57.808674 1 leaderelection.go:257] attempting to acquire leader lease kube-system/plndr-svcs-lock...
2025/08/06 11:19:57 INFO cluster membership namespace=kube-system lock=plndr-cp-lock id=kube-2
I0806 11:19:57.808860 1 leaderelection.go:257] attempting to acquire leader lease kube-system/plndr-cp-lock...
2025/08/06 11:19:57 INFO New leader leader=kube-1
I0806 11:19:57.823949 1 leaderelection.go:271] successfully acquired lease kube-system/plndr-svcs-lock
2025/08/06 11:19:57 INFO (svcs) starting services watcher for all namespaces
2025/08/06 11:24:57 INFO [UPNP] Refreshing Instances "number of instances"=0
2025/08/06 11:29:57 INFO [UPNP] Refreshing Instances "number of instances"=0
2025/08/06 11:34:57 INFO [UPNP] Refreshing Instances "number of instances"=0
2025/08/06 11:36:24 INFO (svcs) adding VIP ip=192.168.4.110 interface=eth0 namespace=default name=hello-node
2025/08/06 11:36:24 INFO layer 2 broadcaster starting
2025/08/06 11:36:24 INFO inserting ARP/NDP instance name=192.168.4.110/32-eth0
2025/08/06 11:36:24 INFO [service] service=hello-node namespace=default "synchronised in"=43ms
2025/08/06 11:37:34 INFO removing ARP/NDP instance name=192.168.4.110/32-eth0