共计 4253 个字符，预计需要花费 11 分钟才能阅读完成。
Docker 大略没想到，2020 年，它在技术圈内的两次成为（舆论的）焦点，居然都是因为信息差（说是“题目党”也不为过）。
概览
2013 年
Docker 是在 2013 年的 PyCon 上首次正式对外颁布的。
它带来了一种先进的软件交付形式，即，通过容器镜像进行软件的交付。
工程师们只须要简略的 docker build 命令即可制作出本人的镜像，并通过 docker push 将其公布至 DockerHub 上。
通过简略的 docker run 命令即可疾速的应用指定镜像启动本人的服务。
通过这种方法，能够无效的解决软件运行时环境差别带来的问题，达到其 Build once, Run anywhere 的指标。
从此 Docker 也根本成为了容器的代名词，并成为容器时代的引领者。
2014 年
2014 年 Google 推出 Kubernetes 用于解决大规模场景下 Docker 容器编排的问题。
这是一个逻辑抉择，在过后 Docker 是最风行也是惟一的运行时。 Kubernetes 通过对 Docker 容器运行时的反对，迎来了大量的用户。
同时，Google 及 Kubernetes 社区与 Docker 也在进行着亲密的单干，在其官网博客上有如下内容：
We’ll continue to build out the feature set, while collaborating with the Docker community to incorporate the best ideas from Kubernetes into Docker.
An update on container support on Google Cloud Platform
Kubernetes is an open source manager for Docker containers, based on Google’s years of experience using containers at Internet scale.
Docker is delivering the full container stack that Kubernetes schedules into, and is looking to move critical capabilities upstream and align the Kubernetes framework with Libswarm.
Welcome Microsoft, RedHat, IBM, Docker and more to the Kubernetes community
并在同一个月的 DockerCon 上公布演讲，介绍了 Kubernetes 并受到了宽泛的关注。
此时 Docker Inc. 也公布了其容器编排工具，libswarm（也就是起初的 swarmkit）。
2015 年
2015 年 OCI（Open Container Initiative）由 Docker 和其余容器行业领导者独特成立（它也是 Linux 基金会旗下我的项目）
OCI 次要蕴含两个标准：
- 运行时标准（runtime-spec）：容器运行时，如何运行指定的 文件系统上的包
- 容器镜像标准（image-spec）：如何创立一个 OCI 运行时可运行的文件系统上的包
Docker 把它本人的容器镜像格局和 runtime ( 当初的 runc ) 都捐给了 OCI 作为初始工作。
2016 年
2016 年 6 月，Docker v1.12 公布，带来了 Docker 在多主机多容器的编排解决方案，Docker Swarm。
这里也须要留神的是，Docker v1.12 的设计准则：
- Simple Yet Powerful（简略而弱小）
- Resilient（弹性）
- Secure（平安）
- Optional Features and Backward Compatibility（可选性能及向后兼容）
所以你能够通过配置自行抉择是否须要应用 Docker Swarm，而无需放心有什么副作用。
2016 年 12 月，Kubernetes 公布 CRI（Container Runtime Interface），这当中一部分起因是因为 Kubernetes 尝试反对另一个由 CoreOS 领导的容器运行时我的项目 rkt，然而须要写很多兼容的代码之类的，为了防止后续兼容其余运行时带来的保护工作，所以公布了对立的 CRI 接口，但凡反对 CRI 的运行时，皆可间接作为 Kubernetes 的底层运行时；
当然，Kubernetes 也是在 2016 年逐渐获得那场容器编排和平的胜利的。
2017 年
2017 年，Docker 将本身从 v1.11 起开始引入的容器运行时 containerd 捐给了 CNCF
2017 年，Docker 的网络组件 libnetwork 减少了 CNI 的反对；
同时通过应用 Docker 为 Docker Swarm 提供的 ipvs 相干的代码，也在 Kubernetes 中实现了基于 IPvs 的 service 负载平衡。不过在 v1.18 中开始移除了相干的依赖。
同年 11 月，Kubernetes 中新增了 containerd 的反对
2018 年
2018 年，Kubernetes 的 containerd 集成，正式 GA
之前版本的架构：
新的架构：
2019 年
2019 年，上文中提到的另一个容器运行时我的项目 rkt 被 CNCF 归档，终止使命了；
2019 年 Mirantis 收买 Docker 的企业服务。
2020 年
工夫回到往年，Docker 次要被误会的两件事：
- Docker Inc. 批改 DockerHub 的定价和 TOS。国内争执较多的次要是对于合规性的问题（然而被题目党带歪了，免不了恐慌）；
- Kubernetes 发表开始进入废除 dockershim 反对的倒计时，被人误以为 Docker 不能再用了；
阐明
对于 DockerHub 批改定价和 TOS 的事件，这里就不再多说了，毕竟 DockerHub 目前大家依然用的很欢畅，远不像当初那些题目党声称的那样。
重点来说一下第二件事件吧。
Kubernetes 当初抉择 Docker 作为其容器运行时，自身就是因为过后它没有其余的抉择，并且抉择 Docker 可为它带来泛滥的用户。
所以，开始时，它便提供了内置的对 Docker 运行时的反对。
而 Docker 其实创立之初，并没有思考到“编排”的这个性能，当然也没有思考到 Kubernetes 的存在（因为过后还没有）。
dockershim 始终都是 Kubernetes 社区为了能让 Docker 成为其反对的容器运行时，所保护的一个兼容程序。 本次所谓的废除，也仅仅是 Kubernetes 要放弃对当初 Kubernetes 代码仓库中的 dockershim 的保护反对。 以便其能够像开始时打算的那样，仅负责保护其 CRI，任何兼容 CRI 的运行时，皆可作为 Kubernetes 的 runtime。
在 Kubernetes 提出 CRI 时，有人倡议在 Docker 中实现它。然而这种形式也会带来一个问题，即便 Docker 实现了 CRI，但它依然不是一个单纯的容器运行时，它自身蕴含了大量的非“纯底层容器运行时”所具备的性能。
所以起初 自 Docker 中分离出来的 containerd 我的项目，作为一个底层容器运行时呈现了，它是 Kubernetes 容器运行时更好的抉择。
Docker 应用 containerd 作为其底层容器运行时以及泛滥的云厂商及公司在生产环境中应用 containerd 作为其 Kubernetes 的运行时，这也从侧面验证了 containerd 的稳定性。
当初 Kubernetes 和 Docker 社区都置信 containerd 曾经足够成熟可间接作为 Kubernetes 的运行时了，而无需再通过 dockershim 应用 Docker 作为 Kubernetes 的运行时了。这也标记着 Docker 为 Kubernetes 提供一个现代化的容器运行时的承诺最终兑现了。
而本次事件中，重点的 dockershim 之后的方向如何呢？Kubernetes 代码仓库中的 dockershim 将会在将来版本中移除，然而 Mirantis 公司曾经和 Docker 达成单干，在将来会独特保护一份 dockershim 组件，以便反对 Docker 作为 Kubernetes 的容器运行时。
Otherwise, if you’re using the open source Docker Engine, the dockershim project will be available as an open source component, and you will be able to continue to use it with Kubernetes; it will just require a small configuration change, which we will document.
Mirantis 公司发表将保护 dockershim
Q&A
Q：本次 Kubernetes 放弃对 dockershim 的保护，到底有什么影响？
A：对于普通用户而言，没有任何影响；对于在 Kubernetes 之上进行开发的工程师，没什么太大影响；对于集群管理员，须要思考是否要在将来版本中，将容器运行时，降级为反对 CRI 的运行时，比方 containerd。
当然，如果你并不想切换容器运行时，那也没关系，Mirantis 公司将来会和 Docker 独特保护 dockershim , 并作为一个开源组件提供。
Q: Docker 不能用了吗？
A：Docker 依然是本地开发，或者单机部署最佳的容器工具，它提供了更为人性化的用户体验，并且也有丰盛的个性。目前 Docker 曾经和 AWS 达成单干，可间接通过 Docker CLI 与 AWS 集成。另外，Docker 也依然能够作为 Kubernetes 的容器运行时，并没有立刻停止对其反对。
Q：据说 Podman 能够借机上位了？
A：想太多。Podman 也并不兼容 CRI，并且它也不具备作为 Kubernetes 容器运行时的条件。我集体也偶然有在用 Podman，并且咱们在 KIND 我的项目中也提供了对 Podman 的反对，但瞎话讲，它也就是只是一个 CLI 工具，某些状况下会有些作用，比方如果你的 Kubernetes 容器运行时应用 cri-o 的状况下，能够用来本地做下调试。
总结
本文次要介绍了 Docker 和 Kubernetes 的倒退历程，也解释了本次 Kubernetes 仅仅是放弃其对 dockershim 组件的反对。将来更举荐的 Kubernetes 运行时是 兼容 CRI 的 containerd 之类的底层运行时。
Mirantis 公司将会和 Docker 独特保护 dockershim 并作为开源组件提供。
Docker 依然是一款最佳的本地开发测试和部署的工具。
欢送订阅我的文章公众号【MoeLove】