Kubernetes Versioning & Version Skew

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
kubectl	±1 minor	Must be at API server version or one minor behind
kube-proxy	±1 minor	Must be at API server version or one minor behind
kubeadm	±1 minor	Must be at API server version or one minor behind
etcd	Varies	See etcd version policy

Practical Example

If the API server runs v1.30.2:

• 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 version
kubectl version --short
# Client version
kubectl version --client --short
# Node kubelet versions
kubectl 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.

See Also

• Kubernetes Cluster Upgrade — Step-by-step kubeadm commands that enforce these version rules
• Kubeadm Cluster Setup — Initial installation where version alignment is established
• Kubernetes Architecture — How API server, scheduler, controller-manager, and kubelet versions interact during runtime
• CKA Certification — Exam domain mapping: version skew and upgrade paths sit in Architecture, Installation & Configuration (~25%)
• CKA Day 34 — Step-By-Step Guide To Upgrade a Multi Node Kubernetes Cluster With Kubeadm

---

Tags: kubernetes cka versioning version-skew semver cluster-upgrade devops production