Container Runtime


Low-Level container run time:  At their core, low-level container runtimes are responsible for 
* setting up these namespaces and cgroups for containers, 
* allow for setting resource limits on the cgroup, 
* setting up a root filesystem, 
* chrooting the container's process to the root file system, and 
* then running commands inside those namespaces and cgroups
using the standard Linux cgcreate, cgset, cgexec, chroot and unshare commands.

Example
1. runC is reference implementation of OCI specification https://github.com/opencontainers/runtime-spec sudo runc run mycontainerid
2. lxc
3. lmctfy by Google. It has the ability to run sub-task containers under a pre-allocated set of resources on a server, and thus achieve more stringent SLOs than could be provided by the runtime itself. It supports container hierarchies that use cgroup hierarchies via the container names


High-level container run time (= container run time) supports: 
* image management, 
* image transport
* image unpack
* pass image to low-level container run time to run it. 
* provide daemon application
* gRPC API. gRPC is a modern, open source, high-performance remote procedure call (RPC) framework 
* Web API. 

Example
1. containerd from docker. ctr is command line client for containerd. https://github.com/docker/containerd/blob/master/design/architecture.md
2. rkt by CoreOS 
3. cri-o

Relations

* rkt is a runtime containing both high level runtime and low level runtime. 
containerd and cri-o are on top of runC
* containerd does not have support for building container image. 
* rkt can build docker image, however does not provide remote API. 
* docker provides everything. docker is not container runtime. It uses containerd as container runtime. 
* rkt can become alternative of docker. K8s can use rkt instead of docker. K8s can also use cri-o + runC instead of docker. 
* rkt supports pod natively. 


0 comments:

Post a Comment