https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rke2
a
This message was deleted.
c
we don’t typically support changing the CNI on a running cluster.
it is very likely to result in broken cluster networking unless you have a VERY good guide on what all to clean up
b
it's been rebooted if that's what you're referring to
or are you saying you don't support ever changing the cni period
c
yeah. CNI should be a settled decision when you build the cluster. Changing it after the cluster has been started and there are nodes and pods present is unlikely to work.
b
shrug
c
different CNIs use different ways of passing traffic (iptables/ebpf/ipvs), don’t reliably clean up after themselves when removed, don’t agree on how to do IPAM… its a mess.
b
the pods have all been restarted etc, I've migrated clusters from canal/calico to cilium etc before
it's generally functional, but it's clearly trying to do something funny with LB ips that run directly inside the cluster
I keep very close tabs on all the iptables/ipvs/etc rules so that's all been cleaned up
c
if you put calico in ebpf mode it will try to replace kube-proxy, and you should probably disable the built-in kube-proxy. is it that perhaps?
b
unless that's the default no, is that even possible with windows nodes in the mix?
all of this bs is to make cluster work with windows lol, it's terrible to walk away from cilium
I worked through so many bugs with them over the years to get ever single weird edge case cleaned up..now this
c
no, wouldn’t work with windows
b
yeah, I got some catching up do to with calico config
we have this in place for cilium+dsr and that was causing the problem with calico: https://github.com/travisghansen/metallb-node-route-agent
65 Views
Open in Slack
PreviousNext
Powered by