Docker Container发展史

　　　　　　　　　　　　　　　　Docker Container发展史

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正杰

版权声明：原创作品，谢绝转载！否则将追究法律责任。

 

 

 

一.Docker的历史

1>.Docker技术开源，IT界的福音

　　2010年，几个大胡子年轻人在旧金山成立了一家做PaaS平台的公司，起名为"dotCloud"，该公司主要是基于PaaS平台为开发者或开发商提供技术服务。他们提供了对多种运行环境支持，如Java，Python，Ruby，Node.js等。

　　PaaS的概念虽好，但是由于认知、理念和技术的局限性，市场的接受度并不高，市场的规模也不够大。

　　除此之外，还有巨头不断进场搅局，IBM的蓝云，微软的Azure，Amazon的EC2，Google的GAE，VMware的Cloud Foundry等等，可谓强敌环伺，而且强敌都不差钱，想玩多久就玩多久，想玩多大玩多大。

　　在这种情况下，虽然dotCloud在2011年初拿到了1000万美元的融资，但依然举步维艰。这可能叫生不逢时吧，在PaaS领域有太多的巨头和大企业了。

　　有一天dotCloud的创始人Solomon Hykes就召集了公司核心开发人员，商量准备开源Docker技术。因此，在2013年3月，Docker正式以开源软件形式在pycon网站(见下图)首次发布了。正式由于这次开源，让容器领域焕发了第二春。

　　可以说，Docker是继Linux之后，最让人感到兴奋的系统层面的开源项目，据不完全统计，包括dotCloud公司，RedHat，IBM，Google，Cisco，亚马逊及国内华为等，都在为它贡献代码。

　　在美国，几乎所有的云计算厂商都在拥抱Docker这个生态圈。你知道的，很快Docker技术风靡全球，于是，dotCloud决定改名为Docker Inc(下面简称"Docker")，全身心投入到Docker的开发中。

　　更名后的Docker并于2014年8月，Docker宣布把平台即服务的业务dotCloud出售给位于德国柏林的平台即服务提供商cloudControl，自此dotCloud和Docker分道扬镳。
　　
　　参考链接:
　　　　https://us.pycon.org/2013/
　　　　https://www.oschina.net/news/57838/docker-dotcloud
　　　　《docker容器实战：原理、架构与应用》书籍

2>.容器编排工具Kubernetes诞生

　　Google多年来一直使用容器作为交付应用程序的一种重要方式，且运行有一款名为Borg(在一定程度上借鉴了Omega)的编排工具。当谷歌于2014年3月开始开发Kubernetes时，原本是希望在大规模场景下，将容器化编排管理能力带到大众手中。

　　这是一个很大的目标，McLuckie，Beda和队友Brendan Burns相信实现这一目标的唯一途径就是将技术开源并围绕其建立一个社区。事实证明他们的这个决定非常正确，但在当时没人能够100％确定。
　　
　　kubernetes很明智的选择当时最流行的容器，没错，就是Docker。Kubernetes对docker容器运行时的支持，迎来了大量的使用用户。
　　
　　Kubernetes于2014年6月6日首次发布。容器化才刚刚崭露头角，这主要得益于Docker，它是向开发人员推广容器化概念的功臣。但在当时，由于刚刚开始发展，因此尚不存在标准的容器管理方法。
　　
　　Kubernetes在以下几个方面堪称独一无二: 　　　　
　　　　(1)它基于谷歌多年来开发的现有技术，Kohn说:"尽管Kubernetes的代码是新的，但它背后的概念、工程和技术都是基于谷歌15年来建立Borg的经验(据说其前身是:"Omega"调度系统，两者各有优势!)"; 　　　　
　　　　(2)Kubernetes从一开始就是为开源而设计的。 

　　参考链接: 　　　　
　　　　https://blog.csdn.net/snail_ren/article/details/72636868 　　　　
　　　　https://blog.csdn.net/M2l0ZgSsVc7r69eFdTj/article/details/80681470

3>.Docker是一家有野心的公司-陆续推出Docker编排工具三剑客

　　Swarm:
　　　　早在2014年底，Docker公司就设计了容器集群的方案组合：Machine(可快速创建Docker运行环境) + Swarm + Compose(自定义文件格式以运行多容器应用程序的工具)。当然此时的Swarm局限性较大，比如：
　　　　　　(1)没有副本和负载均衡的概念，这导致服务无法高可用；
　　　　　　(2)当然也更不存在什么服务网络管理和跨节点数据存储这些东西；
　　　　　　(3)没有服务模型：集群中服务间关系和启动顺序编排也很复杂，于是就有了下面的SwarmKit的诞生；

　　SwarmKit:
　　　　在2016年2月，Docker公司开始了一个名叫SwarmKit的项目。而恰在Docker 1.12 RC之前的一段时间，Docker发布了Swarmkit，这是一个独立的、开源的容器编排项目。
　　　　SwarmKit不同于一开始的经典Swarm，它从一开始就重新设计了一套独立的API和模型体系，并且采用独立的客户端命令行工具"swarmctl"。和上面的经典Swarm模型相比，它加入了如下特性：
　　　　　　(1)重新设计的一套独立的API和模型体系;
　　　　　　(2)使用了自己的CLI(swarmd命令负责管理，swarmctl命令用于控制);
　　　　　　(3)节点管理、服务模型更加自然，提供编排和调度服务;
　　　　　　(4)将过去Swarm依赖的外部集群一致性存储组件Etcd的核心部分内置化;
　　　　　　(5)然而此时的SwarmKit并没有提供诸如服务发现、负载均衡和路由等功能。尽管如此，SwarmKit其实已经是我们今天广泛使用的Docker Swarm集群技术的基石。

　　Swarm Mode:
　　　　Swarm Mode则更进一步，它在Docker 1.12版本开始为大家所周知，一个docker swarm命令红遍大江南北，这个所谓的Swarm Mode其实就是我们今天所广泛使用的Docker Swarm集群技术。
　　　　然而Swarm Mode并不是一个全新的东西，也并不是一个全新的模式，而是站在SwarmKit的巨人肩膀上发展起来的，是Docker中的一组与集群相关功能的统称而已。
　　　　Docker将SwarmKit的核心模块内嵌于Docker的后台服务之中，通过不同的命令允许使用者同时以"本节点"和"本集群"这两种视角来操作整个集群，增加了集群的管理、节点的管理、服务的管理和编排等等一系列高级特性。
　　　　因此总结一下Swarm Mode就是：
　　　　　　(1)基于Swarmkit编写;
　　　　　　(2)支持服务模型以及服务发现、路由和负载均衡等新功能;
　　　　　　(3)使用Docker原生态的CLI命令;
　　　　　　(4)集成到了Docker engine中(强大的 docker swarm 命令);

　　参考链接:
　　　　https://github.com/docker/compose
　　　　https://www.jianshu.com/p/7eb93f1e9ed4
　　　　https://www.jianshu.com/p/3f3c9e0e3db5

4>.CoreOS Rkt 轻量级容器

　　创立于2013年的CoreOS公司旨在为各种规模的企业构建并交付基础设施，帮助其获得与大型软件企业对等的运营环境、实现自动更新与服务器修复，并协助解决停机时间控制、安全性保障以及恢复能力实现等实际难题。

　　CoreOS公司最早是Docker的支持者，其产品CoreOS操作系统是适用于企业的轻量级容器化的Linux发行版，是Docker生态圈的重要一员。
    
　　随着Docker在容器行业变得逐渐强大，Docker也越来越臃肿，CoreOS公司希望有一个更加开放和中立的容器标准，因此推出了自己的容器计划，很明显CoreOS公司也想在容器方面有一席之地。当然，这样不得不说后面有谷歌和红帽公司在背后做支持。

　　Rkt诞生于2014年11月末，我在GitHub上发现他在2014年11月27日就发布了"v0.0.0"版本，"v0.1.0"版本是在同年的12月1日发布的。

　　Rkt是一种与Docker类似的容器引擎，由CoreOS公司主导，得到了Redhat、Google、Vmware等公司的支持，更加专注于解决安全、兼容、执行效率等方面的问题。

　　就这样，CoreOS公司成为了Docker公司的容器引擎竞争对手。由于Docker已经深入人心，尽管Rkt也很优秀，但很少有人愿意将Docker技术栈迁移到Rkt技术栈。最终容器之战Docker占领了大部分市场。

　　CoreOS是CoreOS Tectonic的创建者，CoreOS Tectonic是一种企业级Kubernetes平台，可提供自动化操作，实现在私有和公共云提供商之间的可移植性，并且基于开源软件。它还提供CoreOS Quay（企业级容器注册表）。

　　CoreOS还以帮助推动许多开源技术创新而闻名，这些创新技术是容器化应用程序的核心，包括Kubernetes，它是该领域的主要贡献者。
 
　　参考链接:
　　　　https://www.openshift.com/learn/coreos/
　　　　https://www.redhat.com/en/about/press-releases/red-hat-acquire-coreos-expanding-its-kubernetes-and-containers-leadership
　　　　https://github.com/rkt/rkt/releases
　　　　https://www.sohu.com/a/216850450_468741

5>.容器编排工具之争Kubernetes完胜Docker Swarm系列

　　Docker容器开源1年3个月后，Google公司开源了容器编排系统(Kubernetes,下面简称"K8S")，当时就以最流行的Docker作为底层容器引擎，因此也为该开源项目带来不少Docker用户，可以说是相当的"吸粉"呀~

　　Docker公司也在同年年底推出了Swarm以抵抗K8S市场，在后续的3年时间内相继推出了SwarmKit，Swarm Mode集群编排方案。在Swarm被纳入Docker 1.12后，Swarm与K8S之争日趋白热化。可以看出Docker公司的野心还是非常大的。

　　在Docker公司和Google公司进行容器编排工具大战时，CoreOS公司开源的rkt容器引擎主动站队到Kubernetes，达成了合作关系，Kubernetes主力代码贡献者是Google(贡献源码第一)和RedHat(贡献源码第二)公司的人员。

　　由于CoreOS的主动加入，Kubernetes在2016年7月11日发布的kubernetes 1.3版本之后将rkt作为可选容器引擎。但这条在当时的新闻对Docker项目发展几乎没有受到任何影响，Docker早已凭借自身的稳定性和易用性占领了大批的用户！

　　大概在2017年秋季左右，如下图所示，可惜最终容器编排市场Google占有率(69%)远超过了Docker Swarm容器编排的占有率(18%)，这场容器编排技术大战以Google公司完胜宣告结束。

　　究其原因并不是Docker公司实力不行，而是由于Google公司在开源K8S之前已经有了15年企业内部的使用容器的经验了(在这15年内已经经历了两代调度系统，即Omega和Borg)。

　　经理了第一代调度系统:Omega，第二代调度系统:Borg，前两者都是商业的调度系统(即Google公司内部使用)，而第三代调度系统K8S则是开源产品，它借鉴了前两者调度的优势和经验。而Docker集群的集群编排是从2014年年底才开始的，经验尚有不足。

　　参考链接:
　　　　https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-kubernetes/
　　　　https://www.cncf.io/blog/2019/08/16/cncf-archives-the-rkt-project/
　　　　https://github.com/moby/moby
　　　　https://www.sohu.com/a/221638054_198222

6>.Docker的版本变化

　　我们知道Docker在容器编排技术上败给了K8s，大量市场被Google公司拿下，因此它没有找到一个很好的变现方式。

　　为了让Docker项目做的更大，目的是吸引更多的投资人，将来未上市就想成为传说中的"独角兽"，此时这家领导层发现"Docker"这个关键词在互联网上非常火，该公司始终无法变现，能否通过这个关键词来引流呢?

　　于是在2017年3月2日，Docker公司高层决定将docker更名为新的项目moby，其GitHub对应的地址为: "https://github.com/moby/moby"。
    
　　moby项目属于Docker项目的全新上游，docker将是一个隶属于moby的子产品，并将Docker开源版做了双发行版本，即Docker社区版(Community Edition，简称"dockerce")和Docke企业(Enterprise Edition，简称"dockeEE")版。

　　在此期间Docker社区版的使用者对此做法有很多不满。后来Docker的CEO不得不解释说是为了Docker社区版更好的发展。很多程序员估计都心里念叨过:"我信你个鬼，你个糟老头子坏得很!"

　　K8S将Docker社区版合并的代码贡献给CNCF组织，其目的是要告诉大家Google公司不会讲K8S私有化，这样大家方能大胆使用。

　　现在K8S使用Go语言研发(Docker也是使用Go语言研发)，而k8s目前还处于高速发展期，更新版本迭代是相当之快。
　　
　　最早的时候docker就是一个开源项目，主要由docker公司维护。2017年年初，docker公司将原先的docker项目改名为moby，并创建了docker-ce和docker-ee。这三者的关系是：
　　　　(1)moby是继承了原先的docker的项目，是社区维护的的开源项目，谁都可以在moby的基础打造自己的容器产品;
　　　　(2)docker-ce是docker公司维护的开源项目，是一个基于moby项目的免费的容器产品，GitHub地址如下所示:
　　　　　　　　https://github.com/docker/docker-ce
　　　　　　　　如下图所示，需要注意的是: 从Docker 20.10版本开始，用于Docker Engine和Docker CLI的软件包直接从其各自的源存储库而不是从此存储库构建。
　　　　　　　　　　https://github.com/moby/moby
　　　　　　　　　　https://github.com/docker/cli
　　　　(3)docker-ee是docker公司维护的闭源产品，是docker公司的商业产品，官网地址如下所示:
　　　　　　　　https://www.docker.com/enterprise-edition
    
    docker-ce的发布计划v1.13.1之后，发布计划更改为:
　　　　Edge: 月版本，每月发布一次，命名格式为YY.MM，维护到下个月的版本发布
　　　　Stable: 季度版本，每季度发布一次，命名格式为YY.MM，维护4个月

　　官方原文:
　　　　https://www.docker.com/blog/docker-enterprise-edition/

7>.Rkt和Docker陆续被收购

　　CoreOS公司(开源了RKT的母公司)被收购:
　　　　2018年1月31日由Redhat公司宣布收购CoreOS且已签署最终协议，收购价格为2.5亿美元。
　　　　2018年4月16日是发布的最新rkt容器工具，目前该项目已经停止维护，因此生产环境中不推荐大家使用该容器技术。推荐使用主流的容器工具，如Docker，Pouch，podman。

　　Docker公司被收购:
　　　　2019年11月左右，Mirantis收购Docker，但收购金额两家公司貌似很保密，至今未公开发布官方说明。Mirantis表示，今后的重点是Kubernetes。他还承诺将对Swarm的支持再延长至少两年。

　　参考链接:
　　　　https://analyticsindiamag.com/mirantis-docker-acquisition-enterprise-kubernetes-containers/

 

 

二.OCI与CNI那些事

1>.OCI(全称:"Open Container Initiative")

　　业内最早的容器运行时环境(Runtime)是LXC，起初Docker就是利用LXC做容器管理引擎，但是在创建容器用户空间时不在用LXC的模板现场安装生成容器。

　　而是实事先通过一种镜像技术(类似于KVM镜像启动)，把一个操作系统用户空间所要用到的所有组件事先准备编排好打包成一个文件，这个文件Docker称之为镜像文件。

　　但后来觉得隔离性差，于是自研了libcontainer组件，不过此时Docker已被CNCF挟持了，当然容器的话语权依旧归Docker公司，这并不是说CNCF组织没有能力定制Docker的标准，只不过他们真那样做就太欺负Docker公司了。

　　后来Docker又转型到runC，所以说到目前为止，runC是Docker的独生子。

　　随着LXC，LXD，Docker，Rkt等容器运行时环境各有不同，这时候容器运行时的确是有点多了，开放容器倡议(Open Container Initiative，简称"OCI")由多家公司共同成立的项目，并由linux基金会进行管理。 　　

　　OCI是建立围绕容器格式和运行时的开放式行业标准的明确目的的开放式的治理结构。OCI由Docker和其他容器行业的领导者于2015年6月建立，但在2015年12月18日才在GitHub上发布的"v0.1.1"。 　　
　　
　　所谓container runtime，主要负责的是容器的生命周期的管理。OCI目前包含两个规范：运行时规范(runtime-spec)和映像规范(image-spec)。
　　　　(1)OCI的runtime spec标准中对于容器的状态描述，创建，删除，查看等操作进行了定义，以及容器运行时如何运行指定文件系统上的包;
　　　　(2)OCI的image-spec标准在定义了如何创建一个OCI运行时可运行的文件系统上的包;

　　Docker公司将容器镜像格式和runtime(也就是runc)都捐献给了Open Container Initiative组织。runc是对于OCI标准的一个参考实现，是一个可以用于创建和运行容器的CLI(command-line interface)工具。

　　runc直接与容器所依赖的cgroup/linux kernel等进行交互，负责为容器配置cgroup/namespace等启动容器所需的环境，创建启动容器的相关进程。
　　
　　为了兼容OCI标准，docker也做了架构调整。2016年12月14日，Docker公司宣布将将容器运行时相关的程序从docker daemon剥离出来，形成了containerd。而早在同年的3月份，Docker 1.11的Docker Engine里就包含了containerd。

　　Containerd向docker提供运行容器的API，二者通过grpc进行交互。containerd最后会通过runc来实际运行容器。其架构如下图所示。
　　
　　参考链接:
　　　　https://github.com/opencontainers/runc
　　　　https://opencontainers.org/
　　　　https://github.com/opencontainers/runtime-spec/releases/tag/v0.1.1
　　　　https://www.cnblogs.com/xuxinkun/p/8036832.html
　　　　http://www.dockone.io/article/9400

 

2>.CNI(全称"Container Runtime Interface")

　　kubernetes在初期版本里，就对多个容器引擎做了兼容，因此可以使用docker、rkt对容器进行管理。以docker为例，kubelet中会启动一个docker manager，通过直接调用docker的api进行容器的创建等操作。

　　在kubernetes中，pod是由一组进行了资源限制的，在隔离环境中的容器组成。而这个隔离环境，称之为PodSandbox。

　　据说是Google(对K8S源码贡献第一)和RedHat(对K8S源码贡献第二)这两家公司有意将Docker边缘化，因此大力扶持由CoreOS公司2014年开源的轻量级rkt容器工具引擎。

　　在Kubernetes早期版本，主要是支持docker和rkt两种容器引擎，这需要Kubernetes官方做大量的工作来兼容这两种容器，而兼容会带来很多维护性工作。

　　于是在OCI提出一年后，大概在2016年12月19日，即在k8s 1.5版本之后，kubernetes推出了自己的运行时接口Container Runtime Interface(下面简称"CRI")。

　　凡是支持CRI皆可作为K8S的底层运行时，CRI接口的推出，隔离了各个容器引擎之间的差异，而通过统一的接口与各个容器引擎之间进行互动。

　　与OCI不同，CRI与kubernetes的概念更加贴合，并紧密绑定。CRI不仅定义了容器的生命周期的管理，还引入了k8s中pod的概念，并定义了管理pod的生命周期。

　　但Docker本身并未实现CRI，因此使用临时解决方案: 其中kubelet是通过CRI接口，调用docker-shim，并进一步调用docker api实现的。但这增大了K8S官方的工作负担，于是在2020年12月宣布将来会弃用docker-shim。

　　如上文所述，docker独立出来了containerd。kubernetes也顺应潮流，孵化了cri-containerd项目，用以将containerd接入到cri的标准中。

　　为了进一步与oci进行兼容，kubernetes还孵化了cri-o，成为了架设在cri和oci之间的一座桥梁。通过这种方式，可以方便更多符合oci标准的容器运行时，接入kubernetes进行集成使用。

　　可以预见到，通过cri-o，kubernetes在使用的兼容性和广泛性上将会得到进一步加强。

　　大概在2017年左右，Docker将自身的容器运行时(即"containerd")捐给了CNCF组织(该组织维护的是Kubernetes开源产品)。同年，Docker的网络组建(libnetwork)增加了CNI的支持，同时实现基于IPVS的SERVICE负载均衡。

　　来自谷歌、Docker、IBM、中兴通讯和ZJU的工程师们致力于为containerd实现CRI。该项目名为cri containerd，其特性在2017年9月25日发布了完整的v1.0.0-alpha.0版本。

　　在2018年5月24日，Kubernetes GA版本正式集成了cri containerd架构。使用cri containerd，用户可以运行Kubernetes集群，使用containerd作为底层运行时，而无需安装Docker。

　　2019年8月16日，CNCF组织正式将rkt归档，结束了rkt容器的在Kubernetes的生命周期，在此之前，2018年4月16日是发布的最新rkt容器工具。
　　
　　参考链接:
　　　　https://kubernetes.io/blog/2017/11/containerd-container-runtime-options-kubernetes/
　　　　https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/
　　　　https://www.cncf.io/blog/2019/08/16/cncf-archives-the-rkt-project/
　　　　https://github.com/containerd/cri
　　　　https://github.com/cri-o/cri-o 
　　　　https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/
　　　　https://kubernetes.io/blog/2020/12/02/dockershim-faq/
　　　　https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim
　　　　https://github.com/rkt/rkt/releases
　　　　https://www.cnblogs.com/xuxinkun/p/8036832.html 　　　　
　　　　http://www.dockone.io/article/9400

 

三.2020年Docker被误会的两件事

1>."Docker Inc."修改DockerHub定价和TOS

　　对免费用户/未登录用户影响:
　　　　流量限制:
　　　　　　(1)未登录用户每6小时允许PULL 100次;
　　　　　　(2)已登录用户每6小时允许PULL 200次;
　　　　镜像保留策略:
　　　　　　由于Docker Hub保留的镜像总大小已经超过了15PB，其中有4.5PB属于无效镜像。
　　　　　　从2020年11月1日开始生效，非活跃(指的是没有push或poll操作的)镜像，保留周期为6个月。清理前，会发送通知告知清理操作。
　　　　　　Docker团队也宣传会在Docker Hub上开发一个Dashboard以供用户查阅当前镜像的一个健康程度。
　　上述消息对企业或个人有什么影响吗？我个人觉得影响不大，因为稍微有一点规模的公司，肯定是有基础架构部门的，里面有专门负责运维的同学，它们肯定不会使用官网的Docker Hub仓库，而是会考虑自建私有的高可用Harbor服务仓库。

　　对于Docker Hub，Docker Registry，Harbor的部署或基本使用感兴趣的小伙伴可参考我之前整理的笔记，我这里就不赘述啦~
　　　　https://www.cnblogs.com/yinzhengjie/p/12231835.html
　　　　https://www.cnblogs.com/yinzhengjie/p/12232737.html
　　　　https://www.cnblogs.com/yinzhengjie/p/12233594.html
　　　　https://www.cnblogs.com/yinzhengjie/p/12235258.html
　　　　https://www.cnblogs.com/yinzhengjie/p/12237263.html


　　参考链接:
　　　　https://www.docker.com/legal/docker-terms-service
　　　　https://www.docker.com/pricing
　　　　https://docs.docker.com/docker-hub/builds/
　　　　https://docs.docker.com/docker-hub/repos/

2>.Kubernetes宣布开始进入废弃dockershim支持的倒计时

　　由于Docker在设计之初并未考虑集群编排的能力，主要考虑的单机的环境迁移问题。而且在2013年3月dotCloud公司开源时Kubernetes还为诞生呢！

　　于是谷歌在2014年3月开始开发Kubernetes，到2014年6月6日首次发布。并与2015年7月发布Kubernetes 1.0，并加入CNCF组织。2018年K8S从CNCF基金会毕业。

　　Kubernetes选择Docker作为容器运行时，本身就是因为当时它没有其他的选择，而且当时最火的容器引擎就是Docker。选择Docker可以为Kubernetes带来更多的用户。
　　
　　综上所述，因此Kubernetes在开始时那就对Docker做了内置的支持，使用"dockershim"作为调用Docker的API接口作为临时解决方案，以兼容docker引擎，当然维护该组件是需要耗费资源的。
　　
　　大概在2017年左右，Docker将的容器运行时(即"containerd")捐给了CNCF组织(该组织维护的是Kubernetes开源产品)。 

　　来自谷歌、Docker、IBM、中兴通讯和ZJU的工程师们致力于为containerd实现CRI。该项目名为cri containerd，其特性在2017年9月25日发布了完整的v1.0.0-alpha.0版本。

　　在2018年5月24日，Kubernetes GA版本正式集成了cri containerd架构。使用cri containerd，用户可以运行Kubernetes集群，使用containerd作为底层运行时，而无需安装Docker。
 
　　由于历史性原因，从2014年至今2020年底，一直维护dockershim，Kubernetes将在下一个版本Kubernetes 1.20版本中宣布废弃dockershim(若使用其API只会发出警告信息)，当然你依旧可以使用，直到k8s 1.23版本发布才会被正式移除哟~
 
　　此外，这些较新的CRI运行时中正在实现与dockershim基本上不兼容的功能，例如cgroups v2和用户名称空间。删除对dockershim的支持将允许在这些领域中进行进一步的开发。

　　综上所述:
　　　　(1)随着cri-containerd从2018年正式发布以来已经有两年多时间了，基本上也侧面证明了cri-containerd的稳定性，K8S官方任务可以将其作为容器的运行时；
　　　　(2)因此以后可以使用符合CRI标准的cri-container作为容器运行时，这样符合2016年其推出的CNI规范！不过最新版本的容器运行时版本架构发生变化，如下图所示。

　　参考链接:
　　　　https://kubernetes.io/blog/2020/12/02/dockershim-faq/
　　　　https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/
　　　　https://www.bilibili.com/video/BV1y5411G7Zf　

3>.dockershim之后的方向如何呢?

　　Docker和收购它的公司MIRANTIS会一起维护一个开源的dockershim组件，以便docker作为Kubernetes的容器运行时。

　　本次Kubernetes放弃对dockershime的维护到底有什么影响?
　　　　(1)对普通用户没有任何影响;
　　　　(2)对开发工程师也没用太大影响;
　　　　(3)对K8S运维工程师的小伙伴需要注意：
　　　　　　　　a)需要考虑将容器运行时考虑换成支持CRI的容器运行时，换句话说，就是不使用原生docker的容器运行时，而是使用集成了CRI Plugin的Containerd运行时;
　　　　　　　　b)不使用K8S官方提供的cri-containerd组件，那就只能使用Docker公司和MIRANITS公司共同维护的dockershim组件啦，只不过该组件需要你在K8S集群外部维护而已。
　　
　　听说K8S放弃dockershim后Podman可以借机上位了?
　　　　别听风就是雨，Podman和Docker一样都不兼容Container Runtime Interface(就是我们简称的"CRI")，此前Docker之所以是K8s的底层容器引擎是因为K8S官方提供了dockershim来调用docker容器的API。
　　　　尽管我们可以使用支持kind工具(它是一个CRI工具，下面链接有其官网地址)来使得Docker或者Podman容器引擎来实现CRI功能，估计使用者也寥寥无几吧，毕竟已经有比较成熟的cir-contained容器运行时。
　　　　当然，如果我们在使用的容器运行时是cri-o的时候，这时候可以使用docker或者podman来做本地调试。

　　参考链接:
　　　　https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/
　　　　https://kind.sigs.k8s.