Merge pull request #42554 from sftim/20230815_fix_release_blog_misleading_statement
Fix misleading v1.28 release announcementpull/42594/head
commit
f8673e1835
|
@ -26,13 +26,31 @@ Much like a garden, our release has ever-changing growth, challenges and opportu
|
|||
# What's New (Major Themes)
|
||||
|
||||
## Changes to supported skew between control plane and node versions
|
||||
This enables testing and expanding the supported skew between core node and control plane components by one version from n-2 to n-3, so that node components (kubelet and kube-proxy) for the oldest supported minor version work with control plane components (kube-apiserver, kube-scheduler, kube-controller-manager, cloud-controller-manager) for the newest supported minor version.
|
||||
|
||||
This is valuable for end users as control plane upgrade will be a little faster than node upgrade, which are almost always going to be the longer with running workloads.
|
||||
Kubernetes v1.28 expands the supported skew between core node and control plane
|
||||
components by one minor version, from _n-2_ to _n-3_, so that node components
|
||||
(kubelet and kube-proxy) for the oldest supported minor version work with
|
||||
control plane components (kube-apiserver, kube-scheduler, kube-controller-manager,
|
||||
cloud-controller-manager) for the newest supported minor version.
|
||||
|
||||
The Kubernetes yearly support period already makes annual upgrades possible. Users can upgrade to the latest patch versions to pick up security fixes and do 3 sequential minor version upgrades once a year to "catch up" to the latest supported minor version.
|
||||
Some cluster operators avoid node maintenance and especially changes to node
|
||||
behavior, because nodes are where the workloads run. For minor version upgrades
|
||||
to a kubelet, the supported process includes draining that node, and hence
|
||||
disruption to any Pods that had been executing there. For Kubernetes end users
|
||||
with very long running workloads, and where Pods should stay running wherever
|
||||
possible, reducing the time lost to node maintenance is a benefit.
|
||||
|
||||
However, since the tested/supported skew between nodes and control planes is currently limited to 2 versions, a 3-version upgrade would have to update nodes twice to stay within the supported skew.
|
||||
The Kubernetes yearly support period already made annual upgrades possible. Users can
|
||||
upgrade to the latest patch versions to pick up security fixes and do 3 sequential
|
||||
minor version upgrades once a year to "catch up" to the latest supported minor version.
|
||||
|
||||
Previously, to stay within the supported skew, a cluster operator planning an annual
|
||||
upgrade would have needed to upgrade their nodes twice (perhaps only hours apart). Now,
|
||||
with Kubernetes v1.28, you have the option of making a minor version upgrade to
|
||||
nodes just once in each calendar year and still staying within upstream support.
|
||||
|
||||
If you'd like to stay current and upgrade your clusters more often, that's
|
||||
fine and is still completely supported.
|
||||
|
||||
## Generally available: recovery from non-graceful node shutdown
|
||||
|
||||
|
|
Loading…
Reference in New Issue