Currently cni installer is within the kmesh daemon, however when the daemon panic unexpected, the cni does not have a chance to uninstall all the cni configs.
If the kubeconfig kmesh-cni using is not out of date, then after kmesh-daemon updated, it can start up successfully.
However if the kubeconfig's token is out dated, the the above procedure would fail.
Add a go routine in cni installer, watch the token file, update the kubeconfig when token modified. This would make sure the kubeconfig can not expire easily.
Make kmesh-cni CmdAdd never fail, even it failed, we return success. And depend on manage controller to manage workload eventually.
What would you like to be added:
Currently cni installer is within the kmesh daemon, however when the daemon panic unexpected, the cni does not have a chance to uninstall all the cni configs.
If the kubeconfig kmesh-cni using is not out of date, then after kmesh-daemon updated, it can start up successfully. However if the kubeconfig's token is out dated, the the above procedure would fail.
Several solutions come up to my mind:
CmdAdd
never fail, even it failed, we return success. And depend on manage controller to manage workload eventually.Why is this needed: