近期，Kubernetes在其最新的Changelog中宣布，自Kubernetes 1.20之后将弃用Docker作为容器运行时。这一消息在云原生领域激起了不小的水花，在Rancher技术社区里许多小伙伴也对此进行了激烈的讨论。
Kubernetes为什么选择弃用Docker呢?我们需要先简单了解Dockershim。它是一个桥接服务，帮助Kubernetes与Docker进行通信，Kubelet 之前使用 dockershim 实现对 Docker 的 CRI 支持(Docker本身目前尚未实现CRI)。但时至今日，维护Dockershim已成为运维/开发人员的沉重负担。因此Kubernetes社区建议大家考虑使用包含 CRI 完整实现(兼容 v1alpha1 或 v1)的可用容器运行时。从而取消了对Docker作为容器运行时的支持。
不过大家不必过分担心，近期从Rancher社区里面搜集了一些大家比较关注的问题，下面一一为大家解答：
1、Kubernetes Kubelet 弃用了Docker作为容器运行时，有代替方案吗?
在Kubernetes集群中，容器运行时负责提取和运行容器镜像。Docker只是被普遍使用的容器运行时，在Docker被弃用之后，我们还有两个常见的选项：containerd 和 CRI-O。
Containerd 是一个工业级标准的容器运行时，它极为简单、健壮并且具备可移植性。Containerd 可以在宿主机中管理完整的容器生命周期。这是一个100%开源的软件，已于去年2月份从CNCF毕业。
去年年初，Rancher推出的轻量级Kubernetes发行版K3s已经使用containerd作为默认容器运行时。
containerd：https://github.com/containerd/containerd/
CRI-O是由Red Hat推出的一款容器运行时，旨在提供一种在OCI一致的运行时和Kubelet之间的集成方式。在文章后半部分我们将会进一步对比containerd和CRI-O的性能，为您在选择容器运行时的时候提供参考。
CRI-O：https://github.com/cri-o/cri-o
2、我仍然可以在Kubernetes 1.20中使用Docker吗?
是的，如果使用Docker作为运行时，在1.20中只会在Kubelet启动时打印一个警告日志。Kubernetes最早将在2021年末发布1.23版本中将dockershim移除。
3、我现有的Docker镜像仍然可以使用吗?
仍然可以使用。Docker生成的镜像实际上并不是特定于Docker的镜像，而是OCI(Open Container Initiative)镜像。无论你使用什么工具构建镜像，任何符合OCI标准的镜像在Kubernetes看来都是一样的。containerd和CRI-O都能够提取这些镜像并运行它们。所以您可以仍然使用Docker来构建容器镜像，并且可以继续在containerd和CRI-O上使用。
4、我应该使用哪个CRI实现?
这是一个比较复杂的问题，它取决于许多因素。如果您之前熟练使用Docker，那么迁移到containerd应该是一个相对容易的选择，并且containerd具有更好的性能和更低的成本。当然，您也可以探索CNCF领域中的其他项目，来选择更适合您的环境。
来源：https://kubernetes.io/blog/202 ... i-use
eBay对containerd和CRI-O进行了一组性能测试，包括创建、启动、停止和删除容器，以比较它们所耗的时间。如图所示，containerd在各个方面都表现良好，除了启动容器这项。从总用时来看，containerd的用时比cri-o要短。
以下数据来自eBay的分享：
Rancher，阿里云，AWS， Google，IBM和Microsoft作为初始成员，共同建设 containerd 社区。2017年3月，Docker 将 containerd 捐献给CNCF(云原生计算基金会)。containerd得到了快速的发展和广泛的支持。Docker引擎已经将containerd作为容器生命周期管理的基础，Kubernetes也在2018年5月，正式支持containerd作为容器运行时管理器。2019年2月，CNCF宣布containerd毕业，成为生产可用的项目，更加稳定。
5、Rancher 对 Containerd 的支持
Rancher 在轻量级Kubernetes发行版 K3s和 RKE2(2020年10月推出)中早已将 containerd 作为默认的容器运行时。相信在 Rancher 2.x 支持 Kubernetes 1.20+ 之后会将这些宝贵经验运用到新版本的Rancher 2.x 迭代中。
其实Kubernetes弃用Docker这一决定已经酝酿很长时间了，可能对于没有密切关注这个方面的工程师来说有些措手不及。但其实无需特别担心：如果你是Kubernetes的终端用户，这仅仅是一个后端容器运行时的更改，从使用方面来说几乎感觉不到区别;如果你是一名开发/运维人员，你依旧可以继续使用Docker来构建镜像，以相同的方式将镜像推送到Registry，并且将这些镜像部署到你的Kubernetes中;如果你是运行和操作集群的用户，你只需要将Docker切换成你需要的容器运行时即可。
