Skip to main content
In this lesson we walk through upgrading the Kubernetes control plane for an LKE (Linode Kubernetes Engine) cluster, what Linode automates for you, and what you must prepare to avoid unexpected downtime. Kubernetes upgrades move a cluster from one supported release to a newer one; downgrades are generally not supported. LKE exposes the supported versions or release tracks in the Cloud Manager. When a newer supported version is available, the Cloud Manager typically shows an upgrade button you can use to begin the process.
LKE automates most of the control plane orchestration (API server, scheduler, controller manager, and etcd) during an upgrade. Your main responsibility is to prepare the worker nodes and workloads so pod disruption is minimized.
On this cluster we are running Kubernetes version 1.22 and an upgrade to 1.23 is available.
A screenshot of a web UI showing a confirmation dialog to upgrade the Kubernetes cluster "test01" from version 1.22 to 1.23, with "Cancel" and "Upgrade Version" buttons. The page behind the dialog shows cluster/node details faded out.
What happens during an LKE upgrade
  • Control plane upgrade: LKE upgrades control plane components (API server, controller manager, scheduler, etcd) in a managed way.
  • Worker node recycle: After the control plane upgrade, LKE requires recycling (deleting and recreating) the worker nodes so they run the new kubelet/agent and rejoin the upgraded control plane.
  • Pod lifecycle: Because nodes are replaced, existing pods are evicted and then scheduled onto the new nodes. PersistentVolumes provisioned with external storage survive if they are independent of the node’s local disk.
Before you start the node recycle, the Cloud Manager prompts you to confirm the node recycling step. This dialog explicitly warns that local node storage will be erased.
A confirmation dialog on a Kubernetes cluster web UI asking "Recycle all nodes in cluster?" is shown. It warns that nodes and local storage will be deleted and offers "Cancel" and "Recycle All Nodes" buttons.
Recycling nodes will delete the worker nodes and any local storage on them (for example, hostPath volumes). PersistentVolumes backed by a proper external storage class (for example, block storage) will survive if they are independent of the node’s local disk.
Key implications for your workloads
  • Local storage loss: Any pods using hostPath or other node-local storage will lose data when their nodes are recycled.
  • Potential downtime: If Deployments/ReplicaSets do not have enough replicas or if critical services lack PodDisruptionBudget (PDB) resources, workloads may experience downtime during recycling.
  • Stateful workloads: StatefulSets and databases require proper PersistentVolumes and careful verification of StorageClass behavior before upgrading.
Recommended pre-upgrade checklist Example commands and tips
  • Export all resources:
  • Backup databases using the vendor-recommended method (for example, pg_dump for PostgreSQL).
  • Check PDBs:
  • Check PersistentVolume and StorageClass health:
Upgrade flow in the Cloud Manager
  1. Click the upgrade button on the cluster in the Cloud Manager.
  2. Confirm the control plane version change (e.g., 1.22 → 1.23).
  3. Confirm node recycling when prompted. LKE will then upgrade the control plane and start deleting and recreating worker nodes to match the new control plane version.
Final notes Upgrading from the Cloud Manager is operationally simple — click to upgrade, then confirm node recycling — but the planning work (replicas, PDBs, persistent storage, backups, and testing) is what prevents outages. Treat the Cloud Manager action as the last step after validation and backups. Links and references

Watch Video