When the cloud-controller manager detects a mismatch between the clustercidr provided to it via argument and node.spec.podcidrs of existing nodes, it assumes this is a fatal condition and halts its execution and crash. This mismatch is not a fatal condition, controller manager should tolerate this mismatch and keep trying to reconcile instead of crashing. The side-effect of crashing is that when a new node joins the cluster, its not able to get the new podcidr from controller manager because its been crashing.
What you expected to happen:
If controller-manager tolerates this mismatch, we can have old nodes running old podcidr and new nodes running new podcidr and that's a perfectly ok condition to be in. In fact when a user wants to live migrate a running cluster from one podcidr to another, it will run thru this exact scenario and get blocked if this issue is not fixed.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:
Kubernetes version (use kubectl version):
Cloud provider or hardware configuration:
OS (e.g: cat /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Network plugin and version (if this is a network-related bug):
What happened:
When the cloud-controller manager detects a mismatch between the clustercidr provided to it via argument and node.spec.podcidrs of existing nodes, it assumes this is a fatal condition and halts its execution and crash. This mismatch is not a fatal condition, controller manager should tolerate this mismatch and keep trying to reconcile instead of crashing. The side-effect of crashing is that when a new node joins the cluster, its not able to get the new podcidr from controller manager because its been crashing.
What you expected to happen:
If controller-manager tolerates this mismatch, we can have old nodes running old podcidr and new nodes running new podcidr and that's a perfectly ok condition to be in. In fact when a user wants to live migrate a running cluster from one podcidr to another, it will run thru this exact scenario and get blocked if this issue is not fixed.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:
kubectl version):cat /etc/os-release):uname -a):