CRI-O 1.22 adds options against the metrics floods, adjusts certificate handling

cri-o 1.22

Following the latest Kubernetes release, the CRI-O team has updated its container runtime interface implementation to version 1.22. The project is mainly known for being the default container runtime in Red Hat’s enterprise Kubernetes distribution OpenShift — which isn’t a big surprise, given CRI-O’s Raleigh origins. However, its early compliance with Kubernetes’s Container Runtime Interface also helped to get it into Oracle and Suse products.

The latest release seems to focus mainly on smaller security and logging related enhancements. For instance, the team taught CRI-O to validate certificate dates for the TLS metrics endpoint, and to automatically reload metrics TLS certificate and key should any of them change. Version 1.22 also generates self-signed certificates and keys for the secure metrics endpoint should the provided ones be unavailable, so that CRI-O can be started without having certificates on disk. 

In order to make data collection a bit more manageable and not have CRI-O metrics flood a project’s memory, users can now disable the collection of certain metrics through a configuration option or via the --metrics-collectors CLI flag. The issue that inspired this addition is also the reason developers now have a crio_image_pulls_layer_size histogram metric available, which is meant to provide insights about all pulled image layer sizes.

Other than that CRI-O 1.22 records the container/sandbox ID and the corresponding process ID on container start, and can now work with the VM runtime type-specific runtime_config_path option. It also learned a couple of additional container and pod annotations to specify things like the default blockio class, or the RDT class of a container.

In terms of dependencies, crun and runc have been bumped to version 0.20.1 and 1.0.1 respectively in the static binary bundle. Other things to be aware of are the deprecation of the internal_wipe option, which is supposed to become unconditionally true in a future release, and a change to the way the resource for a workload is specified. Namely, pods that want to override workloads must be annotated with $prefix/$ctr_name = {"$resource_type": "$resource_value"} — a feature that is now marked experimental.

The release also comes with a long list of bug fixes that for example allow running containers using the default or no seccomp profile on machines and builds where seccomp is disabled, or let runtime VM created containers reach their completed state. Details are available in the release notes.