CRI-O 1.18 lands: Adds better insight, config handling for Kubeheads – but keep an eye on the defaults

CRI-O 1.18 lands: Adds better insight, config handling for Kubeheads – but keep an eye on the defaults

CRI-O, which pitches itself as an open-source replacement for Docker as the runtime for Kubernetes, is now available in version 1.18, improving on configuration and logging, among other things.

The release is the first of the community project – an implementation of the Kubernetes Container Runtime Interface based on the Open Container Initiative –  to support drop-in registries.conf configuration files and also provides ways to set a default environment for all containers and a default config path if needed. Users are meant to get more feedback about their input, thanks to a new verification feature that validates provided capabilities when CRI-O is started. 

To improve on traceability, increasingly a hot topic with cloud-natives, the project now adds log context to container stats and gRPC method names to log entries for better insight.

In terms of API changes, the project uses /var/run/$NS_NAMEns/$RAND_ID instead of /var/run/crio/ns/$RAND_ID/$NS_NAME when pinning namespaces, which is meant to improve compatibility with other providers’ networking plugins. Also, the CRI-O team has decided to stop running containers with NET_RAW and SYS_CHROOT by default, arguing in the release notes that “the majority of containers don’t need them” and “the fewer capabilities CRI-O gives out by default, the more secure it is by default”. 

However, there are, of course, teams running building tool buildah in their containers or using them to configure RPMs, which are only two of the examples that could fail with the new defaults and therefore require some manual updates to keep going. Same goes for devs still using a version of the Go language that is below 1.13, as support for these has been dropped from the project in order to be able to use it with Kubernetes 1.18. 

Apart from that, the CRI-O now does live reloads for the decryption_keys_path, as well as for configurations of seccomp and AppArmor profile options. It also learned to take local images into account, when pulling images with a localhost/-prefix.

A full list of added features and fixed bugs can be found in the CRI-O repository. Those who need help updating their configuration file to the latest version can make use of the crio config -m/–migrate option. 

CRI-O was started by Red Hat in 2016 and is currently a Cloud Native Computing Foundation incubating project. Contributing organisations include Intel, Suse, Hyper, and IBM, though Red Hat is still top of the list. 

The project is seen as an alternative to Docker and rkt, and supports runc and Kata Containers as container runtimes, though “any OCI-conformant runtime can be plugged in principle”. Being CRI-based, it’s also one of the runtimes supported by container orchestration tool Kubernetes. The project gained some public interest in 2019, when Red Hat decided to replace the Docker engine inside its OpenShift Container Platform with CRI-O. Another project using it as the default is OpenSuse’s Kubernetes distribution Kubic.