multus-cni
multus-cni copied to clipboard
Master CNI file flag option isn't working for thin plugin
What happend:
I am trying to use use the --multus-master-cni-file-name
flag with the thin-plugin. It is expected that it should use the cni file name passed here everytime as default master cni and not the alphabetically first file in the cni-bin directory. But this feature does not seem to work and it always picks up the first file alphabetically instead of what is passed in that flag.
I checked the code and I see that the file name is taken and is not being used to configure anything in this function: https://github.com/k8snetworkplumbingwg/multus-cni/blob/8e5060b9a7612044b7bf927365bbdbb8f6cde451/cmd/thin_entrypoint/main.go#L301
Tested this for thick-plugin and works as expected.
What you expected to happen: It was expected that the master cni is always the plugin file that is passed.
How to reproduce it (as minimally and precisely as possible):
Install the helm chart on a k8s cluster. Additionally, include the flag --multus-master-cni-file-name
under args
in the daemonset yaml.
Anything else we need to know?:
Environment:
- Multus version : lates image path and image ID (from 'docker images')
- Kubernetes version (use
kubectl version
): 1.25 - Primary CNI for Kubernetes cluster: calico
- OS (e.g. from /etc/os-release):
- File of '/etc/cni/net.d/'
- File of '/etc/cni/multus/net.d'
- NetworkAttachment info (use
kubectl get net-attach-def -o yaml
) - Target pod yaml info (with annotation, use
kubectl get pod <podname> -o yaml
) - Other log outputs (if you use multus logging)
I ran into this as well upgrading from (ancient) 3.4 -> 4.0.2. With
- name: kube-multus
image: ghcr.io/k8snetworkplumbingwg/multus-cni:v4.0.2
command: ["/thin_entrypoint"]
args:
- "--multus-conf-file=auto"
- "--multus-autoconfig-dir=/host/etc/cni/net.d"
- "--cni-conf-dir=/host/etc/cni/net.d"
- "--multus-master-cni-file-name=10-canal.conflist"
It keeps sucking in 00-multus.conf
on every restart:
pretty printed
{
"cniVersion": "0.3.1",
"name": "multus-cni-network",
"type": "multus",
"kubeconfig": "/etc/cni/net.d/multus.d/multus.kubeconfig",
"delegates": [
{
"cniVersion": "0.3.1",
"delegates": [
{
"cniVersion": "0.3.1",
"delegates": [
{
"cniVersion": "0.3.1",
"delegates": [
{
"cniVersion": "0.3.1",
"delegates": [
{
"cniVersion": "0.3.1",
"name": "k8s-pod-network",
"plugins": [
{
"datastore_type": "kubernetes",
"ipam": {
"subnet": "usePodCidr",
"type": "host-local"
},
"kubernetes": {
"kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
},
"log_file_path": "/var/log/calico/cni/cni.log",
"log_level": "info",
"mtu": 1450,
"nodename": "kueyen01",
"policy": {
"type": "k8s"
},
"type": "calico"
},
{
"capabilities": {
"portMappings": true
},
"snat": true,
"type": "portmap"
},
{
"capabilities": {
"bandwidth": true
},
"type": "bandwidth"
}
]
}
],
"kubeconfig": "/etc/cni/net.d/multus.d/multus.kubeconfig",
"name": "multus-cni-network",
"type": "multus"
}
],
"kubeconfig": "/etc/cni/net.d/multus.d/multus.kubeconfig",
"name": "multus-cni-network",
"type": "multus"
}
],
"kubeconfig": "/etc/cni/net.d/multus.d/multus.kubeconfig",
"name": "multus-cni-network",
"type": "multus"
}
],
"kubeconfig": "/etc/cni/net.d/multus.d/multus.kubeconfig",
"name": "multus-cni-network",
"type": "multus"
}
]
}
It seems like the default output file should be filtered out of the input cni config file list.
Thanks for the heads up. When we deprecated the entrypoint.sh it looks like this parameter might've been missed.
HI, I will work on this issue next a few weeks.