In recent news, container orchestration system Kubernetes has released its version 1.20. This is the third (post v1.18 and v1.19) and the last release of Kubernetes this year, calling it the ‘Raddest Release’. The new version consists of 42 enhancements in all. Of these, 11 enhancements are stable, 15 are being moved to beta, and the remaining are entering alpha.

As per the developers’ blog, this version is one of the ‘most feature dense’ releases, which has more alpha than the stable enhancements. As per them, this shows that there still is tremendous scope for exploration in the cloud-native ecosystem.

In this article, we discuss some of the prominent features of this new stable release from Kubernetes.

Volume Snapshot Operations

In the Kubernetes v1.20, the volume snapshot operations that provide a standard way to trigger and incorporate volume snapshot operations has been made stable. Snapshots are instantaneous ‘pictures’ or reports of a server’s file system at a given point.

Users will now be able to use these volume snapshot operations in a portable manner on any Kubernetes environment or supported storage providers. This will also unlock the ability of Kubernetes to develop ‘advanced, enterprise-grade, storage administration features’, including application or cluster level backup solutions.

Kubernetes Command-Line Feature Graduates To Beta

From an alpha in the previous version, the kubectl debug feature has now become beta. As per this update, it goes from kubectl alpha debug to kubectl debug. This feature supports debugging workflows directly from kubectl, a Kubernetes command-line tool that allows users to run commands against its clusters. It also means that with this update, invocations using Kubectl alpha debug will now be deprecated and finally removed in the subsequent release, as and when that happens.

As per the new update, Kubectl Debug supports the following troubleshooting scenarios:

• Creating a copy of the pod (units of computing) that use a different container image or command to troubleshoot the problem of workload upon startup.
• Adding a new container with debugging tools or using an ephemeral container to troubleshoot distroless containers.
• It allows for troubleshooting on a node by creating a container that runs in the host namespaces with access to its filesystem.

PID Limits Graduated To General Availability

There are only a finite number of possible process IDs (PIDs) available for each pod and node. If any pod tends to use PIDs beyond what is allowed, the host machine faces starvation of resources, becoming unstable. PIDs are fundamental resources on Linux hosts, and administrators must ensure that the user pods don’t exhaust the PIDs that may result in the proper running of host daemons such as runtime, kubelet, etc. Further, it is also important to ensure that each of the pods has limited PIDs to have a limited impact on the other workloads on the node.

To ensure that, in v1.14, introduced in 2019, Kubernetes released a feature for the configuration of a kubelet to limit the number of PIDs a pod can consume. Now, after being enabled-by-default for a year, the PID limits have been graduated to general availability (GA) on both SupportNodePidsLimit (node-to-pod PID isolation) and SupportPodPidsLimit (ability to limit PIDs per pod).

Graceful Node Shutdown

Until now, upon shutting down of nodes, pods did not follow the expected termination lifecycle, which may cause issues for some workloads. The new feature GracefulNodeShutDown (currently in alpha) in V1.20 will enable the ‘graceful’ termination of pods during a system shutdown.

Dockershim Deprecation

The container runtime interface (CRI) shim for Docker, called that Dockershim is being deprecated in v1.20. Further, in the subsequent release, the support for Docker will also be deprecated. 

Interestingly, when the news of Docker deprecation came to the public domain just a few days before the formal release of v1.20, there was widespread havoc created in the developer community. This prompted the Kubernetes community to issue a clarification, where it mentioned Docker as an underlying runtime which was being deprecated in favour of Kubernetes-exclusive runtimes that use CRI. Further, the blog said, “This doesn’t mean the death of Docker. Docker is still a useful tool for building containers as the images that result from running Docker can still run in your Kubernetes cluster.”

Some of the other major updates include:

• Reimplementation of IPv4/IPv6 dual-stack to support dual-stack services.
• Fixing a default one-second value applied to exec probes for better timeout handling.
• Enabling API Priority and Fairness (APF) by default, by virtue of which, the incoming requests will be categorised.
• Features such as RuntimeClass, built-in API types defaults, support for CRI-ContainerD on Windows have been graduated to stable.