Hi, I'd like for the documentation to not show --taint as required for kube-vip as Daemonset.
I've really enjoyed setting up kube-vip on the control plane with VIP and LB using static pods and BGP. Currently running v0.6.3. I set up the cloud-provider and created a configmap in kube-system called kubevip that had data.cidr-global: 10.245.0.0/18. I have a kubernetes/ingress-nginx controller service of type loadbalancer with spec.externalTrafficPolicy: local. I've been reading a few of the open issues on the kube-vip project around this, and they all seem to be treated like this fuctionality is implemented, yet I was getting \ for external IPs on loadbalancers with externalTrafficPolicy: local. From the documentation it seems like a kube-vip instance would need to run on a worker. But the pages mostly feel like they address control plane availability. There is some mention of service VIPs and loadbalancing, and the existence of options like --controlplane and --services implied to me that one could run kube-vip on workers without anything related to the control-plane going on. So far so good.
I tried to generate a manifest for a daemonset for kube-vip, to run kube-vip pods on my cluster. My control plane is still using static pods, is there a way to migrate to a controlplane daemonset after kubeadm standup or should I leave them as is? I figured I could have a daemonset limit kube-vip to being run on all worker nodes, just not controlplane. My limited kubernetes knowledge aside, it turns out that happens when there aren't any specific node selectors (not sure what they're called off-hand) for the daemonset, or something along those lines.
To not include affinity rules, --taint can be left out and when applied to the cluster, I have a kube-vip pod on each worker performing service elections and I've successfully had an external IP issued to my ingress-nginx.
The point of this issue is to address the documentation's use of "Required for kube-vip as Daemonset" around --taint. I don't believe it's true --taint is required, as removing that option from the command generating my manifest solved the issue I had been trying to address.
Could that requirement be removed and some clarifications be made around daemonset or static pod (would anyone bother with this approach for workers?) for kube-vip on workers? And around whether both control-plane and workers should use --services and --servicesElection especially considering I've deployed both static pods and a daemonset?
Hi, I'd like for the documentation to not show --taint as required for kube-vip as Daemonset.
I've really enjoyed setting up kube-vip on the control plane with VIP and LB using static pods and BGP. Currently running v0.6.3. I set up the cloud-provider and created a configmap in kube-system called kubevip that had data.cidr-global: 10.245.0.0/18. I have a kubernetes/ingress-nginx controller service of type loadbalancer with spec.externalTrafficPolicy: local. I've been reading a few of the open issues on the kube-vip project around this, and they all seem to be treated like this fuctionality is implemented, yet I was getting \ for external IPs on loadbalancers with externalTrafficPolicy: local. From the documentation it seems like a kube-vip instance would need to run on a worker. But the pages mostly feel like they address control plane availability. There is some mention of service VIPs and loadbalancing, and the existence of options like --controlplane and --services implied to me that one could run kube-vip on workers without anything related to the control-plane going on. So far so good.
I tried to generate a manifest for a daemonset for kube-vip, to run kube-vip pods on my cluster. My control plane is still using static pods, is there a way to migrate to a controlplane daemonset after kubeadm standup or should I leave them as is? I figured I could have a daemonset limit kube-vip to being run on all worker nodes, just not controlplane. My limited kubernetes knowledge aside, it turns out that happens when there aren't any specific node selectors (not sure what they're called off-hand) for the daemonset, or something along those lines.
To not include affinity rules, --taint can be left out and when applied to the cluster, I have a kube-vip pod on each worker performing service elections and I've successfully had an external IP issued to my ingress-nginx.
The point of this issue is to address the documentation's use of "Required for kube-vip as Daemonset" around --taint. I don't believe it's true --taint is required, as removing that option from the command generating my manifest solved the issue I had been trying to address.
Could that requirement be removed and some clarifications be made around daemonset or static pod (would anyone bother with this approach for workers?) for kube-vip on workers? And around whether both control-plane and workers should use --services and --servicesElection especially considering I've deployed both static pods and a daemonset?
Cheers :)