From d44f6bb4e44800514ccd1e1ebfc394a5494277e5 Mon Sep 17 00:00:00 2001 From: Erik Sundell Date: Tue, 7 May 2024 15:57:40 +0200 Subject: [PATCH] docs: link out to a blog post about version skew --- docs/howto/upgrade-cluster/k8s-version-skew.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/howto/upgrade-cluster/k8s-version-skew.md b/docs/howto/upgrade-cluster/k8s-version-skew.md index ab7429a92b..008101e743 100644 --- a/docs/howto/upgrade-cluster/k8s-version-skew.md +++ b/docs/howto/upgrade-cluster/k8s-version-skew.md @@ -5,7 +5,7 @@ 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. +can [_skew_] in relation to each other. When we upgrade, we are practically constrained by [Kubernetes' version skew policy] in the following ways: @@ -18,4 +18,5 @@ policy] in the following ways: 2. Nodes' k8s version must not be newer than the control plane, and be at most three minor versions older (`kubelet` requirement). +[_skew_]: https://www.industrialempathy.com/posts/version-skew/ [Kubernetes' version skew policy]: https://kubernetes.io/releases/version-skew-policy/#supported-version-skew