cri-o VS runtime-spec

Kubernetes on the backend used to utilize docker for much of its container runtime solutions. One of the modular features of Kubernetes is the ability to utilize a Container Runtime Interface or CRI. The problem was that Docker didn't really meet the spec properly and they had to maintain a shim to translate properly. Instead users could utilize the popular containerd or cri-o runtimes. These follow the Open Container Initiative or OCI's guidelines on container formats.

Multiple container runtimes are supported, like conatinerd, cri-o, or other CRI compliant runtimes.

Install container runtime on all nodes. We will use cri-o.

Container Runtime Interface (CRI) is one of the important parts of the Kubernetes cluster. It is a plugin interface allowing kubelet to use different container runtimes. And recently CRI-O container runtime has been announced as a CNCF Graduated project. I thought of writing a blog on CRI-O and how to set up a single-node Kubernetes cluster with Kubeadm and CRI-O.

CRI-O: This is an open-source container runtime designed for use with Kubernetes. It is a lightweight and stable environment for containers. It also complies with the Kubernetes Container Runtime Interface (CRI), making it easy to integrate with Kubernetes.

With CRI-O I believe you can configure registry mirror locations…. Similar to this: https://github.com/cri-o/cri-o/issues/4941

Alternatives like Podman and CRI-O continue to gain traction and may replace Docker in various places. For example, Kubernetes used to use Docker, then moved to containerd, and now also support CRI-O. Generally speaking, the core features of "Docker" are such a commodity now that no one was the wiser when Kubernetes stopped using it.

will the site be available for the CKA exam? https://github.com/cri-o/cri-o/blob/main/install.md

The CRI-O container engine provides a stable, more secure, and performant platform for running Open Container Initiative (OCI) compatible runtimes. CRI-Os purpose is to be the container engine that implements the Kubernetes Container Runtime Interface (CRI) for OpenShift Container Platform and Kubernetes, replacing the Docker service. Source

> Well, no. When people say "containers", they always mean "Docker".

Not really/necessarily. https://github.com/opencontainers/runtime-spec

Otras iniciativas empezaron a surgir debido a la alta popularidad de los containers y debido a esto, en 2015 se crea OCI(Open Container Initiative) para definir un estandar para containers(runtimes e imagenes).

Theoretically there could be a lot of new options that pop up. There is an Open Container Initiative that has a Runtime Specification that can be implemented. youki is one example of an OCI-compliant container runtime.

Open Container Initiative Runtime Specification aims to specify the configuration, execution environment, and lifecycle of a container. Source

How I can generate oci bundle that can be run with systemd-nspawn? I've tried podman/buildah push, but generated directory/archive is not an oci bundle (https://github.com/opencontainers/runtime-spec/blob/main/bundle.md). I've tried podman image mount, but config.json file is nowhere to be found. It looks like I am missing something simple.

In more detail, runC and youki need to implement this specification. https://github.com/opencontainers/runtime-spec

A runtime specification that describes how to unpack and run a container. OCI maintains a reference implementation called runc. Both containerd and CRI-O use runc in the background to spawn containers.

The immediate goal of this project(youki) is to pass all the default tests of the runtime-spec that the opencontainers is making. Of course, this is for my own learning, but I believe Rust is one of the best languages to implement a container runtime.