Closed EyeCantCU closed 2 months ago
There may already be a similar fix for this in the v4.1 release, but due to dependencies it'd be great to get this back-ported to v4.0.2. As there's no branch for v4.0.2, here's a proposal:
I see it already being reported here - https://github.com/k8snetworkplumbingwg/multus-cni/issues/1130 - and fixed here - https://github.com/k8snetworkplumbingwg/multus-cni/commit/159f2610c0775a3d22fb1109786dab5ef33bb9f7 - It's released in 4.1.0
version
It'd be great to see it backported to 4.0.3
version too. @mamccorm , is your proposal going to be worked on?
Looks like it's fixed up, thanks for the report
What happend:
The very first network configuration file is selected as the delegate. This file is always
00-multus.conf
in/etc/cni/net.d/
.10-calico.conflist
is then correctly appended to00-multus.conf
When restarting the multus pod, it appends the configuration for
00-multus.conf
to all delegates (now including itself), breaking networking. Restart after restart, the file gets larger and larger due to thisWhat you expected to happen:
Multus would not delegate to itself
How to reproduce it (as minimally and precisely as possible):
curl -O https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/master/deployments/multus-daemonset.yml
kubectl apply -f multus-daemonset.yml
kube-multus
pod <- this is where things breakMultus will have delegated to itself breaking networking
Anything else we need to know?:
Rancher provides a patch that addresses this: https://github.com/rancher/image-build-multus/blob/v4.0.2-build20231009/self_delegation_bug.patch
Would this be possible to apply in a 4.0.3 patch release?
Environment:
ghcr.io/k8snetworkplumbingwg/multus-cni:v4.0.2
kubectl version
): 1.31.0