Kubernetes releases follow a predictable semantic scheme, but the rules around how far components can diverge and how many minor versions you can jump in a single upgrade are strict. Violating them causes API incompatibilities, kubelet registration failures, and unsupported clusters that receive no security patches.Source: CKA Day 34
Semantic Versioning in Kubernetes
Kubernetes uses SemVer in the form v<major>.<minor>.<patch>:
Segment
Example
Cadence
What It Contains
Major
v1
Rare (never changed since launch)
Architectural breaking changes
Minor
.30
Every ~3–4 months
New features, deprecations, API additions
Patch
.2
Every few weeks
Bug fixes, CVE patches, minor enhancements
A full version looks like v1.30.2.
CKA note: Since Kubernetes launched, the major version has remained 1. The CKA exam and all current documentation assume v1.x. A hypothetical v2 would be a monumental ecosystem shift.
The Three-Version Support Window
The Kubernetes project supports only the latest three minor versions at any time. When v1.31 is released:
Supported:v1.29, v1.30, v1.31 — receive patches and security fixes.
Out of support:v1.28 and older — no new patches, no official bug-fix backports.
Running an out-of-support version does not break your cluster immediately, but it means you are exposed to known CVEs and compatibility issues with newer ecosystem tools (Helm, cert-manager, ingress controllers) that test only against supported Kubernetes versions.
Branch Model
Internally, the Kubernetes codebase maintains release branches for the three supported minors. New code is merged to master, then cherry-picked to the active release branches. When a branch ages out, it is archived and deleted. This is why patch releases for old minors stop appearing.
Version Skew Policy
Components within a single cluster are allowed to differ by at most one or two minor versions, depending on the component. The rule is always measured against the API server version.
Component
Maximum Skew
Rule
kube-apiserver
—
The reference version
kube-controller-manager, kube-scheduler
±1 minor
Must be at API server version or one minor behind
kubelet
±2 minors
Must be at API server version or two minors behind
Controller-manager and scheduler can be v1.30.x or v1.29.x.
Kubelets can be v1.30.x, v1.29.x, or v1.28.x.
kubectl can be v1.30.x or v1.29.x.
Exam trap: A kubelet at v1.27.x against a v1.30.x API server violates the ±2 skew rule and may fail to register or report node status.
Upgrade Path Rules
You cannot skip minor versions when upgrading a cluster.
Current
Target
Valid?
Required Path
v1.28.x
v1.29.x
Yes
Direct
v1.28.x
v1.30.x
No
v1.28 → v1.29 → v1.30
v1.26.x
v1.30.x
No
v1.26 → v1.27 → v1.28 → v1.29 → v1.30
v1.29.x
v1.30.x
Yes
Direct
The only exception is when an intermediate minor version is out of support and explicitly documented as skippable in the official upgrade notes. This is rare and never assumed in the CKA exam.
Why the Restriction Exists
Each minor version may introduce new API fields, change default behaviors, or deprecate old ones. The upgrade logic in kubeadm and the API server’s internal version negotiation are tested only for single-step transitions. Skipping a version risks:
etcd schema migrations being missed.
Admission controllers or webhook configurations referencing removed API versions.
kubelet flags or CRI behaviors that changed in the skipped version.
Component Upgrade Alignment
In practice, kubeadm upgrade apply keeps the control plane aligned to a single version. However, the video demonstrates that you must manually upgrade kubelet and kubectl on every node via the OS package manager (apt or yum). These are not upgraded by kubeadm because they run as systemd services and client binaries outside the containerized control plane.
After a cluster upgrade, verify alignment:
# Server versionkubectl version --short# Client versionkubectl version --client --short# Node kubelet versionskubectl get nodes -o wide
CKA Exam Patterns
Skip trap: If the exam scenario says “upgrade from v1.28 to v1.30,” the correct answer is to identify that this is impossible in one step and outline the two-step path.
Component skew: Know that kubelets may lag the API server by up to two versions, but control-plane components may lag by only one.
Support window: Recognize that a cluster on v1.27 when v1.30 is current is out of support and should be upgraded urgently.
Practical Practice
Exam-style hands-on tasks for this topic. Complete each task before reviewing the solution. Time yourself — CKA tasks average 5–7 minutes.
Task 1: Check Cluster Version
Check the current cluster version with kubectl version.
Requirements: Report both client and server versions.
Verification: Output shows server and client versions.
Solution:
kubectl version --shortkubectl version --client --short
Task 2: Verify Version Skew
Verify all nodes are within the supported version skew of the control plane.
Requirements: API server is the reference version. Kubelets may lag by up to 2 minors.
Verification:kubectl get nodes -o wideSolution:
kubectl version --short | grep Serverkubectl get nodes -o wide# Compare kubelet versions (node VERSION column) to API server version.# All kubelets must be at API server version or up to two minor versions behind.# Control plane components must be at API server version or one minor behind.