multus-cni
multus-cni copied to clipboard
Failed To Setup Network For Sandbox After Deploying Multus
I have a cluster setup with Cilum as my main CNI. I am trying to add Multus to allow specific pods to have multiple interfaces (to hopefully fix some multicasting issues).
I deployed Multus via the thick
method daemonset. Before I configure any pod to actually use Multus, I can kill and reschedule any pod that has a networking interface and the following error occurs. The pod refuses to start. A similar error happens on ALL pods, not just ones that are configured to use Multus.
Sorry I dont have this in text format, I quickly grabbed a screenshot and then started recovering my cluster by removing Multus and the conf
file it creates.
Is this an issue with Multus & Cilium running together? Or do I have some type of configuration error somewhere?
Could you please share following info:
- which container image is used (i.e. container image URL) and
- pod yaml file (of multus pod, in kube-system namespace)
I used the thick daemonset from here
- Container used: ghcr.io/k8snetworkplumbingwg/multus-cni:snapshot-thick
- yaml, see above. I made no changes to the yaml supplied.
Hmm... it looks like multus-daemon failed to get pod network namespace inode from the pod. Could you please check '/var/run/netns/cni-....' accessibility? (you can find it from last message from above), from multus-daemon pod?
I've noticed similar behaviour where no pods were coming online with the current master. Multus seems to be up and running but pod creation just hangs. Using Calico instead.
The 3.9.1 release is also broken but for other reasons. It seems to be using the wrong image tag in the YAML so Multus doesn't even come online itself with this release; it's set to use thick
, which does not contain the generate-kubeconfig
binary for one. Looks to be related to #918
Using the 3.9.1 yaml and updating the tag to either stable
or v3.9.1
creates a Multus deployment that runs and other pods start coming online fine.
File permissions on /var/run/netns
on my end are 750. There are no underlying cni-*
files/directories, just files (UUID names) with mode 444.
If your thick
means container image tag, such as :thick
, please update to ghcr.io/k8snetworkplumbingwg/multus-cni:v3.9.1-thick-amd64
. As you mentioned above, the issue is same to #918.
I'll need to set up a test cluster to get those logs for you. Give me a few days
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.