Tech Kaizen: CRI-O(Container Runtime Interface based on Open Container Initiative)

CRI(Container Runtime Interface) consists of protocol buffers and gRPC API, and libraries, with additional specifications and tools under active development. Container Runtime is the software that, among other things, starts and stops containers. The most widely known container runtime is Docker.

CRI-O(Container Runtime Interface based on Open Container Initiative) is an open source community-driven container engine. The CRI-O container engine provides a stable, more secure, and performant platform for running Open Container Initiative (OCI) compatible runtimes. You can use the CRI-O container engine to launch containers and pods by engaging OCI-compliant runtimes like runc, the default OCI runtime, or Kata Containers.

CRI-O, formerly known as OCID, seeks to enable the open source Kubernetes Orchestrator to manage and launch containerized workloads without relying on a traditional container engine. cri-o provides a minimal set of tools and interfaces to download, extract, and manage images, maintain the container lifecycle, and provide monitoring and logging required to satisfy the CRI. It can use any OCI runtime that implements the OCI runtime spec and defaults to using runc. cri-o uses the configured runtime (runc by default) to create a sandbox container (pod), then uses the runtime again to create any containers within that pod.

Developers need container engines for creating and building container images and may prefer to use their own staging environments for local testing. Administrators and operations teams, however, might find the emerging Kubernetes stack(the orchestrator, CRI, and CRI-O) more suitable than pairing the orchestrator with standard container engines, for managing more complex production environments. The CRI, its contributors tell us, would allow Kubernetes to use use any container engine that is compliant with Open Container Initiative specifications, including OCI’s own runc engine, which that can do many of the things that a branded container engine like Docker or CoreOS’ rkt can do, including pull images from a registry, except that it won’t build images from a makefile.

cri-tools are CLI and validation tools for Kubelet Container Runtime Interface (CRI). crictl CLI tool can be used to create/start OCI complaint images.

runc is a CLI tool for spawning and running containers according to the OCI specification. runc is a CLI tool written primarily in go (with some C shims for things go cannot do) to run a container in linux according to the OCI specification. It is the most popular OCI runtime and is default used by containerd, and cri-o. For the most part, all runc does is configure the namespace and cgroups while spawning a process. This is all a container really is, a namespace and cgroups. runc depends on and tracks the runtime-spec repository, ensuring that runc and the OCI specification major versions stay in lockstep. This means that runc 1.0.0 implements the 1.0 version of the specification.

There are several competing Container Image formats (Docker, Appc, LXD), but the industry is moving forward with a standard governed under the Open Container Initiative – sometimes referred to simply as Open Containers or the OCI. The scope of the OCI includes a Container Image Format Specification, which defines the on-disk format for container images as well as the meta-data which defines things like hardware architecture and the operating system (Linux, Windows, etc). An industry wide container image format enables ecosystems of software to flourish – different individual contributors, projects, and vendors are able to build images and tooling, which are interoperable. Users want interoperability between tools for signing, scanning, building, running, moving and managing container images.

There are also several competing Container Engines including Docker, CRI-O, Railcar, RKT, LXC. These Container Engines take a Container Image and turn it into a Container (aka running processes). How this happens is governed by the scope of the OCI which includes a Container Runtime Specification and a Reference Runtime Implementation called RunC. This reference implementation is open source, governed by a community development model, and commonly used by many container engines to communicate with the host kernel when creating containers.

Tools:

1. crictl - For troubleshooting and working directly with CRI-O container engines

2. runc - For running container images

3. podman - For managing pods and container images (run, stop, start, ps, attach, exec, etc.) outside of the container engine

4. buildah - For building, pushing and signing container images

5. skopeo - For copying, inspecting, deleting, and signing images

ref:

CRI(container runtime interface) - https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md

CRI-O -

1. https://cri-o.io/

2. https://docs.openshift.com/container-platform/3.11/crio/crio_runtime.html

3. https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/cri-o_runtime/index

cri-o tutorial - https://github.com/kubernetes-sigs/cri-o/blob/master/tutorial.md

cri-o source code - https://github.com/kubernetes-sigs/cri-o

runc source code - https://thenewstack.io/cri-o-make-kubernetes-center-container-ecosystem/

cri-tools - https://github.com/kubernetes-sigs/cri-tools

Demystifying container runtimes - https://lwn.net/Articles/741897/

How Container Runtimes matter in Kubernetes - https://events.linuxfoundation.org/wp-content/uploads/2017/11/How-Container-Runtime-Matters-in-Kubernetes_-OSS-Kunal-Kushwaha.pdf