During the last few months, there have been changes in Kubernetes’ traditional tie-in to Docker and rkt as container runtimes. Kubernetes has released its Container Runtime Interface (CRI) API, and there is a parallel ongoing implementation called CRI-O which attempts to create a bridge between Kubernetes and OCI-compliant runtimes. This paves the way for Kubernetes to use any OCI compliant container runtime in a standard way.
Kubernetes relies on the underlying container runtime for container lifecycle control operations like pull, create, delete etc. The runtime is the actual container implementation that manages the namespace isolation and resource allocation at the operating system level. Earlier, Docker and rkt were both tightly integrated into the Kubernetes source code through non-public APIs. Adding another runtime was cumbersome and required tinkering with the source code with no guarantee of stability. The Container Runtime Interface (CRI), introduced as an alpha feature in Kubernetes 1.5, aims to change this. The CRI exposes a common interface that lets container runtimes plug in to the Kubernetes system, allowing users to run Kubernetes to orchestrate and scale their non-Docker and non-rkt infrastructure. The runtimes can also be container-based hypervisors like runv.
The Open Container Initiative (OCI), an industry forum formed to standardize container formats and runtimes, published the runtime-spec as a standard for container runtimes. Current implementations include runc, HyperHQ’s runv and one based on Intel’s Clear Containers. The CRI-O project, started by Project Atomic/RedHat and other contributors from the industry, implements the Kubernetes CRI API using OCI compliant runtimes. This means that any OCI-compliant runtime can be plugged into Kubernetes via the latter’s CRI API, instead of having to implement a CRI adapter for each of them.
The Kubernetes’ CRI has the following implementations as of now:
- CRI-O - OCI conformant runtimes
- rktlet - The rkt container runtime
- Frakti - A hypervisor-based container runtime
- Docker CRI shim - Support for Docker directly as a CRI adapter
Image Courtesy: http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html
In a Kubernetes deployment, the kubelet is the local agent on each host (or minion in Kubernetes parlance) that talks to the container runtime. With CRI, the kubelet would communicate with a CRI-shim over gRPC (an open source RPC framework), which front-ends calls to the actual runtime. The concept of a Pod, the smallest unit of deployment in Kubernetes, has been extended to a concept called PodSandbox, maintaining similar semantics. This might translate to a virtual machine for hypervisor-based runtimes and to Linux namespaces for runtimes like Docker.
