From 5ea10ed1ae94ae81f4fedc19f49d9744f00d344c Mon Sep 17 00:00:00 2001 From: Justin Santa Barbara Date: Mon, 20 Jan 2025 09:42:25 -0500 Subject: [PATCH] Update docs/tutorial/upgrading-kubernetes.md Co-authored-by: Dan Ports --- docs/tutorial/upgrading-kubernetes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorial/upgrading-kubernetes.md b/docs/tutorial/upgrading-kubernetes.md index 0d126bb47a..9e888e5a73 100644 --- a/docs/tutorial/upgrading-kubernetes.md +++ b/docs/tutorial/upgrading-kubernetes.md @@ -2,7 +2,7 @@ ## **NOTE for Kubernetes >1.31** -Kops' upgrade procedure has hostorically risked violating the [Kubelet version skew policy](https://kubernetes.io/releases/version-skew-policy/#kubelet). Between `kops update cluster --yes` and every kube-apiserver being rotated with `kops rolling-update cluster --yes`, newly launched nodes running new kubelet versions could be connecting to older `kube-apiserver` nodes. +Kops' upgrade procedure has historically risked violating the [Kubelet version skew policy](https://kubernetes.io/releases/version-skew-policy/#kubelet). After `kops update cluster --yes` completes and before every kube-apiserver is replaced with `kops rolling-update cluster --yes`, newly launched nodes running newer kubelet versions could be connecting to older `kube-apiserver` nodes. **Violating this policy when upgrading to Kubernetes 1.31 can cause newer kubelets to crash.** [This kubernetes issue](https://github.com/kubernetes/kubernetes/issues/127316) provides details though it was not addressed because the change does not actually violate the version skew policy, it merely breaks tooling that was already violating the policy.