> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Kubernetes Releases > Overview of Kubernetes release management, including checking cluster versions, semantic versioning, release cadence, component compatibility, release notes, and upgrade planning best practices. 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: ```bash theme={null} kubectl get nodes ``` Example output: ```bash theme={null} $ kubectl get nodes NAME STATUS ROLES AGE VERSION controlplane Ready control-plane 14m v1.33.0 node01 Ready 13m v1.33.0 ``` 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: | Part | Meaning | Notes | | - | - | - | | Major | Breaking changes | Very rare for Kubernetes; project has remained on 1.x numbering so far. | | Minor | New features and functionality | Typical cadence \~every 3 months; includes API additions and feature gates. | | Patch | Bug fixes and security patches | Frequent; used for critical fixes and CVE patches. | 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: | Stage | What it means | Typical behavior | | - | - | - | | Alpha | Early feature preview | Features are often disabled by default; experimental and may change or be removed. | | Beta | Wider testing | Better tested and often enabled by default; intended for broader validation. | | Stable / GA | Production-ready | Feature graduates from beta to stable and is fully supported. | You can view full release notes and historical versions on the official Kubernetes releases pages: * [Kubernetes Releases (website)](https://kubernetes.io/releases/) * [Kubernetes GitHub Releases](https://github.com/kubernetes/kubernetes/releases) 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/](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. ## Links and references * [Kubernetes Release Notes & Changelog](https://kubernetes.io/releases/) * [Kubernetes on GitHub — Releases](https://github.com/kubernetes/kubernetes/releases) * [Semantic Versioning Specification](https://semver.org/) * [Kubernetes Documentation](https://kubernetes.io/docs/) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.