Validate version skew policy compliance on cluster upgrades #923
Conversation
phase/validate_hosts.go
Outdated
| return nil | ||
| } | ||
|
|
||
| if !delta.Consecutive { |
There was a problem hiding this comment.
What does Consecutive mean here, X+1 minor version?
There was a problem hiding this comment.
1.29.3 => 1.30.0 ✅
1.29.3 => 1.31.0 ❌
1.29.3 => 2.0.0 ✅
1.29.3 => 2.1.0 ❌
...but
1.29.3 => 1.30.1 ❌ (this is probably too strict and should be allowed)
There was a problem hiding this comment.
Allowing jumps of minor+2 (1.29 => 1.31) would be ok by kube I suppose.
There was a problem hiding this comment.
Confused 🤷♂️
kubeadm docs state explicitly that upgrading more than one minor at a time is not supported.
It seems it's kube-apiserver, controller manager and schedular that do not support upgrades that skip minors.
In theory, workers could lag 3 minors behind but I don't see how that would happen with k0sctl unless you add previously unmanaged nodes and proceed to upgrade from 1.28 to 1.31.
Major upgrades are not supported at all, but I guess that is something for the far future.
There was a problem hiding this comment.
Essentially it boils down to what k0s supports.
|
It could make sense to wait for workers to get the new kube-proxy after control plane is upgraded before proceeding to upgrade them. |
kke
changed the title
kke
changed the title
kke
force-pushed
the
version-skew-validation
branch
from
ec260b7 to
ccd0855
Compare
Signed-off-by: Kimmo Lehto <klehto@mirantis.com>
Signed-off-by: Kimmo Lehto <klehto@mirantis.com>
kke
force-pushed
the
version-skew-validation
branch
from
ccd0855 to
5c47051
Compare
2 participants
#835
When upgrading, validate that the new version does not violate kube's version skew policy or upgrade path requirements.
Waits for kube-proxy new version roll-out after controller upgrades before starting worker upgrades.