What’s New in Kubernetes v1.22

Kubernetes v1.22 is out now! This release showcases how the Kubernetes community works collectively and collaboratively to solidify the Kubernetes platform as a maturing open source system that brings together balance and stability with agility and innovation. This release brings key changes and enhancements to security, management and stability.

Release Changes Focus On Balance

The Kubernetes release team thoughtfully addressed multiple imbalances that were magnified over the last few releases. This release implements a new policy to alleviate a work-life imbalance in the Kubernetes community. From the Kubernetes Release Cadence Change announcement:

• The first Kubernetes release of a calendar year should start at the second or third week of January to provide people more time for contributors coming back from the end of year holidays.
• The last Kubernetes release of a calendar year should be finished by the middle of December.
• A Kubernetes release cycle has a length of approximately 15 weeks.
• The week of KubeCon + CloudNativeCon is not considered a 'working week' for SIG Release. The Release Team will not hold meetings or make decisions in this period.
• An explicit SIG Release break of at least two weeks between each cycle will be enforced.

This change also leads to a better balance for the developers and consumers of Kubernetes. The result is a slower release cadence of 3 releases per year, versus the previous 4 releases per year which allows more time for features to mature prior to being included in a release. Larger organizations in the community will appreciate the additional time to test, install and upgrade releases and enhancements.

For users of the Red Hat OpenShift Container Platform distribution of Kubernetes, the release schedule is also changing to match the new Kubernetes cadence of 3 releases per year. The Red Hat OpenShift Container Platform Lifecycle Policy page will reflect any changes to support policies to match the longer release cycles.

API Removals Encourage Open Source Best Practices

In order to encourage APIs to move to stable (GA) more quickly, increase trust in API usage for production workloads, and meet the expectations of enterprise users that APIs are consistent from release to release, the Kubernetes community approved a new process beginning with Kubernetes v1.20. This means Kubernetes v1.22 is bringing a series of API removals that, while scary, are necessary for the good of the Kubernetes project. Beta APIs cannot be relied on to be stable and consistent and, with the new process in place, there is now motivation to complete work and move APIs to stable (GA).

These transitions will cause some immediate pain for Kubernetes consumers though will ultimately provide a more consistent experience and drive further innovation in the future for workloads that rely on these APIs.

The API and Feature Removals Blog contains a more comprehensive list, however, some of the key removals (and subsequent transition to GA) are:

• The beta CustomResourceDefinition API (apiextensions.k8s.io/v1beta1)
• Beta versions of the ValidatingWebhookConfiguration and MutatingWebhookConfiguration API (the admissionregistration.k8s.io/v1beta1 API versions)
• The beta CertificateSigningRequest API (certificates.k8s.io/v1beta1)

For users of the Red Hat OpenShift Container Platform distribution of Kubernetes, the Administrator console now issues alerts for deprecated APIs that are being used by workloads running on the platform. This will help development teams and administrators better plan for API transitions.

Another enhancement to the API Server that has been highly anticipated for this release is the Alpha release of API Server Tracing. Red Hat has been working in the upstream Kubernetes community to ultimately meet the goal of making Kubernetes self-driving. As Kubernetes clusters scale out and up and are running faster and larger enterprise workloads, it’s important to reduce time spent troubleshooting individual components.

The new API Server Tracing feature utilizes distributed tracing to track bugs and issues across distributed clusters to simplify troubleshooting. In the past, it has been difficult to trace which components are failing, leading to confusion and downtime.

Shifting To Secure By Default

The more popular Kubernetes becomes, the bigger of a target it is for those that would break in and try to take over. As such, Kubernetes continues to evolve to face the continuing threat of attackers online. This is a never ending battle, and while Red Hat has already baked many extra solutions into OpenShift and Red Hat Enterprise Linux (SELinux), it’s always our goal to push changes upstream, and to help build community-based solutions, rather than rely solely on our own implementations. Better security just makes everyone safer.

One important security enhancement that is exciting for the Kubernetes community is the replacement for PodSecurityPolicy: Pod Security Admission Control.

From KEP 2579:

Replace PodSecurityPolicy with a new built-in admission controller that enforces the Pod Security Standards.

• Policy enforcement is controlled at the namespace level through labels
• Policies can be applied in 3 modes. Multiple modes can apply to a single namespace.
• Enforcing: policy violations cause the pod to be rejected
• Audit: policy violations trigger an audit annotation, but are otherwise allowed
• Warning: policy violations trigger a user-facing warning, but are otherwise allowed
• An optional per-mode version label can be used to pin the policy to the version that shipped with a given Kubernetes minor version (e.g. v1.18)
• Dry-run of namespace updates is supported to test enforcing policy changes against existing pods.
• Policy exemptions can be statically configured based on (requesting) user, RuntimeClass, or namespace. A request meeting exemption criteria is ignored by the admission plugin.

PodSecurityPolicy was deprecated in Kubernetes v1.21 - and targeted for removal in Kubernetes v1.25 - in favor of an alternative mechanism that prevents privilege escalation and still enforces the Pod Security Standards. The CIS Kubernetes Benchmark recommends PodSecurityPolicies so this replacement is important in ensuring security standards are evolving to address the security requirements of the community.

For users of the Red Hat OpenShift Container Platform distribution of Kubernetes, Red Hat will continue to support Security Context Constraints and Red Hat Advanced Cluster Management’s Open Policy Agent Gatekeeper integration.

Other key security enhancements that are debuting as Alpha in this release are:

Running the Control Plane as Non-Root

​​This KEP proposes that the control-plane in kubeadm be run as non-root. If containers are running as root an escape from a container may result in the escalation to root in host. CVE-2019-5736 is an example of a container escape vulnerability that can be mitigated by running containers/pods as non-root.

Enable seccomp by default

Enable seccomp by default for all workloads running on Kubernetes to improve the default security of the overall system.

Workload Improvements Across Kubernetes

With Kubernetes becoming a more mature, stable orchestration platform, long awaited enhancements are landing in Kubernetes v1.22 - setting the stage for further innovations. Some of the most notable enhancements include support for cgroupsv2. Cgroupsv2, or Control Groups v2, brings a more simplified approach to managing computational resources along with resource limitations for rootless containers. With support for cgroupsv2, SIG Node is exploring how to take advantage of new settings cgroupsv2 exposes including the more forward looking Memory QoS enhancement. Cgroupsv2 support will also enable finer-grained control of swap memory, which now has alpha support in 1.22. Red Hat OpenShift Container Platform users can look forward to seeing downstream cgroupsv2 integration in 4.10 as a Tech Preview feature.

Another notable, anticipated feature is support for CSI plug-ins in Windows moving to stable (GA) release. This includes in-tree enhancements and new out-of-tree components, including csi-proxy, to support the CSI node plugins in Windows worker nodes. Downstream support is projected to be available in Red Hat OpenShift Container Platform in the 4.0.0 version of the Windows Operator for Red Hat OpenShift Container Platform 4.10.

Conclusions

The Kubernetes community is continually, and thoughtfully, maturing the orchestration platform to instill trust in a more secure, stable,  performant platform. By having a solid foundation, the community can focus on driving even further innovation. We’re excited to be involved with such a vibrant, welcoming community and look forward to collaborating on many more innovative enhancements!