Kubernetes 弃用 Docker 运行时，小甜甜变牛夫人影响了谁？

由于 Kubernetes 已成为当前云原生基础设施的事实标准，Kubernetes 在 1.20 版本后弃用 Docker 作为容器运行时引发了开发人员的关注。针对此事，网易数帆资深架构师、网易轻舟容器编排技术负责人王新勇给出了自己的见解。他认为，Kubernetes 移除 dockershim 的代码确实有其合理之处，同时此事对绝大多数开发者没有多大的影响。

• 从 Kubernetes 运行时提供统一的接口抽象这个角度来说，移除 dockershim 的代码确实有其合理之处，毕竟之前 dockershim 是由于历史原因，属于特例的。

• Kubernetes 编排是事实标准，容器的镜像格式遵守 OCI，所有之前的交付的构件，无论容器运行时怎样变化，都不会有影响。

• 容器平台提供商需要做一些适配、整合、测试等，需要提供 kubernetes 支持的容器运行时。也可以通过额外维护和引入一个新的不属于 kubernetes 项目的“dockershim”中间层来继续支持 docker 作为运行时。不过无论怎么做，绝大部分开发人员都是感知不到的。

Kubernetes 和 Docker 的关系

• Docker 最初只是一个容器引擎，应该是很多人进入容器领域时最早接触的东西，Docker 为普及 Linux 的容器技术做出了很大的贡献（虽然 Linux 容器上，LXC 更早，而且早期版本的 Docker 就是基于 LXC 实现的，但是 Docker 的最大创新就是提出了镜像的概念）。

• 在 2015 年，我们探索容器技术做蜂巢产品的时候，那时候很多人的理解里面，容器基本就是 Docker，Docker 就是容器。直到现在应该好多开发者还是这个认知。

• Kubernetes 是做容器编排的，本身跟最初 Docker 解决的问题领域是不冲突的，而且很多人都是从 Docker 入手才开始接触 Kubernetes 的。不过后来 Docker 也想做容器编排的事情，推出了 Docker Swarm，Docker Swarm 跟 Kubernetes 就构成了竞争的关系了。Docker 从此以后就不仅仅是运行时了，而是一整套容器技术栈了。现在 Docker 公司又推出了企业服务 Mirantis Kubernetes Engine，同时支持了 Kubernetes 和 Swarm 两种编排技术。

• 总结来看：

1. Docker 作为一定意义上早期容器技术的代名词，对于 Linux 容器，对于 kubernetes 的普及都起到了重要的作用，如果仅仅把 docker 当作一个容器运行时、镜像构建管理、本地开发测试容器工具套件的使用功能上来说（而且实际上，绝大部分开发者目前也就是这么干的），跟 kubernetes 做编排在功能上是相辅相成的，Docker 负责制作相关的软件构建并将其运行起来，Kubernetes 用来控制如何运行这些容器。

2. 如果说有竞争关系，其实随着 Docker 自己的编排引擎 Swarm 的影响力越来越弱，已经基本上丧失了竞争能力了。但是 Docker 公司推出的企业服务 Mirantis Kubernetetes Engine 确实是会跟 Google 的一些服务形成竞争关系。

Kubernetes 和 Docker 的场景与用户

• kubernetes 是一个大而全的容器编排引擎，不仅仅是运行容器，还有存储、网络，还提供了配置管理、服务发现等功能，而且还提供了非常灵活的扩展性。

• 而且现在基于 Kubernetes，已经构成了一整套生态，各种基于 Kubernetes 的解决方案很多，像微服务、Operator 化的中间件服务，service mesh，serverless 等，这些技术的引入可以达到提高运维自动化能力，提升开发效率等。因此，如果业务规模足够大，对于这些功能的需求比较迫切，是应该考虑使用 Kubernetes 的。例如网易数帆构建云 OS 支撑集团多元化业务，解决集群生命周期自动化管理、简化运行时环境运维、提升资源利用率等问题，Kubernetes 因其对云基础设施抽象、融合及生态的优势，成为我们的首选技术。

• 当然，强大的功能，灵活的可定制性自然而然就带来了使用上的复杂性，概念很多，配置参数很多，运维复杂。因此使用 kubernetes 相比较来说比较重，一般 DIY 一个 kubernetes 集群会比较复杂。所以大家实际在使用 Kubernetes 的时候，一般不会自己去 DIY Kubernetes。公有云上一般都是会去买托管的 K8S 服务，像 GKE，EKS 这种，对于 on-premise 情况下，在自己的 IDC 中，一般都会去购买像轻舟容器云这样的成熟的容器服务，这类服务提供了比较友好的使用方式，而且又将运维部署的复杂性对客户进行了屏蔽，可以让客户更好的使用 Kubernetes。

• 如果用户的业务部署比较简单，规模也较小，仅仅是为了使用容器做应用交付的便利，也没有其他的功能需求的话，仅仅通过 docker run/docker-compose 这种方式也能管得好的话，实际上是没必要非得引入 Kubernetes 这样非常重的编排组件的。反而直接仅仅使用 docker 会更轻量，也更好运维。比如 toB 的软件交付的情况，如果要部署的软件的部署架构比较简单的话，仅仅涉及少量几台机器，服务进程也不多的情况下，也有不少是直接使用 docker，而不引入 Kubernetes 的，比较轻量、简单。（当然我这里没有专门提 Docker Swarm，因为实际上我们使用 Docker Swarm 几乎没有，也不太有啥场景非 Docker Swarm 不可的，除非是早期遗留）

• 还有一个就是，使用 kubernetes 做编排引擎的情况下，实际开发者在日常的开发中，也会比较多地使用 Docker。

影响到哪些开发者和企业

• 对于一般的应用开发者来说，他们一般不会直接去面对 Kubernetes 的，因此，对于他们来说，可能压根就是无感知的 ，应用开发者甚至都不用知道他们的业务是用容器运行的。以轻舟容器云产品为例，我们提供了自动从代码编译构建，到运行上线的一条龙服务。应用开发者可以完全不知道容器，仅仅写好代码、提交代码，剩下的工作就交给轻舟容器云平台来进行了，容器云平台会按照预先定义的动作模板，完成接下来的所有工作。

• 对于整个基于 Kubernetes 生态的各个解决方案提供商来说，由于当前基于 Kubernetes 的编排是事实标准，容器的镜像格式又是都遵守 OCI 的，因此可以说所有的之前的交付的构件，无论容器运行时怎样变化，实际上都不会有啥影响。

• 对于容器平台提供商来说，可能需要一些适配和准备动作。就拿轻舟容器平台来说，我们是有比较好的准备的，实际上 Kubernetes 弃用 docker 从很早就开始讨论了，我们也一直有关注相关的信息。很早我们就开始关注和使用 Containerd 作为我们的容器运行时的一个选项了，目前也在网易内部的部分服务中进行了比较长时间的运行，后续也会在轻舟容器云平台中，提供相关的运行时多个选项 ，并逐步过渡到使用 containerd 作为运行时。

• 当然，即使按照当前的计划，到 kubernetes v1.22 版本，从 kubernetes 中删除了 dockershim 的支持，我们还可以通过将 dockershim 从 kubernetes 中抠出来，独立运行，作为 kubernetes 的 cri 到 docker api 的适配器，实现 kubernetes 继续支持 docker，从而保持之前的使用习惯。

迁移到 containerd、CRI-O 复杂度如何

参见上个问题，不同的开发人员感知上可能是不一样的。

对于一般应用开发，可能自己从来都不会去写一个 Dockerfile，那么对于他们来说是没有复杂度的。

对于之前可能需要跟 Docker 打交道的，往往也就是在开发调试阶段打交道，主要就是制作容器镜像和本地调试的。这种情况也是不需要进行迁移的，因为使用 Docker 制作的镜像，在其他运行时下同样能够正常跑。所有的工作流程都可以保持不变，没有迁移复杂度。

对于容器平台提供商来说，需要做的动作会大一点，需要做一些适配、整合、测试等，需要提供 kubernetes 支持的容器运行时。当然也可以通过额外维护和引入一个新的不属于 kubernetes 项目的“dockershim”中间层来继续支持 docker 作为运行时。不过无论怎么做，这个也是绝大部分开发人员都感知不到的。

当然，如果开发人员有兴趣的话，去学习一下 crictl 的操作也是可以的。有了使用 docker 的基础，上手还是很快的。

主要目的分析

docker 的 API 比较早，跟 CRI 不兼容，因此 kubernetes 中实现了 docker 到 CRI 的适配层 dockershim。根据 KEP，CRI 已经是容器运行时标准接口了，而 docker 作为容器运行时也不应该享受特权。同时去除掉 dockershim 支持，还能实现 kubernetes 与 docker 的解耦，减少 kubernetes 社区的负担，也能够使得 kubernetes 的运行时支持上可以有更好的演进和发展。

其实类似的事情，之前在 kubernetes 中已经发生过，那就是把很多厂商的 in-tree 的 Volume 相关的代码移除，而改为统一的基于 CSI 的实现，而 kubernetes 就专注于 CSI 就行了，不用再跟很多厂商的代码耦合了。

从 kubernetes 运行时提供统一的接口抽象这个角度来说，移除 dockershim 的代码确实有其合理之处，毕竟之前 dockershim 是由于历史原因，属于特例的。但是毕竟 Docker 是容器技术的“前辈”，昨天还是“小甜甜”，今天就成“牛夫人”了，还是有点唏嘘的。

Docker 会逐渐消亡吗

还是将 docker 项目和 docker 公司分开来看吧。

docker 项目的未来，我认为不会消亡，会使用 docker 命令可能会成为一个开发人员的必备技能，毕竟技术的惯性是很强大的，太多的开发人员直到现在可能还是认为容器就是 docker，docker 就是容器，日常开发过程中，docker 命令有比较好用，用得又比较熟，没有必要换。

docker 公司的处境和未来，我自己不懂公司经营，没法给出分析。不过就算 docker 公司处境不乐观，还是有强大的开源社区的，应该是不影响 docker 项目的。