The technical oversight committee (TOC) for Kubernetes announced today general availability of a 1.22 update that is likely to be remembered as much for what it gives as for what it takes away.
The latest update deprecates a large number of Kubernetes application programming interfaces (APIs) that IT teams which have already deployed Kubernetes clusters may be relying on. They include, for example, the beta versions of the CustomResourceDefinition API, the APIService API and the TokenReview API. Each of these APIs, along with others, are being superseded by more stable APIs that are now generally available with version 1.22 of Kubernetes.
Savitha Raghunathan, a senior platform engineer at MathWorks who was one of the leaders of the team of contributors to this update, says Kubernetes administrators will need to pay more attention to which versions of Kubernetes is running on any given cluster to make sure applications don’t inadvertently break when they upgrade. The TOC is now committed to only updating Kubernetes three times a year to minimize disruptions.
The TOC has been warning IT teams of its plan to deprecate these APIs since last month. It has similar plans for a forthcoming 1.25 release due out next year; for example, a PodSecurityPolicy API will be removed.
In the meantime, there are a total of 53 enhancements being made in this update. A total of 13 are capabilities that have graduated to stable. There are 24 enhancements that are moving to beta and 16 enhancements that are entering alpha. Three features have also been deprecated.
Major new capabilities that are now generally available include a server-side Apply field ownership and object merge algorithm running on the Kubernetes API server that allows both resources to be managed via configurations and objects to be created or modified declaratively.
Support for Kubernetes client credential plugins is now also stable, while the default etcd backend storage for Kubernetes has been updated to improve security, performance, monitoring and developer experience by adding support for features such as structured logging and built-in log rotation.
With this release, Windows continues to become more of an equal citizen in terms of running on a Kubernetes node. Support for the container storage interface (CSI) for Windows nodes is now generally available. Windows privileged containers, meanwhile, are now supported in alpha. A Linux server is still required to deploy a control plane for any cluster.
Most IT organizations rely on a curated version of Kubernetes that is provided to them by an IT vendor that decides when to support the latest release of upstream Kubernetes software made available by the TOC.
As the number of Kubernetes distributions curated by different vendors increases, there is no doubt that managing Kubernetes clusters is becoming more challenging. The most important thing to do is to read the documentation thoroughly before spinning up a Kubernetes cluster, says Raghunathan. Otherwise, IT teams can easily find themselves employing capabilities that might not ever make it past the alpha or beta stage.
Kubernetes, meanwhile, remains the most powerful IT platform to come down the proverbial IT pike in recent memory. It can, however, also be the most complex to manage.