Skip to main content
In this lesson we’ll cover how Kubernetes manages releases, how to check the version running in your cluster, what the version numbers mean, and where to find compatibility and release notes.

​
Inspect the cluster version

To see the Kubernetes version reported by each node, run:
Example output:
This shows the Kubernetes version that each node is running. Use this to confirm control plane and worker node versions before planning upgrades.

​
Semantic versioning (SemVer)

Kubernetes uses semantic versioning in the form vMAJOR.MINOR.PATCH. Each part has a clear purpose:
A dark infographic showing the semantic version "v1.33.0" with arrows labeling the three parts: MAJOR, MINOR (features, functionalities) and PATCH (bug fixes). The layout highlights how version numbers map to releases.

​
Release cadence and history

Kubernetes follows a regular release cadence:
  • Minor releases introduce new features and generally occur every few months.
  • Patch releases address bug fixes and security issues and are published more frequently.
  • The project began with v1.0 in July 2015, progressed through releases such as v1.20 (2020), and reached v1.33 in April 2025.
Kubernetes publishes pre-stable release stages to manage feature maturity: You can view full release notes and historical versions on the official Kubernetes releases pages:
A screenshot of a webpage showing the Kubernetes "Release History" with version details (1.33, 1.32) and a highlighted GitHub releases URL. The page includes a left sidebar menu and a small KodeKloud copyright at the bottom.

​
Release artifacts and component compatibility

When you download a release tarball (for example, kubernetes.tar.gz) and extract it, it typically contains control plane binaries built for that Kubernetes release, such as:
  • kube-apiserver
  • kube-controller-manager
  • kube-scheduler
  • kubectl (client utility)
Note: Several components used with Kubernetes are separate projects and maintain independent versioning. Examples include:
  • etcd cluster (storage backend)
  • CoreDNS (cluster DNS)
Supported versions for these components vary by Kubernetes release; compatibility details are published in each release’s notes.
Always consult the Kubernetes release notes for compatibility and upgrade instructions before performing an upgrade. See the official release listings: https://kubernetes.io/releases/

​
Planning upgrades and version management

  • Verify control plane and node versions with kubectl get nodes and kubectl version.
  • Consult the release notes for required component versions (etcd, CoreDNS) and any deprecations or API removals.
  • Follow documented upgrade paths: upgrade control plane components first, then worker nodes.
  • Test upgrades in a staging environment before applying to production.
Later sections will cover upgrade planning and best practices for managing component versions across control plane and nodes.
A simple diagram of Kubernetes components showing the control plane and node tools (kube-apiserver, controller-manager, kube-scheduler, kubelet, kube-proxy, kubectl) with version placeholders, plus etcd Cluster and CoreDNS versions. The components are arranged as colorful labeled boxes on a dark background.

Watch Video