Kubernetes, an open-source extensile platform used to manage the workloads and services that are containerized, is known for its service discovery, load balancing, automated mounting of storage system, automatic roll outs, and bin packing, self-healing and sensitive configuration management.
The version of the Kubernetes to be run on the control plane nodes and the worker nodes is to be known while creating a novel Kubernetes cluster using the Container Engine. Kubernetes version is generally represented as x.y.z where, x refers to a major release, y to a minor release, and z to a patch release. The latest minor release of Kubernetes, the third and final release of 2020 with patch support for approximately one year, is v1.20; and can be downloaded from kubernetes.tar.gz, kubernetes-src.tar.gz and GitHub. Furthermore, the release incorporates 44 enhancements out of which 11 have become stable, 15 are on the process of entering beta, and 16 are in the process of moving to alpha.
The major changes in v1.20 since v1.19 are listed below:
The predominant feature observed in v1.20 is the graduation of volume container storage interface (CSI) snapshots operations, that initiate steps to develops applications for Kubernetes, to general availability (GA). This ensures easy triggering and incorporation of stable operations on every Kubernetes environment as well as associated storage providers.
Another noteworthy attribute of v1.20 is the debut of two beta features enabling users and admins using Kubernetes to have adequate control on the permissions concerning the volume mounted within a pod. Further, this release includes the graduation of kubectl, that directly provides support for debugging workflows, to beta.
The new release incorporates the benefit of troubleshooting the following debugs:
Further, the kubectl component holds a higher value than the kubectl plugin, ‘debug’. Thus, the users will need to replace the name of the debug plugin.
The following pre-requisites in terms of kube-apiserver, kube-controller manager, kube-scheduler, cloud-controller manager, kubelet and kube-proxy are to be ensured while upgrading to v1.20.
The upgrade of kube-apiserver to v1.20 must be ascertained before perceiving the upgrade of the kube-controller manager, kube-scheduler, and cloud-controller manager.
There are three pre-requisites to be considered while considering the upgrade of kube-proxy.
NOTE: The presence of version skew within the kube-apiserver components restricts the usage of kubelet, kube-controller manager, kube scheduler, cloud-controller manager and kubectl components.
Notably, the kubectl version is supported by the kube-apiserver version which is one version higher or one version lower than the prevailing version, i.e., if the version of the kube-apiserver is v1.20, kubectl is supported by v1.21, v1.20 and v1.19.
Absence of accelerator metrics (AcceleratorStats) in Summary API within kubelet.
Though, the changes seem a bit confusing, extended interaction with Kubernetes will ensure easiness in the long run.
The depreciation of Dockershim is a factor to be considered, in the long run as support for Docker will be ceased, its better to begin the planning for an upgrade.