Kubernetes Cluster Upgrade Approaches and Post-Upgrade Tasks

the documentation for the version of Kubernetes that you plan to upgrade to. ## Upgrade approaches ### kubeadm {#upgrade-kubeadm} If your cluster was deployed using the `kubeadm` tool, refer to [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) for detailed information on how to upgrade the cluster. Once you have upgraded the cluster, remember to [install the latest version of `kubectl`](/docs/tasks/tools/). ### Manual deployments {{< caution >}} These steps do not account for third-party extensions such as network and storage plugins. {{< /caution >}} You should manually update the control plane following this sequence: - etcd (all instances) - kube-apiserver (all control plane hosts) - kube-controller-manager - kube-scheduler - cloud controller manager, if you use one At this point you should [install the latest version of `kubectl`](/docs/tasks/tools/). For each node in your cluster, [drain](/docs/tasks/administer-cluster/safely-drain-node/) that node and then either replace it with a new node that uses the {{< skew currentVersion >}} kubelet, or upgrade the kubelet on that node and bring the node back into service. {{< caution >}} Draining nodes before upgrading kubelet ensures that pods are re-admitted and containers are re-created, which may be necessary to resolve some security issues or other important bugs. {{</ caution >}} ### Other deployments {#upgrade-other} Refer to the documentation for your cluster deployment tool to learn the recommended set up steps for maintenance. ## Post-upgrade tasks ### Switch your cluster's storage API version The objects that are serialized into etcd for a cluster's internal representation of the Kubernetes resources active in the cluster are written using a particular version of the API. When the supported API changes, these objects may need to be rewritten in the newer API. Failure to do this will eventually result in resources that are no longer decodable or usable by the Kubernetes API server. For each affected object, fetch it using the latest supported API and then write it back also using the latest supported API. ### Update manifests Upgrading to a new Kubernetes version can provide new APIs. You can use `kubectl convert` command to convert manifests between different API versions. For example: ```shell kubectl convert -f pod.yaml --output-version v1 ``` The `kubectl` tool replaces the contents of `pod.yaml` with a manifest that sets `kind` to Pod (unchanged), but with a revised `apiVersion`. ### Device Plugins If your cluster is running device plugins and the node needs to be upgraded to a Kubernetes release with a newer device plugin API version, device plugins must be upgraded to support both version before the node is upgraded in order to guarantee that device allocations continue to complete successfully during the upgrade. Refer to [API compatibility](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#api-compatibility) and [Kubelet Device Manager API Versions](/docs/reference/node/device-plugin-api-versions/) for more details.

This section details different approaches to upgrading a Kubernetes cluster, depending on the deployment method: kubeadm, manual deployments, and other deployments. It provides specific instructions for upgrading control plane components manually and emphasizes draining nodes before upgrading kubelet. The document also covers post-upgrade tasks such as switching the cluster's storage API version, updating manifests using `kubectl convert` to adapt to new APIs, and upgrading device plugins to support newer API versions to ensure compatibility during the upgrade process.