本文转载自Rancher Labs
最近，Kubernetes 在最新发布的 Changelog 中宣布：自 Kubernetes 1.20 起，将逐步弃用 Docker 作为容器运行时。这个消息在云原生和 Kubernetes 社区引发了广泛关注，Rancher 技术社区中也有不少用户围绕这一变化展开了热烈讨论。
那么，Kubernetes 为什么要弃用 Docker 呢？这就需要先了解一下 Dockershim。Dockershim 是一个桥接组件，用于帮助 Kubernetes 与 Docker 通信，Kubelet 过去正是通过 dockershim 实现对 Docker 的 CRI 支持（而 Docker 本身目前并未原生实现 CRI）。但随着 Kubernetes 生态不断演进，持续维护 Dockershim 已经成为开发和运维团队的一项额外负担。因此，Kubernetes 社区建议用户优先选择那些已经完整实现 CRI（兼容 v1alpha1 或 v1）的容器运行时，从而停止继续直接支持 Docker 作为容器运行时。
不过大家也无需过度焦虑。我们从 Rancher 社区整理了一些最常见、最受关注的问题，接下来将逐一进行解答：
1、Kubernetes Kubelet 弃用了Docker作为容器运行时，有代替方案吗？
在 Kubernetes 集群中，容器运行时的职责是拉取并运行容器镜像。Docker 只是目前应用最广泛的容器运行时之一，在 Docker 被弃用之后，仍然有两个主流替代方案：containerd 和 CRI-O。
Containerd 是一个工业级标准的容器运行时，具备轻量、稳定、可移植和高可靠等特点。它能够在宿主机上管理完整的容器生命周期。这是一款 100% 开源的软件，并且已于去年 2 月正式从 CNCF 毕业。
早在去年年初，Rancher 推出的轻量级 Kubernetes 发行版 K3s 就已经将 containerd 作为默认容器运行时。
containerd：https://github.com/containerd/containerd/
CRI-O 是由 Red Hat 推出的一款 Kubernetes 容器运行时，目标是在符合 OCI 标准的运行时与 Kubelet 之间提供更紧密的集成方式。在本文后半部分，我们还会进一步对比 containerd 与 CRI-O 的性能表现，帮助您在选择 Kubernetes 容器运行时时获得更清晰的参考。
CRI-O：https://github.com/cri-o/cri-o
2、我仍然可以在Kubernetes 1.20中使用Docker吗？
可以。如果当前仍然使用 Docker 作为运行时，那么在 Kubernetes 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 的 Kubernetes 集群中。
4、我应该使用哪个CRI实现？
这个问题并没有统一答案，需要结合实际业务场景、团队经验、集群规模以及后续维护成本来综合判断。如果您过去已经非常熟悉 Docker，那么迁移到 containerd 往往会更顺畅一些，而且 containerd 在性能、资源占用和运维成本方面通常也更具优势。当然，您也可以结合 CNCF 生态中的其他项目，评估哪一种容器运行时更适合自身环境。
eBay 曾对 containerd 和 CRI-O 做过一组性能测试，测试项目包括容器的创建、启动、停止和删除等操作，以比较不同容器运行时在各环节的耗时表现。如下图所示，containerd 在大多数测试项中都表现不错，只有在容器启动这一项上不占明显优势。从整体耗时来看，containerd 的总用时比 cri-o 更短。
以下数据来自eBay的分享：
containerd和cri-o的性能对比
containerd和cri-o的综合对比
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+ 之后，这些在 containerd 方向上积累的实践经验，也将被进一步应用到后续 Rancher 2.x 版本迭代中。
事实上，Kubernetes 弃用 Docker 这一决定已经酝酿了很长时间。对于没有持续关注 Kubernetes 容器运行时变化的工程师来说，这一消息可能显得有些突然，但整体上并不需要过分担忧：如果你是Kubernetes的终端用户，这本质上只是底层容器运行时的变更，日常使用体验几乎不会受到影响；如果你是一名开发/运维人员，仍然可以继续使用 Docker 构建镜像，并按原有方式将镜像推送到镜像仓库 Registry，再部署到 Kubernetes 集群中；如果你是运行和操作集群的用户，你需要做的主要工作，就是将 Docker 切换为合适的 Kubernetes 容器运行时，例如 containerd 或 CRI-O。
