kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update content/en/blog/_posts/2023-08-04-kubernetes-1.28-blog.md 

Co-authored-by: Tim Bannister <tim@scalefactory.com>
pull/42381/head
Brad McCoy 2023-08-10 20:22:48 +10:00 committed by GitHub
parent 4f60a5718c
commit d6cdb771e6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/en/blog/_posts/2023-08-04-kubernetes-1.28-blog.md
View File

@ -172,7 +172,7 @@ Node upgrades: v1.42 → v1.43
Node upgrades are inherently more disruptive than control plane upgrades to workloads, for several reasons:
Workloads can be designed to have no dependencies on the Kubernetes control plane, so Kubernetes control plane availability does not directly impact running pods
Workloads can be designed to have no dependencies on the Kubernetes control plane, so Kubernetes control plane availability does not directly impact running pods.
There can be many more nodes (hundreds to thousands) than control plane members (typically 1 or 3).
Every time nodes are upgraded to a new minor version, every pod running on those nodes must be drained/rescheduled. This is true for immutable nodes and mutable/bare-metal nodes. If all nodes are being upgraded, this means every pod in the cluster will be replaced at least once. Patch updates of kubelet / kube-proxy components can be done in place, so it is possible to pick up security fixes and patch updates less disruptively.