Kubernetes v1.22 is a new feature release that adds over 50 improvements to the container orchestration platform. It also deprecates some capabilities and removes several APIs that have been superseded by replacement versions.

Here’s the lowdown on the most significant changes, starting with feature additions.

Server-Side Apply

Server-side Apply is now out of beta and generally available to all users. It’s a new mechanism to facilitate declarative resource management by users and cluster controllers.

Using Server-side Apply lets developers initiate resource changes by describing their intentions. The Kubernetes API server tracks changes to objects on a field-by-field basis. This “field management” system creates an ownership model where changes to a field added by another manager are automatically rejected. This prevents unintentionally reversing an operation started by another administrator.

Before Server-side Apply, the logic for identifying resource fields needing an update was part of the client-side kubectl apply command. Now this is elevated to the server, making it easier for controllers to apply their own configuration changes and facilitating the new access control capabilities. Changes to individual fields are recorded, not just the last state applied by each user.

Resources gain a new managedFields property when Server-side Apply with field management is active. It records each field, the data associated with it, and the time it was last updated. Manually editing managedFields is possible but strongly discouraged; it’s intended that only the Kubernetes API server will write these values.

Field management comes with support for conflict resolution and four different merge strategies. These let you tailor what happens when you try to edit a field that’s already been changed by another user. You can force apply the changes if necessary, transferring ownership to the incoming user.

External Credential Providers

External credential providers have also made the jump to stable. These let you use plugins to obtain credentials such as authentication tokens and TLS certificates from outside your cluster.

The feature lets you integrate Kubernetes access control with existing auth providers. Providers can authenticate you using OAuth2, LDAP, and SAML systems, so you can log in using your existing credentials for popular services.

Providers are implemented as plugins with a server-side component running in the cluster. This uses a special webhook to convert client-specific tokens into a format that the Kubernetes API server can interpret.

Running Without Root

High-security environments can gain increased protections by running the Kubernetes control plane as a non-root user. This is an alpha feature available for new cluster deployments. It helps mitigate the risks of a successful control plane compromise providing unlimited access to your host.

Launching a cluster as a non-root user requires you to enable the RootlessControlPlane feature gate. The control plane should then start without using sudo.

There’s similar support for running individual node-level components in a non-root environment. Kubelet, kube-proxy, and the container runtime now have this ability, helping you tighten your installation’s security.

API Removals

As a new minor release, v1.22 deprecates some existing capabilities in various Kubernetes components. These are mostly commands, flags, and some authentication and storage plugins. The affected features remain available but could be dropped in the future.

v1.22 also removes 12 previously deprecated APIs altogether. The removed APIs are all beta versions that have been superseded by newer stable alternatives.

The list includes the Ingress and IngressClass resources used to expose services with routing rules. The networking.k8s.io/v1beta1 versions of these objects should be replaced with their networking.k8s.io/v1 counterparts which remain supported.

Other removed APIs include the beta versions of APIService, CertificateSigningRequest, CustomResourceDefinition, and Lease, as well as several objects related to access control, storage, and scheduling. Review the migration guide before applying the upgrade to your cluster. You’ll need to change any resources using the removed APIs so they reference the new stable versions instead.

The next Kubernetes release to include removals will be v1.25. This is currently scheduled to remove four beta APIs: CronJob, EndpointSlice, Event, and PodDisruptionBudget.

Other Changes

This release lands many other minor additions and improvements including alpha support for swap memory, an improved experience when running Kubernetes on Windows, and the ability to use cgroups v2 to set memory allocation and isolation constraints on Pods.

Etcd, the configuration store used by the Kubernetes API server, has been bumped to v3.5.0. This improves logging capabilities with a new structured format and integrated file rotation. The project’s also delivered significant performance improvements to accelerate some common Kubernetes operations.

Several beta APIs are now marked as stable, including bound service account tokens and the PodDisruptionBudget object for specifying minimum concurrent replica counts. Kubernetes has gained the ability to warn you when you use a deprecated API too, making it easier to stay on the stable path. You’ll see these messages as you apply resources to your cluster.

New Release Cadence

v1.22 marks the start of a new regular release cadence for Kubernetes updates. Features will now land four times a year instead of three, creating a slightly longer development cycle that offers more chances to optimize and maintain release quality. It also offers more breathing room for cluster administrators who’ve now got an extra month between migrations.

In line with this schedule, Kubernetes v1.23 is expected to arrive in early December 2021. Each cycle has an estimated development time of 15 weeks. Regular patch updates will still be released on their existing monthly cadence, with critical bug fixes landing earlier when necessary.

Summary

Kubernetes v1.22 is a milestone update that sees the project move to a new release cadence. This will help cluster administrators plan for future upgrades, providing more migration time before the next one comes along.

In terms of new features, the most significant addition is arguably Server-side Apply. This simplifies the use of declarative resource configurations, lifting logic from kubectl into your cluster. This is expected to eventually replace the original kubectl apply implementation altogether.

Upgrading to v1.22 might require action if you’re still using any of the removed beta APIs. You should be able to replace them with their stable versions, although this might mean modifying your resources in some cases. Taking the time now to address the new deprecations in v1.22 will help you prepare for when v1.23 arrives, easing that release’s migration process.