2016年，Docker公司为容器技术标准化做出的重要贡献，将Docker引擎中Runtime组件containerd开源，相继AWS、微软、Google及IBM，表示加入支持该项目。一年后，Kubernetes开始支持Containerd，还推出了容器Runtime接口（Container Runtime Interface，CRI），让Kubernetes可以兼容不同的容器Runtime，近日Kubernetes宣布，将正式支持containerd，在正式环境中的Kubernetes集群，也可以执行containerd 1.1版。(只要版本号在1.1版后的Kubernetes，都能兼容containerd。)
原先支持containerd 1.0版时，Kubernetes的设计架构，Kubelet与containerd间，夹着cri-containerd，而该Daemon程序，会负责Kubelet传来的需求，并使用containerd，管理容器及容器镜像。虽然该机制比Docker设计的更为精简，不过Kubernetes认为，这样设计仍不利于开发者进行部署工作，也会带来不必要的信息传输成本。
现在支持containerd 1.1后，cri-containerd被重新设计结构，变成containerd CRI套件，不仅内建在containerd中，也预设启用。如此一来，Kubelet就能直接与containerd通话，
「让整合变得更稳定、有效率。」
这个翻新的架构，也改善了Kubernetes的效率，「包含Pod启动效率，以及Daemon程序资源使用效率。」Kubernetes也比较了使用Docker 18.03 CE版，和containerd 1.1版。相比使用Docker，使用containerd能改善Pod的启动延迟性（Startup Latency）。如果在单一集群内，开启105个Pod（目前单一集群可容纳的最大数量），「无论是CPU、内存的使用，containerd 1.1版都比Docker 18.03 CE版更好。」，例如runtime CPU使用量，containerd比Docker少了68.13％。
不过也有不少开发者好奇，这样是否代表，未来就不能在Kubernetes环境使用Docker引擎。Kubernetes表示，由于Docker引擎是构建在containerd之上，而下一个社区版Docker，也会整合containerd 1.1版。由于Kubelet、Docker引擎都会使用containerd这个组件，用户除了能受益于Kubernetes的功能、效率改进外，也能保留既有使用Docker引擎的应用。
文章参考：https://www.ithome.com.tw/news/123438
