Skip to content

Commit

Permalink
docs: add k8s version skew policy notes
Browse files Browse the repository at this point in the history
  • Loading branch information
consideRatio committed May 7, 2024
1 parent 1ef4c7f commit 18956d8
Show file tree
Hide file tree
Showing 2 changed files with 22 additions and 0 deletions.
1 change: 1 addition & 0 deletions docs/howto/upgrade-cluster/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -50,5 +50,6 @@ some in shared clusters have been announced ahead of time.
:maxdepth: 1
:caption: Upgrading Kubernetes clusters
upgrade-disruptions.md
k8s-version-skew.md
aws.md
```
21 changes: 21 additions & 0 deletions docs/howto/upgrade-cluster/k8s-version-skew.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
(upgrade-cluster:k8s-version-skew)=
# About Kubernetes' version skew policy

When we upgrade our Kubernetes clusters, we upgrade the k8s control plane (k8s
api-server etc.), the cloud providers managed workloads (`calico-node` etc.),
and the k8s node's software (`kubelet` etc.). Since these upgrades aren't done
at the exact same time, there are known constraints on how the various versions
can _skew_ in relation to each other.

When we upgrade, we are practically constrained by [Kubernetes' version skew
policy] in the following ways:

1. Highly available clusters' control planes can only be upgraded one minor
version at the time (`api-server` requirement).

All of our new clusters and most of our old clusters are regional, so our
documentation assumes we need to respect this constraint.
2. Nodes' k8s version must not be newer than the control plane, and be at most
three minor versions older (`kubelet` requirement).

[Kubernetes' version skew policy]: https://kubernetes.io/releases/version-skew-policy/#supported-version-skew

0 comments on commit 18956d8

Please sign in to comment.