Skip to main content
In this lesson you’ll learn the recommended process for upgrading a Kubernetes cluster (focusing on kubeadm-managed clusters). We’ll concentrate on the core control-plane components (kube-apiserver, kube-controller-manager, kube-scheduler) and node components (kubelet, kube-proxy). For production upgrades you should also consider external dependencies (etcd, CoreDNS) — see the References section. Why upgrade carefully?
  • Kubernetes supports only the most recent three minor releases. Plan upgrades so your cluster never falls outside the supported window.
  • Kubernetes components can run different versions during rolling upgrades, but they must follow the supported version skew policy.
Is it mandatory that all components share the same version? No. Control-plane and node components can run different minor versions as long as they respect Kubernetes’ supported version skew rules. Version skew rules (summary) Example:
  • If the API server is v1.10:
    • controller-manager and scheduler: v1.10 or v1.9
    • kubelet and kube-proxy: v1.10, v1.9, or v1.8
    • No component should be v1.11 (a higher version than the API server)
This permissible skew enables live, rolling upgrades: components can be upgraded one at a time. When should you upgrade? How do you upgrade? Upgrade steps depend on how the cluster was provisioned:
  • Managed Kubernetes (cloud provider): provider typically performs or automates upgrades via UI/API.
  • kubeadm-managed clusters: use kubeadm to plan and apply control-plane upgrades, then upgrade node packages.
  • Custom/manual installs: you must upgrade each component manually.
This article focuses on kubeadm-managed clusters. kubeadm basic commands
High-level upgrade flow You have a production cluster running version 1.10 and want to reach 1.13. The major phases are:
  1. Upgrade control plane (masters)
    • Upgrade kubeadm to the target minor version on the machine where you run the upgrade.
    • Run kubeadm upgrade apply to update API server, controller-manager, scheduler and cluster manifests.
    • Control-plane components are briefly restarted. During this window:
      • Existing workloads on worker nodes continue serving users.
      • Management operations (new API changes, scheduling, and controller actions) are unavailable until control plane recovers.
    • After control-plane upgrade, node kubelets may still report older versions until you upgrade them.
  2. Upgrade worker nodes
    • Strategies:
      • Upgrade all workers at once (downtime risk).
      • Rolling upgrade: drain, upgrade, uncordon each node sequentially (minimal downtime).
      • Blue/green: add new-version nodes, migrate workloads, remove old nodes.
Example diagram for strategy 3 (add new nodes, migrate workloads):
A slide titled "Strategy - 3" showing five stylized smartphone mockups (labeled v1.10 and v1.11) across the bottom, with three central phones sending upward arrows to a cluster of user icons, illustrating users receiving updates.
Using kubeadm to upgrade (example: 1.11 -> 1.13)
  1. Check available upgrades and preflight checks:
Sample (trimmed) output:
Always upgrade the kubeadm CLI binary first to the target minor version for each step (for example, upgrade kubeadm to v1.12.x before running kubeadm upgrade apply v1.12.x). After upgrading kubeadm, upgrade the control plane, then upgrade kubelet and kube-proxy on each node.
Important considerations (before you start)
Back up your cluster state (etcd backup) and read the release notes for each minor release you’ll cross. Some upgrades require manual steps for third-party components (e.g., etcd or CNI changes). Failing to back up or to follow release notes can cause irrecoverable outages.
Example: upgrading the control plane from 1.11 → 1.12
  1. Update kubeadm on the host used to perform the upgrade (usually a control-plane host):
  1. Apply the control-plane upgrade:
  1. Verify node versions (note: kubectl get nodes shows the kubelet versions reported by nodes):
Upgrading kubelet on a control-plane host (if kubelet runs there) kubeadm often installs kubelet on masters to host static pods for control-plane components. If kubelet is present, upgrade and restart it:
After restarting kubelet, you should see the updated kubelet version reported:
Upgrading worker nodes — rolling, one node at a time A safe pattern for zero- or minimal-downtime upgrades:
  1. Drain the node:
This evicts pods while respecting PodDisruptionBudgets and prevents new pods from being scheduled.
  1. On the drained node, update kubeadm and kubelet packages:
  1. Update the node’s kubelet configuration to match the control plane:
  1. Restart kubelet:
  1. Make the node schedulable again:
Notes:
  • Draining marks the node unschedulable; uncordoning marks it schedulable again. Pods will be scheduled according to cluster demand and scheduler decisions.
  • Repeat drain → upgrade → uncordon for each worker node sequentially.
Per-node example sequence:
Notes on kube-proxy and DaemonSets
  • If kube-proxy is deployed as a DaemonSet with image tags or manifests managed by cluster-level manifests, kubeadm may update the DaemonSet image during control-plane upgrades; verify after upgrade.
  • In other deployments, you may need to update kube-proxy manually.
Repeat minor-version upgrades After all nodes reach v1.12, if you plan to progress to v1.13 repeat:
  • Upgrade kubeadm on control-plane host(s) to v1.13.
  • Run kubeadm upgrade apply v1.13.x to update the control plane.
  • Upgrade kubelet packages on each node (one at a time) and adjust kube-proxy if required.
Quick checklist before each minor-step upgrade Summary
  • Upgrade one minor version at a time (e.g., 1.10 → 1.11 → 1.12).
  • Upgrade kubeadm first on the host where you run the upgrade, then run kubeadm upgrade apply for the control plane.
  • kubeadm upgrades control plane components and manifests; it does not upgrade the kubelet binary on nodes — upgrade kubelet packages on each node and restart kubelet.
  • Use kubectl drain and kubectl uncordon to perform rolling upgrades on worker nodes with minimal disruption.
  • Always back up cluster state and read release notes for intermediate releases.
Links and References That’s it for this lesson. A practice lab is available where you can follow these steps to upgrade a live kubeadm cluster while keeping user workloads running.

Watch Video