Last week, Kubernetes released version 1.21. The announcement comes just three months after the release of version 1.20. Version 1.21 consists of 51 enhancements, of which 13 enhancements are now stable, 16 are moving to beta, 20 enhancements will be alpha, and two features have been deprecated.
The major features of the latest version are listed below.
CronJobs Reaches General Availability
CronJob is a Kubernetes tool to run scheduled actions such as backups, report generation, etc. Previously known as ScheduledJobs, CronJob has been a beta feature since Kubernetes 1.8 (released in 2017).
For the first five years, CronJob ran on its first version. In v1, CronJob controller worked by performing a periodic poll and sweeping off all CronJob objects in a cluster. As a default, in v1, a single worker implementation would get all CronJobs every 10 seconds and iterate over each of them before syncing them to the desired state. This setting ran the risk of overloading the API server at scale.
CronJob controller v2 implements a queue that uses DelayingInterface to handle the scheduling. This method does not require a linear scan of all the CronJobs, rendering better performance. Further, this controller can be scaled by increasing the number of workers processing the CronJobs in parallel.
IPv4/IPv6 dual-stack support
IP addresses are consumable resources, but it is important to ensure they don’t get depleted. Kubernetes v1.21 gives dual-stack support, enabling both IPv4 and IPv6 addresses. Having dual-stack support enables native IPv6 routing to pods and services while also allowing the cluster to communicate with IPv4 addresses wherever needed. Dual-stack support mitigates scaling limitations for workloads.
The dual-stack on Kubernetes cluster offers the following features:
- Dual-stack Pod networking. In v1.21, the dual-stack networking has been graduated from alpha to beta and is enabled by default.
- Enable both IPv4 and IPv6 services
- Ability to Pod off-cluster egress routing through both IPv4 and IPv6 interfaces.
Immutable Secrets and ConfigMaps
Kubernetes Secrets lets the user store and manage sensitive information such as passwords. ConfigMap is an API object for storing configuration for other objects to use. Both Secrets and ConfigMaps separate the configuration of individual container instances from container images. This helps in reducing overhead and adds flexibility.
Generally, Secrets and ConfigMaps, by default, are set to mutable. It is usually beneficial for pods to consume changes. However, it becomes a problem if a bad configuration is pushed, which pods consume invariably. Kubernetes v1.21 gives the option to mark Secrets and ConfigMaps immutable to ensure the application configuration doesn’t change. This feature has now been graduated to stable in v1.21.
If a user needs to make a change, he/she would be required to create a new Secret and ConfigMap to consume that resource. Since controllers need not poll the API server to watch for changes, immutable resources also offer scaling benefits.
Graceful Node Shutdown
Graceful shutdown refers to preventing incoming requests from hitting the server before it shuts down. It is done to avoid problems during deploying, closing, and restarting the app.
In v1.21, Graceful Node Shutdown has graduated to beta. As per the Kubernetes, this is highly beneficial as it makes Kubelet aware of node shutdown and ‘gracefully’ end the pods that are scheduled to that node.
Persistent Volumes Health Monitor
Persistent Volumes is a storage piece in the cluster provisioned using Storage Classes. They are used in applications to get local and file-based storage. It helps users to migrate applications without re-writing storage backends.
Kubernetes v1.21 now allows PVs to be monitored for the health of the volume. Workloads can now react to the health state to protect it from unhealthy volume.
Kubernetes Build Maintenance
Kubernetes has always maintained multiple build systems, causing complexity for new and current contributors. Building on years of work, Kubernetes has simplified the build process, and standardised native Golang build tools.
Wrapping Up
Two other major changes include:
- Deprecation of PodSecurityPolicy. However, the PodSecurityPolicy feature will continue to be available till v1.25.
- Deprecation of PodSecurityPolicy. However, the PodSecurityPolicy feature will continue to be available till v1.25.
