Skip to content

5.2 Kubernetes Releases & Cluster Upgrade

1️⃣ Kubernetes Releases

Check Cluster Version

kubectl get nodes

Example output:

  • controlplane → v1.33.0
  • worker nodes → v1.33.0

Note

Kubernetes follows Semantic Versioning: vMAJOR.MINOR.PATCH

Version Structure Explained

Example: v1.33.0

  • Major (1) → Rare architectural changes
  • Minor (33) → New features & enhancements
  • Patch (0) → Bug fixes & security updates

Abstract

Minor releases introduce features.
Patch releases improve stability and security.

Release Lifecycle (Alpha → Beta → Stable)

Alpha

  • Experimental
  • Disabled by default
  • Requires feature flag
  • Not production ready

Beta

  • Feature complete
  • Enabled by default
  • Suitable for controlled environments

Stable (GA)

Warning

Never enable Alpha features in production clusters.

Support Policy (Very Important)

Kubernetes supports only the latest 3 minor versions.

Example:

If latest = 1.13
Supported = 1.13, 1.12, 1.11

Older versions become unsupported (EOL).

Danger

Running unsupported versions exposes clusters to security and stability risks.

Component Versioning Overview

Cluster version primarily reflects the control plane version.

Core components:

  • kube-apiserver
  • kube-scheduler
  • controller-manager
  • kubelet
  • kube-proxy
  • kubectl

Independent components:

  • etcd
  • CoreDNS

Note

Always verify compatible etcd and CoreDNS versions in release notes.

2️⃣ Version Skew Policy (Upgrade Safety Rule)

Kubernetes allows limited version differences between components to enable live upgrades.

If kube-apiserver = version X:

  • controller-manager → X or X-1
  • kube-scheduler → X or X-1
  • kubelet → X-1 or X-2
  • kube-proxy → X-1 or X-2
  • kubectl → X-1, X, or X+1

Warning

No core component (except kubectl) can be higher than kube-apiserver.

Success

Version skew makes rolling upgrades possible without downtime.

3️⃣ Cluster Upgrade Strategy (Production)

Core Principles

Golden Rules

  • Upgrade one minor version at a time
  • Upgrade control plane first
  • Upgrade worker nodes next
  • Backup etcd before upgrading
  • Read release notes carefully

Tip

Correct upgrade path: 1.11 → 1.12 → 1.13
Never skip minor versions.

What Happens During Control Plane Upgrade?

  • API server briefly unavailable
  • Worker nodes continue serving workloads
  • Applications stay online
  • No new deployments during upgrade window

Note

If a pod crashes during control plane downtime, it will not auto-heal until control plane is restored.

4️⃣ Worker Node Upgrade Approaches

❌ All Nodes at Once

  • All workers upgraded together
  • All workloads stop
  • Downtime occurs

Danger

Not acceptable for production environments.

Upgrade one node at a time:

  1. Drain node
  2. Upgrade node
  3. Restart kubelet
  4. Uncordon node
  5. Repeat

Workloads shift automatically to other nodes.

Success

Enables zero-downtime upgrades when replicas are configured properly.

✅ Blue/Green Node Replacement

  • Add new nodes with new version
  • Migrate workloads
  • Remove old nodes

Best suited for cloud environments with autoscaling.

5️⃣ Kubeadm Upgrade Workflow

Step 1 — Backup etcd

Always take a snapshot before upgrading.

Step 2 — Upgrade kubeadm

apt-get update
apt-get install -y kubeadm=<target-version>

Step 3 — Review Upgrade Plan

kubeadm upgrade plan

This shows:

  • Current cluster version
  • Target version
  • Component compatibility

Step 4 — Upgrade Control Plane

kubeadm upgrade apply v1.xx.x

Step 5 — Upgrade kubelet (Control Plane Node)

apt-get install -y kubelet=<target-version>
systemctl restart kubelet

Verify:

kubectl get nodes

Step 6 — Upgrade Worker Nodes (Rolling)

Drain:

kubectl drain <node> --ignore-daemonsets --delete-emptydir-data

Upgrade:

apt-get install -y kubeadm=<target-version>
apt-get install -y kubelet=<target-version>
kubeadm upgrade node
systemctl restart kubelet

Uncordon:

kubectl uncordon <node>

Repeat per node.

6️⃣ Production Best Practices

Recommended Practices

  • Stay within supported versions
  • Apply patch updates regularly
  • Maintain N+1 cluster capacity
  • Use PodDisruptionBudgets
  • Monitor deprecated APIs
  • Validate addons compatibility
  • Test upgrades in staging first
  • Monitor cluster health throughout upgrade

7️⃣ Production Do & Don’t

✅ DO

Tip

  • Upgrade sequentially
  • Validate after each phase
  • Maintain rollback plan
  • Monitor logs and metrics
  • Document upgrade runbook

❌ DON’T

Danger

  • Don’t skip minor versions
  • Don’t upgrade all nodes at once
  • Don’t ignore version skew rules
  • Don’t enable Alpha features in production
  • Don’t upgrade without etcd backup

8️⃣ Complete Upgrade Flow (Quick View)

Abstract

  1. Check version
  2. Verify support window
  3. Backup etcd
  4. Upgrade kubeadm
  5. kubeadm upgrade plan
  6. kubeadm upgrade apply
  7. Upgrade kubelet
  8. Rolling upgrade workers
  9. Validate workloads

🎯 Interview / Exam Memory

Question

  • Semantic versioning: Major.Minor.Patch
  • Only last 3 minor versions supported
  • Upgrade one minor at a time
  • Control plane first
  • Respect version skew rules
  • Rolling worker upgrades

Final Production Takeaway

Quote

Keep clusters within supported versions, upgrade sequentially, protect availability, and always plan upgrades — never rush them.