https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rke2
a
This message was deleted.
b
it seems like your cluster is configured with multus as the main cni plugin
check what you have in 
/etc/cni/net.d
m
Yeah it seems upon a server restart it launched a job to uninstall my non-rke2-managed multus, and decided to use it for CNI 😕 The --cni flag was still just 'canal'. I've fixed this temporarily now by setting my config.yaml to:
Copy code
cni: 
- multus
- canal
and following the install of rke2 multus, I installed my own multus as well (it's a requirement for some workloads, being an ISP). I guess I'll need to figure out how to either make rke2-server ignore multus living in the cluster, or if it's the same version of multus, figure out how to make it watch annotations and add networks per networkattachmentdefinitions.
That doesn't seem like correct behaviour though, to assume control of something it hasn't installed - and suddenly ignore the --cni flag
b
kubelet will pick the cni that has the config with the least number in 
/etc/cni/net.d
, if you remove multus from that directory, it will pick the next one
m
Oh, now that's interesting to know. Okay - so potentially I could also just 
mv /etc/cni/net.d/00-multus.conf /etc/cni/net.d/99-multus.conf
and it would potentially have resolved it? Is this an RKE only thing, or shall I find this selection order in code for kubelet? I'll do some digging if so! 🙂 Appreciate that.
b
correct, that would fix it, assuming there is another file there with a lower number than 99
the communication kubelet-CNI is stateless, it will call the "ADD" or "DEL" API and will do it to whatever plugin is there with the lowest number. It does not remember what it picked before
🙌 1
2 Views
Open in Slack
PreviousNext
Powered by