BT

Alternative Container Runtimes in Kubernetes

| by Hrishikesh Barua Follow 15 Followers on Apr 30, 2017. Estimated reading time: 2 minutes |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT