Docker简史
2010：dotCloud成立
2010年，几个大胡子年轻人在旧金山成立了一家做PaaS平台的公司，起名 “dotCloud”，该公司主要是基于PaaS平台为开发者或开发商提供技术服务。他们提供了对多种运行环境支持，如Java，Python，Ruby，Node.js等。PaaS的概念虽好，但是由于认知、理念和技术的局限性，市场的接受度并不高，市场的规模也不够大。
2013：Docker开源发布
有一天dotCloud的创始人Solomon Hykes就召集了公司核心开发人员，商量准备开源Docker技术。因此，在2013年3月，Docker正式以开源软件形式在pycon网站首发。正式由于这次开源，让容器领域焕发了第二春。很快Docker技术风靡全球，dotCloud决定改名为Docker Inc(下面简称"Docker")，全身心投入到Docker的开发中。
2014：Docker容器集群方案
早在2014年底，Docker公司就设计了容器集群的方案组合：Machine(可快速创建Docker运行环境) + Swarm + Compose(自定义文件格式以运行多容器应用程序的工具)。当然此时的Swarm局限性较大，比如：
- 没有副本和负载均衡的概念，这导致服务无法高可用。
- 不存在服务网络管理和跨节点数据存储。
- 没有服务模型：集群中服务间关系和启动顺序编排也很复杂。
2016：Docker容器编排技术
SwarmKit
在2016年2月，Docker公司开始了一个名叫SwarmKit的项目。而恰在Docker 1.12 RC之前的一段时间，Docker发布了Swarmkit，这是一个独立的、开源的容器编排项目。SwarmKit不同于一开始的经典Swarm，它从一开始就重新设计了一套独立的API和模型体系，并且采用独立的客户端命令行工具"swarmctl"。和上面的经典Swarm模型相比，它加入了如下特性：
- 重新设计的一套独立的API和模型体系。
- 使用了自己的CLI(swarmd命令负责管理，swarmctl命令用于控制)。
- 节点管理、服务模型更加自然，提供编排和调度服务。
- 将过去Swarm依赖的外部集群一致性存储组件Etcd的核心部分内置化。
- SwarmKit并没有提供诸如服务发现、负载均衡和路由等功能。尽管如此，SwarmKit其实已经是我们今天广泛使用的Docker Swarm集群技术的基石。
Swarm Mode
Swarm Mode在Docker 1.12版本开始为大家所周知，Swarm Mode其实就是我们今天所广泛使用的Docker Swarm集群技术。Swarm Mode并不是一个全新的技术，也并不是一个全新的模式，而是在SwarmKit的基础上发展起来的，是Docker中的一组与集群相关功能的统称。Docker将SwarmKit的核心模块内嵌于Docker的后台服务之中，通过不同的命令允许使用者同时以"本节点"和"本集群"这两种视角来操作整个集群，增加了集群的管理、节点的管理、服务的管理和编排等等一系列高级特性。
总结一下Swarm Mode特性：
- 基于Swarmkit编写。
- 支持服务模型以及服务发现、路由和负载均衡等新功能。
- 使用Docker原生态的CLI命令。
- 集成到了Docker engine中(强大的 docker swarm 命令)。
2017：Docker项目更名Moby
当时Docker在容器编排市场占有率远低于Google的K8S，导致Docker公司没有找到很好的变现方式。为了让Docker项目做的更大，目的是吸引更多的投资人，将来未上市就想成为传说中的"独角兽"，此时这家领导层发现"Docker"这个关键词在互联网上非常火，该公司始终无法变现，能否通过这个关键词来引流呢?
于是在2017年3月2日，Docker公司高层决定将docker更名为新的项目moby。moby项目属于Docker项目的全新上游，docker将是一个隶属于moby的子产品，并将Docker开源版做了双发行版本，即Docker社区版(Community Edition，简称"docker-ce")和Docke企业(Enterprise Edition，简称"docke-ee")版。
moby、docker-ce、docker-ee这三者的关系是：
2017：cri-containerd
随着容器技术的发展，且LXC，LXD，Docker，Rkt等容器运行时环境各有不同，2015年6月由多家公司共同成立了开放容器倡议(Open Container Initiative，简称"OCI")项目，并由linux基金会进行管理。OCI是一个轻量级，开放的治理结构（项目），在 Linux 基金会的支持下成立，致力于围绕容器格式和运行时创建开放的行业标准。
Docker之后将runC捐献给了OCI，作为OCI标准的一个参考实现。OCI标准发布后Docker为了兼容OCI标准对架构进行了调整，2016年12月14日，Docker公司宣布将将容器运行时相关的程序从docker daemon剥离出来，形成了containerd。
在OCI提出一年后，大概在2016年12月19日，即在k8s 1.5版本之后，kubernetes推出了自己的运行时接口Container Runtime Interface(下面简称"CRI")。大概在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版本。
CNCF/OCI/CRI简介
CNCF（云原生计算基金会）
CNCF，全称Cloud Native Computing Foundation（云原生计算基金会），成立于 2015 年7月21日（于美国波特兰OSCON 2015上宣布），其最初的口号是坚持和整合开源技术来让编排容器作为微服务架构的一部分，其作为致力于云原生应用推广和普及的一支重要力量，不论您是云原生应用的开发者、管理者还是研究人员都有必要了解。
CNCF作为一个厂商中立的基金会，致力于Github上的快速成长的开源技术的推广，如Kubernetes、Prometheus、Envoy等，帮助开发人员更快更好的构建出色的产品。
OCI（开放容器倡议）
OCI开放容器倡议(Open Container Initiative)是一个开放的治理结构，其明确目的是围绕容器格式和运行时创建开放的行业标准。 OCI 由 Docker 和其他容器行业的领导者于 2015 年 6 月创立，目前包含两个规范：运行时规范（runtime-spec）和镜像规范（image-spec）。
运行时规范概述了如何运行在磁盘上解压的“文件系统包”。在高层次上，OCI 实现会下载一个 OCI 映像，然后将该映像解压缩到一个 OCI 运行时文件系统包中。此时，OCI Runtime Bundle 将由 OCI Runtime 运行。
K8S开放接口：CRI、CNI、CSI
Kubernetes作为云原生应用的的基础调度平台，相当于云原生的操作系统，为了便于系统的扩展，Kubernetes中开放的以下接口，可以分别对接不同的后端，来实现自己的业务逻辑：
CRI（Container Runtime Interface）：容器运行时接口，提供计算资源
CNI（Container Network Interface）：容器网络接口，提供网络资源
CSI（Container Storage Interface）：容器存储接口，提供存储资源
以上三种资源相当于一个分布式操作系统的最基础的几种资源类型，而Kuberentes是将他们粘合在一起的纽带。
本文参考：
Docker in Practice SECOND EDITION
Docker Container发展史
Introducing Container Runtime Interface (CRI) in Kubernetes
Kubernetes Handbook——Kubernetes 中文指南/云原生应用架构实战手册
评论区