k8s_cri_oci

Posted on Edited on In ,

Introduction

CRI and OCI

  • The OCI or Open Containers Initiative is an organization that creates container standards. The OCI runtime spec defines the API of a low-level container runtime and the OCI image spec defines what a “Docker image” actually is.
  • The Kubernetes project has also defined a number of standards. Relevant for this article is the CRI: the Container Runtime Interface. This interface defines how Kubernetes talks with a high-level container runtime.

Companies involved

  • CRI-O and podman is created by RedHat for OpenShift, it’s open source now.
  • containerd and runc maintained by community
  • gVisor is developed by Google
  • Kata-runtime comes from Intel and Hyper.sh for security reason, it’s start special VM!!!!

Container Runtime

low level container runtime
An OCI runtime is relatively simple. You give it the root filesystem of the container and a json file describing core properties of the container, and the runtime spins up the container and connects it to an existing network using a pre-start hook.

At the moment, we have three main OCI runtimes or low-level container runtimes.

  • runc, which is the default for most tools such as Docker and Podman. This is based on the code initially donated by Docker.
  • kata-run from the “Kata Containers” project, which aims to provide much better security and isolation between containers by running each container in a lightweight VM. It’s a merge of the runv and Intel Clear Containers projects.
  • gVisor is created by Google. It provides better isolation by running each container in a tight security sandbox.

high-level container runtime

  • Actually creating the network of a container.
  • Managing container images.
  • Preparing the environment of a container.
  • Managing local/persistent storage.

There are also three main high-level container runtimes.

  • containerd is a CRI-compatible container runtime which was donated to the CNCF by Docker. It is currently the default in many Kubernetes distributions such ad Canonical’s Charmed Kubernetes. It supports all OCI-compliant runtimes and has a special shim for kata-run.

  • CRI-O is a bridge between Kubernetes and OCI-compliant runtimes created by Red Hat. It has the big advantage that it gets released in lock-step with Kubernetes itself. Each CRI-O version is compatible with the Kubernetes version that has the same version number. This runtime is the default in OpenShift.

  • Docker itself can also be used as a CIR-compatible container runtime using the docker-shim. However, many Kubernetes distributors are moving away from this solution, due to the added unnecessary complexity of Docker.

kubernetes CRI(leaded by Kubernetes[Google])

The CRI was released in December 2016 by Kubernetes (Container Runtime Interface). In order to avoid subsequent compatibility, Kubernetes attempted to support another container runtime project led by CoreOS, rkt, but needed to write a lot of compatible code, etc. Other runtimes have implemented maintenance work, so a single CRI interface has been released. Any runtime that supports CRI can be explicitly used as Kubernetes’ underlying runtime;, kubelet calls same API(CRI implemented by runtime) to manage container.

Default CRI history
CRI

containerd history

detail about containerd

OCI(leaded by Docker)

In 2015, Docker and other leaders in the container industry jointly founded the Open Container Initiative (OCI) (it is also a project under the Linux Foundation).

Two specifications are primarily used by OCI:

  • Runtime-spec: How to run the package when the container is running on the file system defined.
  • image-spec: How to create a package on a file system that can be run by OCI.

As an original work, Docker donated its own container image format and runtime (now runc) to OCI.

OCI has nothing related to Kubernetes, it defines the specification how to create images and start container.

K8s

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# If you don't specify a runtime, kubeadm automatically tries to detect an installed container runtime by scanning through a list of well known Unix domain sockets.

# Runtime	Path to Unix domain socket
# Docker	    /var/run/dockershim.sock
# containerd	/run/containerd/containerd.sock
# CRI-O	        /var/run/crio/crio.sock

# NOTE: If both Docker and containerd are detected, Docker takes precedence.
# If any other two or more runtimes are detected, kubeadm exits with an error.

# check runtime used by kubelet, check runtime parameter
$ ps -ef | grep kubelet 

# --container-runtime string     Default: `docker`
# The container runtime to use. Possible values: `docker`, `remote`.

# --container-runtime-endpoint string     Default: `unix:///var/run/dockershim.sock`
# possible values: '/run/containerd/containerd.sock', '/var/run/crio/crio.sock'

multiple runtime support

A k8s cluster can have multiple runetime!!!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: node.k8s.io/v1alpha1  # RuntimeClass is defined in the node.k8s.io API group
kind: RuntimeClass
metadata:
  name: myclass  # The name the RuntimeClass will be referenced by
  # RuntimeClass is a non-namespaced resource
spec:
  runtimeHandler: myconfiguration  # The name of the corresponding CRI configuration


apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ...

standalone container

docker is best choice for this, but this is another choice to try. why redhat deos not use docker for openshift

  • Use Podman managing pods and containers. It’s a CLI tool which is very similar to docker. It uses libpod which uses runc in backend and is fully compatible with “Docker Images”.
  • Use Buildah for building “Docker Images”. It supports building containers from DockerFiles, but you can also build them with simple shell scripts!
  • Use CRI-O for running containers with Kubernetes. If you want to debug pods and containers maintained by Kubernetes, you can use the crictl tool instead of the docker commands.

Note: Podman can’t be used as kubernetes runtime

Ref