What you might have missed in Kubernetes 1.22 release

Significant Changes

Server-Side Apply to GA

The server-side apply feature has graduated to general availability (GA) in Kubernetes v1.22. The new feature moves the logic of kubectl apply to the Kubernetes API server, which makes it easier for tools other than kubectl to manage Kubernetes resources. For example, the Kubernetes Terraform provider makes use of it with its kubernetes_manifest resource. It comes with a new field management method to prevent multiple tools and controllers making conflicting changes, and defines how resources should be managed as declarative configurations. So, if you’re changing the field test-key of a configmap test-cm in a kubectl apply, then the ownership of the field moves to the manager kubectl as follows: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-cm
  namespace: default
  managedFields:
  - manager: kubectl
    operation: Apply
    apiVersion: v1
    time: "2021-10-01T0:00:00Z"
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        f:test-key: {}
data:
  test-key: test-value

The server-side apply feature provides a more straightforward and declarative mechanism to follow changes to resources. If you’re developing a controller, this means you can simplify the resource update logic on your side, but you also need to resolve conflicts when multiple managers are acting on the same fields.

External Credential Providers

Kubernetes client credential plugins were a feature available in the previous releases, and it has now graduated to GA with Kubernetes v1.22. The providers make it possible to authenticate using external systems such as a Key Management System (KMS) or Hardware Security Module (HSM), or using third-party tools such as the AWS CLI to retrieve short-lived credentials for accessing the Kubernetes API. If you’re writing your own custom provider, you can check out the sample-exec-plugin to get started.

etcd Version 3

etcd is the database of Kubernetes where the state of each Kubernetes resource is stored. In Kubernetes v1.22, the etcd version is upgraded to 3.5.0, which provides better performance and more security features. If you’re using the same etcd instance or backup and recovery mechanisms, updating your clients to version 3 for compatibility is suggested.

cgroups V2 API

Control groups (cgroups) is the Linux kernel feature that makes the containerization of processes possible. It limits and isolates the resource usage (CPU, memory, disk, networking) of processes and makes them run separately. Kubernetes was using cgroups v1 API where QoS class for pods only applied on CPU resources. In Kubernetes v1.22, cgroups v2 API is an alpha feature to manage memory allocation and isolation. 

If you’re not into container runtime and memory management on the nodes, you won’t face any side effects. However, container lifetime and node availability will increase with the usage of cgroups V2 API.

Node System Swap 

The new version of Kubernetes comes with another alpha feature to make system administrators’ life easier: running nodes with swap memory. In the previous releases, you had to disable swap space in your Kubernetes nodes, whereas this new feature provides running nodes where swap is enabled. Furthermore, you can configure swaps on Linux servers with a portion of block storage as virtual memory. 

Although the feature seems like only a slight improvement, it makes installing Kubernetes and node management simpler and increases the operator experience. 

Default Seccomp Profiles

Another alpha feature of the v1.22 release is SeccompDefault. The new flag enables seccomp by default for all pods and creates a new layer of security to prevent 0-day vulnerabilities or Common Vulnerabilities and Exposures (CVE). When the flag is in use, security administrators of Kubernetes clusters will have fewer things to worry about. If you want to enhance the security of your clusters and try this new feature out, a tutorial on enabling and configuring seccomp profiles is already available in the Kubernetes documentation.

Rootless-Mode Kubelet

Running processes as root is always a security red flag, as faulty or misconfigured applications can exploit their root access. With this new feature, it’s now possible to run Kubelet, the agent that runs on each node, as a non-root user, which will make the clustersless vulnerable to attacks. 

Deprecated and Removed APIs

The Kubernetes API is a living system that evolves with every new feature. When the new features become alpha, beta, and finally GA, their endpoints are reorganised. In v1.22, many APIs have been removed from Kubernetes, as they have graduated to GA, and new stable APIs have been added. The following beta APIs have been removed:

• admissionregistration.k8s.io/v1beta1: ValidatingWebhookConfiguration and MutatingWebhookConfiguration

• apiextensions.k8s.io/v1beta1: CustomResourceDefinition

• apiregistration.k8s.io/v1beta1: APIService

• authentication.k8s.io/v1beta1: TokenReview

• authorization.k8s.io/v1beta1: SubjectAccessReview, LocalSubjectAccessReview, SelfSubjectAccessReview 

• certificates.k8s.io/v1beta1: CertificateSigningRequest

• coordination.k8s.io/v1beta1: Lease

• extensions/v1beta1: Ingress

• networking.k8s.io/v1beta1: Ingress

If you have one of the listed resources in your manifest files or Helm charts, you need to update their API versions. In addition, there may be structural changes in the resource definitions. Thus, a migration guide for each resource is available in the Kubernetes documentation, including each step you need to take. 

Conclusion

Kubernetes v1.22 comes with new features that are security-oriented and focused on increasing the user experience. This article focused on the significant changes you need to consider before upgrading to Kubernetes v1.22. For more details, you can have a look at the Kubernetes release notes and read through the changelog as well. 

This blog is written exclusively by the OpenCredo team. We do not accept external contributions.