-
Notifications
You must be signed in to change notification settings - Fork 590
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clean Up auto generated config #592
Comments
Due to Issue: k8snetworkplumbingwg/multus-cni#592 When multus is removed from the cluster it is left in an inoperable as CNI calls fail due to removed RBAC. While it makes sense to occur for secondary network when specified in a pod spec as net-attach-def name, it should not fail on primary network. Downgrade multus CNI to v3.4.1 where such an issue does not occur.
Due to Issue: k8snetworkplumbingwg/multus-cni#592 When multus is removed from the cluster it is left in an inoperable as CNI calls fail due to removed RBAC. While it makes sense to occur for secondary network when specified in a pod spec as net-attach-def name, it should not fail on primary network. Downgrade multus CNI to v3.4.1 where such an issue does not occur. Signed-off-by: Adrian Chiris <[email protected]>
It should be noted that in multus v3.4.1 this operation is not observed so with multus v3.4.1 when you deploy it in a k8s cluster and then delete (daemonset, rbac) pods with primary network keep on working with multus v3.6 doing the same leaves k8s cluster in an inoperable state as multus CNI calls now fail. i didnt have time to dig into this issue but it seems that between v3.4.1 and v3.6 we lost the ability of multus to handle failure to access kubernetes API when not nessecary (e.g no secondary network for pod and not |
Hi, do you please have a proper solution? Please let us know as soon as possibile. Thanks |
In NVIDIA network operator we currently WA this issue by deploying multus daemonset with a pre-stop hook which deletes the generated multus cni config file (we use |
you are my hero! I confirm it is the solution! Thanks |
Great approach Adrian, I think handling this with an operator is great, that's an excellent way to make an opinionated way to handle the lifecycle and to denote node readiness based on a specific scenario. |
After multus daemonset removal if the multus config is in place the multus CNI binary will be used to create/delete network namespaces for pods, this will fail since the apiserver access done at multus fails at authentication if the multus pod is gone [1]. This change add the suggested solution adding a preStop hook that will remove the multus config before stop. [1] k8snetworkplumbingwg/multus-cni#592 Signed-off-by: Quique Llorente <[email protected]>
After multus daemonset removal if the multus config is in place the multus CNI binary will be used to create/delete network namespaces for pods, this will fail since the apiserver access done at multus fails at authentication if the multus pod is gone [1]. This change add the suggested solution adding a preStop hook that will remove the multus config before stop. [1] k8snetworkplumbingwg/multus-cni#592 Signed-off-by: Quique Llorente <[email protected]>
After multus daemonset removal if the multus config is in place the multus CNI binary will be used to create/delete network namespaces for pods, this will fail since the apiserver access done at multus fails at authentication if the multus pod is gone [1]. This change add the suggested solution adding a preStop hook that will remove the multus config before stop. [1] k8snetworkplumbingwg/multus-cni#592 Signed-off-by: Quique Llorente <[email protected]>
After multus daemonset removal if the multus config is in place the multus CNI binary will be used to create/delete network namespaces for pods, this will fail since the apiserver access done at multus fails at authentication if the multus pod is gone [1]. This change add the suggested solution adding a preStop hook that will remove the multus config before stop. [1] k8snetworkplumbingwg/multus-cni#592 Signed-off-by: Quique Llorente <[email protected]>
* multus: Bump to 3.8 Multus project has change a little: - They don't have a manifests pert arch since they are using multiarch registry. - They have bump golang to 1.17 This change moves away golang origin builder since there is non for 1.17 Signed-off-by: Quique Llorente <[email protected]> * multus: Delete config preStop hook After multus daemonset removal if the multus config is in place the multus CNI binary will be used to create/delete network namespaces for pods, this will fail since the apiserver access done at multus fails at authentication if the multus pod is gone [1]. This change add the suggested solution adding a preStop hook that will remove the multus config before stop. [1] k8snetworkplumbingwg/multus-cni#592 Signed-off-by: Quique Llorente <[email protected]>
change thin plugin dockerfile to use the same base image as the thick plugin. this will allow users to implement simple lifecycle hooks e.g exec simple shell cmd to delete multus conf file on container exit which allows to remove multus from the cluster without breaking it. this functionality was possible in v3. Related issue: k8snetworkplumbingwg#592 Signed-off-by: adrianc <[email protected]>
When multus daemonset is deployed with --multus-conf-file=auto, it generates an auto cnofig file in CNI_DIR, usually it is 00-multus. After removing the multus daemonset and roles, this file will stay which cause to call multus cni that doesn't have the permissions to access k8s api, that cause the multus to fail everytime.
What would you like to be added:
Clean up the auto generated config file
Why is this needed:
Leaving config file for mulus without permission causing the cluster to not be able to schedule pods
The text was updated successfully, but these errors were encountered: