Kubernetes Releases and Versions
In this tutorial, we will discuss about the various Kubernetes releases and versions.
So what do we know about API versions in Kubernetes so far? We know that when we install a Kubernetes cluster, we install a specific version of Kubernetes.
We can see that when we run the kubectl get nodes command.
$ kubectl get nodes NAME STATUS ROLES AGE VERSION node3 Ready <none> 5d1h v1.19.3-34+a56971609ff35a node2 Ready <none> 5d1h v1.19.3-34+a56971609ff35a node1 Ready <none> 5d2h v1.19.3-34+a56971609ff35a
In this case version is v1.19.3. In this tutorial we will see how Kubernetes project manages software releases.
About version
Let’s take a closer look at the version number. The Kubernetes release versions consists of 3 parts. The first is the major version (v1), followed by the minor version (19) and then the patch version (3).
While minor versions are released every few months with new features and functionalities, patches are released more often with critical bug fixes.
Just like many other popular applications out there, Kubernetes follows a standard software release versioning procedure.
Every few month it comes out with new features and functionalities through a minor release. The first major version was released in July of 2015. As of this tutorial the latest stable version is 1.19.3.
Apart from this you will see alpha and beta releases. All the bug fixes and improvements first go into an alpha release tagged alpha. In this release, the features are disabled by default and may be buggy.
Then from there they make their way to beta release where the code is well tested. The new features are enabled by default. And finally they make their way to the main stable release.
You can find all the releases in the releases page of the Kubernetes GitHub repository.
Download the Kubernetes.tar.gz file and extract it to find executables for all the Kubernetes components. The downloaded package when extracted has all the control plane components in it. All of them of the same version.
Please note that there are other components within the control plane that don’t have the same version numbers (ETCD cluster and Core DNS servers).
The ETCD cluster and Core DNS servers have their own versions as they are separate projects.
The release notes of each release provide information about the supported versions of externally dependent applications like ETCD and Core DNS etc.