器运行时是执行容器并在节点上管理容器镜像的软件，目前，最广为人知的容器运行时是Docker，但在生态系统中还有其他容器运行时软件，比如Rkt、Containerd和Lxd。Docker是现在于Kubernetes环境中使用的最常见的容器运行时，今天数人云给大家推荐一个Docker的组件——Containerd，它可能是更好的选择。
本文是由谷歌的软件工程师Lantao Liu和IBM的开源开发者Mike Brown基于自身相关实践，共同编写。
Kubernetes 1.5引入了一个名为容器运行时接口（CRI）的内部插件API，以方便地访问不同的容器运行时，CRI允许Kubernetes使用各种容器运行时，而不需要重新编译。从理论上说，Kubernetes可以使用任何实现CRI的容器运行时管理容器和容器镜像。
在过去的6个月中，来自Google、Docker、IBM、中兴和ZJU的工程师们一直在努力为CRI For Containerd，这个项目被称为cri-containerd，用户可以使用容器作为底层运行时运行Kubernetes集群，并且无需安装Docker。
Containerd
Containerd是一个兼容OCI的核心容器运行时，它被设计为嵌入到更大的系统当中，提供了在一个节点上执行容器和管理镜像的最小功能集，它是由Docker公司发起，并于2017年3月加入了CNCF，Docker引擎本身是建立在早期版本的容器之上，并且很快将更新到最新版本。
与Docker相比，Containerd的规模要小得多，提供了Golang客户端API，而且更专注于可嵌入，较小范围会导致一个更小的代码库，随着时间的推移，其更容器维护以及匹配Kubernetes的需求，如下图所示：
综上所述，从技术的角度来看，Containerd是Kubernetes的容器进行时比较好的选择。
Cri-Containerd
Cri-Containerd是对于容器的一个实现，它在与Kubelet和 Containerd相同的节点上运行，在Kuberntes和Containerd之间的分层中，Cri-Containerd处理来自Kubelet的所有国际服务请求，并使用Containerd管理容器和容器镜像，Cri-Containerd管理这些服务请求，在一定程度上是通过形成Containerd服务请求，同时添加足够的附加功能来去支持CRI需求。
与当前的Docker CRI实现（Dockershim）相比，Cri-Containerd消除了栈中的额外跳转，使堆栈更加稳定和高效。
体系结构
可以通过下面这个例子来演示当Kubele创建一个单一容器的时候，如何使用Cri-Containerd。
Kubelet通过国际运行时服务API调用了Cri-Containerd，用以创建一个Pod；
Cri-Containerd使用Containerd创建和启动一个特殊的暂停容器（沙箱容器），并将该容器放在Pod的Cgroups和名称空间中；
Containerd使用CNI配置了Pod的网络名称空间；
Kubelet随后通过国际服务API调用了“容器”，以拉出应用程序的容器的镜像；
如果镜像不存在于节点，则Cri-Containerd将进一步使用Containerd来拉出镜像；
然后，Kubelet通过“CRI”服务API调了“Cri-Containerd”通过拉取容器的镜像来创建和启动应用程序容器；
Cri-Containerd最终调用Containerd来创建应用程序容器，将其放入Pod的Cgroups和命名空间中，然后启动该容器的新应用程序容器。
在这些步骤之后，将创建并运行一个Pod及其相应的应用程序容器。
现阶段状态
Cri-Containerd V1.0.0-alpha.0是在2017年9月25日发布的。
其功能完备，所有的Kubernetes的特性都得到了支持。
所有的CRI validation test（CRI validation test是一种测试框架，用于验证是否符合Kubernetes的所有要求。地址：https://github.com/kubernetes/community/blob/master/contributors/devel/cri-validation.md）
所有的 Node e2e Test都已通过（用于测试Kubernetes节点级功能的测试框架如Managing Pods、Mounting Volumes等，地址：https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-node-tests.md）。
若想了解更多关于V1.0-Alpha的相关内容，请前往：https://github.com/kubernetes-incubator/cri-containerd/releases/tag/v1.0.0-alpha.0
延伸阅读
对于一个多节点集群安装程序，并使用能应用和Kubeadm启动步骤请参见：https://github.com/kubernetes-incubator/cri-containerd/blob/master/contrib/ansible/README.md
若想在Google云端从头创建一个集群，请参见：https://github.com/kelseyhightower/kubernetes-the-hard-way
对于一个自发布Tarball的自定义安装，请参见：https://github.com/kubernetes-incubator/cri-containerd/blob/master/docs/installation.md
对于在本地VM上安装LinuxKit，请参见：https://github.com/linuxkit/linuxkit/tree/master/projects/kubernetes
下一阶段
Containerd承诺，在下一阶段将主要改进稳定性和可用性方面的问题：
稳定性：
在Kubernetes的测试基础设施上建立一套完整的Kubernetes集成测试，包括Ubuntu、COS（容器化的OS 地址：https://cloud.google.com/container-optimized-os/docs/）等等。
积极解决用户报告的任何测试失败和其他问题。
可用性：
提高Crictl（https://github.com/kubernetes-incubator/cri-tools/blob/master/docs/crictl.md）的用户体验，Crictl是所有的CRI容器运行时的可移植命令行工具，这里的目标是使其易于用于调试和开发场景。
集成Kube-up.sh（https://kubernetes.io/docs/getting-started-guides/gce/）帮助用户使用Cri-Containerd来提高Kubernetes集群的生产质量。
改进文档。
预计在2017年底发布V1.0-Beta。
提供建议
Cri-Containerd是一个Kubernetes的孵化器项目，地址：ttps://github.com/kubernetes-incubator/cri-containerd。欢迎提供任何具有建设性的意见和建议，具体的使用入门指南请参见：https://github.com/kubernetes-incubator/cri-containerd#getting-started-for-developers
社区
Cri-Containerd是由Kubernetes Signode社区开发和维护的，如有相关的建议，可以加入社区：
Sig-Node社区网站：https://github.com/kubernetes/community/tree/master/sig-node
Slack:Kubernetes(kubernet.slack.com)的sig-节点通道：https://kubernetes.slack.com/
原文作者：Kubernetes
原文链接：http://blog.kubernetes.io/2017/11/containerd-container-runtime-options-kubernetes.html?utm_source=tuicool&utm_medium=referral
