Allow to skip minor K8s versions when upgrading a worker group's K8s version
dguendisch opened this issue · comments
How to categorize this issue?
/area usability
/kind enhancement
What would you like to be added:
Allow to skip minor K8s versions when upgrading a worker group's K8s version and the resp. control plane K8s version allows for the targeted version skew. E.g. control plane is on v1.28, a worker group on v1.26 => please allow to upgrade the worker group directly to v1.28 without requiring a node rollout on v1.27 inbetween.
Why is this needed:
Control plane's K8s version can be upgraded without upgrading the worker groups immediately.
Due to the allowed K8s version skew policy a control plane could be more than one K8s minor version behind the control plane.
When upgrading the worker group, all nodes are rolled anyway, hence there is no node identity that needs to be preserved or might undergo potential conversions. Hence there is no requirement to upgrade K8s versions of a worker group (kubelet essentially) one minor version by one, but skipping a minor version should be totally fine.
Usecase: some scenarios do not consider the control plane upgrade as disruptive, but only eviction of running pods (e.g. because of node rolling). Some customers would prefer to upgrade the control plane twice, e.g. from v1.26 via v1.27 to v1.28 while keeping their worker group on v1.26, and then to finally roll their worker group only once, from v1.26 directly to v1.28.
(sure, the same could be achieved by using two different worker groups, it would be however simply more convenient to allow for such direct transitions).
/assign