From: http://collabnix.com/building-multi-node-kubernetes-cluster-using-linuxkit-cri-containerd/
Let’s talk about CRI Vs CRI-Containerd…
Container Runtime Interface(a.ka. CRI) is a standard way to integrate Container Runtime with Kubernetes. It is new plugin interface for container runtimes. It is a plugin interface which enables kubelet to use a wide variety of container runtimes, without the need to recompile.Prior to the existence of CRI, container runtimes (e.g., docker, rkt ) were integrated with kubelet through implementing an internal, high-level interface in kubelet. Formerly known as OCID, CRI-O is strictly focused on OCI-compliant runtimes and container images.
让我们讨论下CRI和CRI-Containerd
容器运行时接口(CRI)是集成容器运行时和kerbernets的标准方式。对于容器运行时，它是新的插件接口。这个插件接口使得kubelet可以使用更广泛的容器运行时，而且不用重新编译。在CRI存在之前，容器运行时（例如docker，rkt）是通过在kubelet中实现一个内部的高层接口与kubelet集成在一起。 以前称为OCID，CRI-O要严格注意OCI运行时间和容器映像的兼容。
Last month, the new CRI-O version 1.2 got announced. This is a minor release of the v1.0.x cycle supporting Kubernetes 1.7.With CRI, Kubernetes can be container runtime-agnostic. Now this provides flexibility to the providers of container runtimes who don’t need to implement features that Kubernetes already provides. CRI-O allows you to run containers directly from Kubernetes – without any unnecessary code or tooling.
上个月，新的CRI-O版本1.2发布了。 这是支持Kubernetes 1.7的v1.0.x的次要版本。通过CRI，容器运行时对Kubernetes可以是不可知的。 现在，这为不需要实现Kubernetes已经提供的功能的容器运行时提供者提供了灵活性。 CRI-O允许您直接从Kubernetes运行容器 - 不需要任何不必要的代码或工具。
For those viewers who compare Docker Runtime Engine Vs CRI-O, here is an important note –
CRI-O is not really a competition to the docker project – in fact it shares the same OCI runC container runtime used by docker engine, the same image format, and allows for the use of docker build and related tooling. Through this new runtime, it is expected to bring developers more flexibility by adding other image builders and tooling in the future.
Please remember that CRI is not an interface for full-fledge, all inclusive container runtime.
对于那些比较Docker运行时引擎和CRI-O的观众来说，这里有一个重要的提示 -
CRI-O实际上并不是一个与Docker项目的竞争 - 事实上它共享Docker引擎使用的相同的OCI runC容器运行时，相同的图像格式，并且允许使用docker构建和相关工具。 通过这个新的运行时，期望通过在将来添加其他图像构建器和工具来为开发者带来更大的灵活性。请记住，CRI不是全面容器运行时的接口。
How does CRI-O workflow look like ?
When Kubernetes needs to run a container, it talks to CRI-O and the CRI-O daemon works with container runtime to start the container. When Kubernetes needs to stop the container, CRI-O handles that. Everything just works behind the scenes to manage Linux containers.
当Kubernetes需要运行容器时，它与CRI-O进行通信，而CRI-O守护进程与容器运行时一起工作来启动容器。 当Kubernetes需要停止容器时，CRI-O将处理该容器。 所有的东西都在后台管理Linux容器。
Kubelet is a node agent which has gRPC client which talks to gRPC server rightly called as shim. The shim then talks to container runtime. Today the default implementation is Docker Shim.Docker shim then talks to Docker daemon using the classical APIs. This works really well.
CRI consists of a
protocol buffers
and
gRPC API
, and
libraries
, with additional specifications and tools under active development.
Kubelet是一个具有gRPC客户端的节点代理，它与称为shim的gRPC服务器通讯。 然后Shim与容器运行时进行对话。 今天，默认实现是Docker Shim.Docker shim，然后使用传统的API与Docker守护进程交谈。 这流程工作得很好。
CRI由一个协议缓冲区和gRPC API以及库组成，并且正在开发中的附加规范和工具。
Introducing CRI-containerd
CRI-containerd is
containerd
based implementation of
CRI
. This project started in April 2017. In order to have Kubernetes consume containerd for its container runtime, containerd team implemented the
CRI interface
. CRI is responsible for distribution and the lifecycle of pods and containers running on a cluster.The scope of containerd 1.0 aligns with the requirement of CRI. In case you want to deep-dive into it, don’t miss out
this
link.
CRI-containerd是基于容器的CRI实现的
containerd
。 该项目于2017年4月开始。为了使Kubernetes为其容器运行时使用containerd，containerd团队实现了CRI接口。 CRI负责运行在集群上的POD和容器的分发和生命周期管理，containerd 1.0 符合CRI的要求。 如果您想深入研究，请不要错过这个链接。
Below is how CRI-containerd architecture look like:
下图是CRI-containerd架构
