Replies: 1 comment
-
I generally work from this document: https://kubernetes.io/releases/version-skew-policy/ The biggest stumbling block I’ve had with this, internally at least, is deciding what is a reliable indicator of what the “cluster version” is.
There are a lot of edge cases; to a certain extent the cloud providers have it easy, as there is an external store that determines the “correct” desired version for the cluster, and they can just compare everything against that. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
k3s should consider implementing user protection mechanisms for Kubernetes upgrades. This could involve preventing users from directly jumping to major version changes or skipping necessary patches within a branch. Instead, forced sequential upgrades within branches and controlled transitions to major versions would promote smoother updates, mitigate potential regression risks, and guarantee system stability.
Open to debate but I'd vote we stdout which version the cluster-admin should be upgrading to - maybe leave in a --force flag for circumventing known issues and edge cases that pertain to particular clusters. If a user passes --force they're on their own and they should acknowledge that during this upgrade path. I also think if possible this should take into account historic installation methods - do we want to add protections for admins who initially installed the cluster with package managers vs. the installation script to stay within the same method for upgrades?
Beta Was this translation helpful? Give feedback.
All reactions