[v2.0.0 Issue]: `CrashLoopBackOff`, `failed to run kube-router: failed to synchronize cache: 1m0s timeout` about kube-router HOT 6 CLOSED

Ok
While I understand and kind of aggree with the explanation and the breaking change from 1.x to 2.x,
It appears that many providers of managed Kubernetes control plane do not specify a tag for the components they install in kube-system.
So that did came to me as a surprise when adding or rebooting a node.
That is why unfortunately it will break for many other people using managed control planes.

Maybe a hint or warning of the braking change can be written on output log, alongside the version?

from kube-router.

@alexfouche thanks for your feedback. This has been implemented in version v2.0.1 of the kube-router container and kube-router will now properly display its version and build date, it will also give a warning about the 2.0.X version until we get to 2.1.X.

from kube-router.

Yup, this is expected. v2.0.0 breaks backward compatibility. See the release description for more information: https://github.com/cloudnativelabs/kube-router/releases/tag/v2.0.0

If you're worried about this type of breaking changes, then I would recommend using version tags instead of latest. In general, we try really hard to not break backward compatibility, but it is necessary for some changes. In this case, the change that is required to understand all of the endpoint IPs and not just the primary endpoint IP that is required for dual-stack functionality.

The log message, seems to give a pretty distinct picture of what's happening.

from kube-router.

I'll look into the version not displaying in the logs.

from kube-router.

If you're worried about this type of breaking changes, then I would recommend using version tags instead of latest.

Installing kube-router following the documentation will install with latest. Then it will silently upgrade the images and break the cluster when a node restarts (just happened to me 😰).

from kube-router.

Latest represents the bleeding edge of stable, and running any container (kube-router or otherwise) with the latest tag and an image pull policy of Always is inherently risky. In general, best practice, where you don't want to bring in upstream changes that you haven't vetted is to lock in at a specific container image release and to not have an Always image pull policy.

The documentation, is just for getting started with kube-router and to give users some helpful examples, it does not cover every possible combination of kube-router options, nor should it be construed to comment on the environment that you are deploying into. Some amount of decision making is require from the user to ensure that what they are deploying works correctly for their environment, cluster setup, risk profile, etc.

Definitely open to other ways that we could communicate this to users though. We didn't specifically announce it in slack, so that might be something that we could do. Previous announcement of version updates haven't gained any traction or feedback from the community so I haven't been bothering to make them with the last few releases. If we had posted an update in slack would it have helped you understand the changes to the project?

from kube-router.