由于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项目的。