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.
* 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.
Reference : https://www.youtube.com/watch?v=Utf-A4rODH8
0 comments:
Post a Comment