Docker横空出世

2013年：Docker项目由Dotcloud公司（后更名为Docker Inc.）开源发布，最初基于Linux容器（LXC）技术，使用Go语言开发，主要在Ubuntu 12.04上实现，并迅速获得广泛关注 。

“容器”这个概念从来就不是什么新鲜的东西，也不是 Docker 公司发明的。

回到10年前，在2013年的时候，PaaS技术栈指的是以 Cloud Foundry 为代表的开源技术，当时主流的开源方案是基于OpenStack平台（iaas）部署CloudFoundry平台（paas）。

在此的方案里，CloudFoundry会将应用进行打包和分发。cf为每种主流开发语言都定义了各自的打包格式，然后传到自己的存储中，再通过调度器将应用包分发到虚拟机中运行。（是不是和现在的容器+k8s的方案有点像）

那为什么docker开源之后，直接干翻了这套技术方案呢？

关键点就是docker镜像。CloudFoundry方案中对应用打包极其繁琐且不稳定，让人抓狂。因为cf的打包只包含了代码和执行脚本，忽略了基础运行环境，就是说我打包时的环境和最终代码运行的环境并不能保证是一样的，这就导致代码在运行时可能出现各种异常问题。

Docker 镜像恰好解决了这个痛点。Docker 镜像直接把软件包需要的运行环一起打包进镜像里了（不包括操作系统内核），确保了镜像不管在哪里运行，应用都是运行在我期望的操作系统环境中，和开发者的本地系统、打包的操作系统、运行的服务器系统都没有关系。

这是一种非常宝贵的能力，只要我在本地开发完成，打好镜像，测试没问题。然后将镜像发布。那么我就可以保证应用获得了一样的运行环境。

按理说docker其实正好解决了CloudFoundry的打包难题，但是docker此时并没有CloudFoundry已经建成的调度能力。CloudFoundry完全可以和Docker合作，替换掉自己的打包流程，说不定现在我们学的就不是k8s,而是cf了。

很快其他更敏捷的公司跟进，推出基于Docker的容器集群管理项目。他们称自己为CaaS 即 Container-as-a-Service,以便和过时的PaaS划清界限。

Docker的进击

2014年：Docker推出了Docker Compose工具，用于定义和运行多容器Docker应用程序，这标志着Docker从单机容器管理向集群管理的转变 。

2014 年底的 DockerCon 上，Docker 公司雄心勃勃地对外发布了自家研发的“Docker 原生”容器集群管理项目 Swarm。

如果Swarm能如愿推广成功，那么Docker 公司这个小公司将正式迈入伟大公司的行列。

Docker很火，但是说到底，Docker只是一个用来打包和启停应用的小工具。一个公司想要的都是用户来上他们的平台，而不是做一个平台背后的底层工具。

所以Docker公司推出Swarm技术方案，向PaaS平台能力进化。

此时要提到另一个基础设施领域的创业公司CoreOS。CoreOS公司发现可以把容器技术集成到自己的方案中，从而优化自己的PaaS平台方案。于是积极参与到Docker开源社区，很快成了Docker项目中第二重要的力量。

（CoreOS另一个著名产品是etcd）

看到这里，你也会发现Docker公司和CoreOS公司在业务战略上有严重的重合，两家公司很快从合作转向了竞争。

2014 年底，CoreOS 公司以强烈的措辞宣布与 Docker 公司停止合作，并直接推出了自己研制的 Rocket（后来叫 rkt）容器。

Docker公司此时可谓当红炸子鸡，获得大量注资。不差钱的Docker并购了多个项目来完善自己的平台能力。迅速建立起一个非常繁荣的“Docker 生态”，此时的Docker看起来离最后的成功一步之遥。

Kubernetes 项目诞生

CoreOS 和Docker分手之后过的并不好，一方面广大开发者已经习惯了Docker及其配套技术，他推出的rkt容器完全打不开局面。

同样郁闷的还有一个老牌公司RedHat。RedHat最初也积极参与了Docker开源社区，同样是因为Docker激进的推动Docker Swarm项目与自己的战略利益冲突而退出Docker社区。RedHat此时只有OpenShift这个跟 Cloud Foundry 同时代的经典 PaaS 一张牌可以打，在和Docker Swarm的竞争中处于下风。

没想到，就在此时一个新项目的诞生拯救了CoreOS和RedHat。

Docker公司在Docker生态中的强势地位，直接影响了很多大公司的切身利益。

几家大公司开始合谋降低Docer公司的话语权，手段也很经典：成立一个中立的开放的云原生基金会。

2015 年 6 月 22 日，由 Docker 公司牵头，CoreOS、Google、RedHat 等公司共同宣布，Docker 公司将 Libcontainer 捐出，（Libcontainer是Docker公司开发的一个容器运行时库），并改名为 RunC 项目，交由一个完全中立的基金会管理，然后以 RunC 为依据，大家共同制定一套容器和镜像的标准和规范。

这套标准和规范，就是 OCI（ Open Container Initiative ）。

OCI 提出的目的就在于将容器运行时的实现和镜像的实现从 Docker 项目中完全剥离出来。这样各大公司可以不依赖于Docker，构建自己的平台能力。

很明显Docker公司对OCI标准的推进并不会很积极。OCI标准也没有动摇Docker在容器领域的霸主地位，因为Docker 项目已经是容器生态的事实标准，而且 Docker 社区也足够庞大。

眼看OCI并没有对Docker产生实质性的打击，各大公司又祭出第二招。

瞄准了刚推出不久的Swarm，Google、RedHat 等开源基础设施领域玩家们，共同牵头发起了一个名为 CNCF（Cloud Native Computing Foundation）的基金会。建立一个以 Kubernetes 项目为基础的开放云原生社区。

Kubernetes 项目来源于Google内部的Borg 和 Omega 系统，是Google 公司在容器化基础设施领域多年来实践经验的沉淀与升华。

Kubernetes 开源之后，RedHat 积极参与，迅速在云原生时代占得一席之地。RedHat 与 Google 联盟成立。

CNCF 社区发展迅猛，很快拿下了Prometheus这一容器监控的事实标准，又加入了Fluentd、OpenTracing等知名项目。现在cncf社区已经有接近200个项目

Cloud Native Computing Foundation (cncf.io)

为什么k8s会击败Docker公司的swarm

一是k8s来源于Google内部使用多年的项目，其设计理念和架构都非常先进。

二是有富爸爸撑腰，人力财力支持

三更重要的是对开源社区的运作非常成功。Docker在取得容器的霸主地位之后，与开源社区渐行渐远。cncf社区则在推进其民主化架构。从 API 到容器运行时的每一层，Kubernetes 项目都为开发者暴露出了可以扩展的插件机制，鼓励用户通过代码的方式介入 Kubernetes 项目的每一个阶段。在整个容器社区中催生出了大量的、基于 Kubernetes API 和扩展接口的二次创新工作，比如：目前热度极高的微服务治理项目 Istio；被广泛采用的有状态应用部署框架 Operator；

cncf的繁荣

2016 年之后k8s得到了空前的发展，不同于之前局限于“打包、发布”这样的 PaaS 化路线，这一次容器社区的繁荣，是一次完全以 Kubernetes 项目为核心的“百家争鸣”。

相对应的就是Docker公司的落寞，之前拒绝了微软的天价收购。现在无奈豪赌失败之后选择逐步放弃开源社区而专注于自己的商业化转型。

从 2017 年开始，Docker 公司将 Docker 项目的容器运行时部分 Containerd 捐赠给 CNCF 社区

2018 年 1 月 30 日，RedHat 宣布斥资 2.5 亿美元收购 CoreOS

2022年：Kubernetes宣布从v1.20起不再支持Docker运行时，并在v1.24中完全移除，这标志着Docker在Kubernetes生态中的地位发生变化 。

回首看容器技术快速普及发展的那几年，真有种波澜壮阔之感，不只是技术的发展进步。各大公司之间的斗法也同样精彩。CNCF开源社区的运作也是漂亮。