On August 4th 2021, Kubernetes (K8s) upstream announced the general availability of Kubernetes 1.22, the latest version of the most popular container orchestration platform. At Canonical, we actively track upstream releases to ensure our Kubernetes distributions align with the latest innovations that developers and businesses need for their cloud native use cases. Usually, we would announce the availability and support for the latest Kubernetes, and also highlight any exciting new features in Charmed Kubernetes and MicroK8s.

So why does this blog not read like a release announcement? This time, we wanted to try something different. How about having a look at the most exciting features from Kubernetes 1.22 and assessing how they address industry challenges? A few months ago, we published the Kubernetes and cloud native operations report 2021

(hereafter “the report”). A sample of 1200 respondents and 7 industry thought leaders helped us gather and analyse data on the usage, challenges, goals and aspirations that users and enterprises have for the new way of building and delivering software – the cloud native way. Let’s see how Kubernetes is addressing the needs of the general public.

Putting Kubernetes security first

If one thing is clear in this Kubernetes release, it’s the shift in gears when it comes to security. Three of the most significant new features address security concerns. Bingo!

A quick glance at the report and anyone could tell that security is primarily what keeps people awake at night: 46% argue that security should be the top consideration for DevOps engineers working with cloud native technologies. Similarly, with 56% and 49%, security is by and large the biggest concern with regards to building containers or implementing an edge strategy respectively.

So what are the new Kubernetes security features that help put developer minds at ease?

Cluster-wide seccomp profile

In Kubernetes 1.22, a default, cluster-wide seccomp profile feature graduates to alpha. Seccomp is a Linux kernel facility used to tie down processes to a very limited number of system calls. Before 1.22, Kubernetes did allow containers to be run using a seccomp profile, a feature that had been stable since 1.19, but was so far only opt-in. The fact that from now on this will be the default behaviour can prevent the exploitation of a multitude of CVE’s and zero-day vulnerabilities.

Rootless mode containers

Running containers as a non-root user is the number-one container security best practice. With Kubernetes 1.22, this concept is leveraged in full, allowing for the K8s control plane to run in the user space. Specifically, kubeadm can now be run as non-root if needed, by running the control plane with lower privileges. The rest of the Kubernetes node components can also be run experimentally as a non-root. This way, if a Kubernetes cluster is compromised, it will be significantly harder for attackers to attackcompromise the underlying infrastructure.

PodSecurity admission to replace PodSecurityPolicy

A new PodSecurity admission feature is introduced, intended as a replacement for PodSecurityPolicy, which was deprecated in Kubernetes 1.21. The PodSecurity admission controller enforces pod security standards at the level of namespaces – which, according to the report, are the de facto way to isolate applications in Kubernetes. The admission controller comes with three levels of enforcement severity: 

• Enforce – Policy violations will cause the pod to be rejected.
• Audit – Policy violations will trigger the addition of an audit annotation, but are otherwise allowed.
• Warn – Policy violations will trigger a user-facing warning, but are otherwise allowed.

Opening Windows to new worlds

“[W]hat people mean when they say ‘modern infrastructure’ – they’re not literally talking about doing something that has never been done before. They’re talking about the things that have been in production for the past 10 or 15 years. Kubernetes is today’s checkpoint on all the ‘modern patterns’”.

These are the words of Kelsey Hightower when asked to comment on the report data showing that 47% of respondents selected infrastructure modernisation as the second most important goal of their business. Another interesting data point is that incompatibility with legacy systems is the third most voted challenge of using Kubernetes. 

Microsoft Windows, an operating system on top of which countless organisations have built and run their software in the past, has yet to become a first-class citizen of the Kubernetes platform. But it looks like upstream has received the message, and now provides an enhanced user experience for building and running containers at scale on Windows.

Already available in Linux, privileged containers are now supported on Windows. They have direct host access and are quite useful for administration, security and monitoring purposes, although not suitable for all workloads. Additionally, as part of the overall Windows enhancements, a new developer toolset has been released with 1.22. These support multiple CNI providers and can run on multiple platforms. They also provide a way to test early-support Kubernetes features on Windows, by manually building the Windows kubelet and kube-proxy binaries. Finally, the CSI support for Windows, which was initially released as an alpha feature in Kubernetes 1.16, is now generally available.

Intent-based configuration

One of the pieces of technology pioneered by Canonical which is part of the CNCF landscape is the Charmed Operator Framework. This allows users to move from configuration management to application management by capturing business intent in a model. Looking at the report, we were excited to see that, although early in their K8s journey, most respondents were keen on trying out charmed operators. There is a lot to be done to improve the full lifecycle management of Kubernetes, and the adoption of the operator pattern is a solid bet in that regard. For now, Kubernetes is adding enhancements that allow users to configure clusters and deployments in a way that feels more intuitive. 

The general availability of Server-side Apply is certainly a push in that direction. This feature allows resources to be managed via declarative configurations. Changes to a resource can be tracked on a field-by-field basis, implementing a fine-grained permissions model. The intention is that Server-side Apply will eventually replace the kubectl apply command, as it provides a simpler mechanism for users and controllers to make changes to their configurations, by specifying their intent. The new logic is implemented in the Kubernetes API server in an attempt to fix most of the kubectl apply pitfalls – and also makes operations accessible directly from the K8s API.

Kubernetes 1.22 release wrap-up

As mentioned above, all of the upstream Kubernetes 1.22 features are available in Canonical Kubernetes. For the detailed list of features in our distributions, you can refer to the Charmed Kubernetes and MicroK8s release notes.

Whether you’re building Kubernetes clusters or deploying software on top of K8s, you can look to Canonical for support. Ubuntu is the operating system of choice for Kubernetes, and our comprehensive suite of technology enablers from bare metal to application management can be used as the building blocks for a neatly integrated cloud native stack.

Find us on Canonical Kubernetes channels

• ubuntu.com/kubernetes
• microk8s.io
• Chat with our team in #cdk and #microk8s on the Kubernetes Slack
• Find our Kubernetes forum on Discourse
• Follow us on Twitter – @canonical, @ubuntu