Take a cluster from Kubernetes 1.31 to 1.32 the way EKS expects: check upgrade insights, fix a removed API, upgrade the control plane, then the add-ons, then the nodes. Try doing it out of order or skipping a version, or press ▶ Guided tour.
EKS upgrades go one minor version at a time and in order. Upgrade insights scan the API server's audit logs for calls to APIs the next version removes, so you can fix clients and charts first. The control plane upgrade is done by EKS in place, replacing API servers without downtime, and can't be rolled back. Managed add-ons then move to the versions built for the new release; kube-proxy should match the control plane. Nodes come last: a managed node group launches new nodes from the new AMI, then cordons, drains (respecting PodDisruptionBudgets) and terminates old ones. Kubelets may lag the control plane by up to three minor versions but may never be newer. Each version has about 14 months of standard support, followed by paid extended support.