目录
Jail 时代
1979 年 贝尔实验室发明 chroot
2000 年 FreeBSD 4.0 发行 FreeBSD Jail
2001 年 Linux VServer 发行
2004 年 Solaris Containers 发行
云时代
2006 年 google 推出 Process Containers
2008 年 LXC 推出
2011 年 CloudFoundry 推出 Warden
2013 年 LMCTFY 启动
2013 年 Docker 推出到风靡全球
云原生时代
Google &Docker 竞争
2013 年 CoreOS 发布和 Docker 由合作终止
2014 年 6 月 Google 发布开源的容器编排引擎 Kubernetes（K8S）
2014 年 12 月 CoreOS 发布开源容器引擎 Rocket(rkt)
2015年 Docker 推出容器集群编排组件 Swarm
2015 年 6 月 Docker 成立 OCI
2015 年 7 月 Google 带头成立 CNCF
k8s 成为云原生事实标准
2016 年 发布 CRI 标准
2016 年 Docker 捐献 containerd
2016 年 CRI-O 发布
2017 年 containerd 确定作为标准 CRI
编排与容器的技术演进之路
DockerClient
RUNC&Shim
编辑CRI-Containerd
CRI-O
Containerd
实际生产的集群采用的什么运行时组件？
Jail 时代
容器不是一个新概念或者新技术，很早就有了，只是近几年遇到了云计算，整个技术被彻底引爆了。
1979 年 贝尔实验室发明 chroot
chroot 系统调用是在 1979 年开发第 7 版 Unix 期间引入的。贝尔实验室在 Unix V7 的 开发过程中，发现当一个系统软件编译和安装完成后，整个测试环境的变量就会发生 改变，下一次测试需要重新配置环境信息。
设计者们思考能否隔离出来一个独立的环境，来构建和搭建测试环境，所以发明了 chroot，可以把一个进程的文件系统隔离起来。
chroot 系统调用可以将进程及其子进程的根目录更改为文件系统中的新位置。隔离以 后，该进程无法访问到外面的文件，因此这个被隔离出来的新环境像监狱一样，被命 名为 Chroot Jail （监狱）。后续测试只需要把测试信息放到 Jail 中就可以完成测试了。
这一进步是进程隔离的开始：为每个进程隔离文件访问。所以 chroot 可以认为是容器技术的鼻祖。
2000 年 FreeBSD 4.0 发行 FreeBSD Jail
2000 年，当时一家小型共享环境托管提供商提出了 FreeBSD Jail，以实现其服务与其 客户服务之间的明确分离，以实现安全性和易于管理。每个 Jail 都是一个在主机上运 行的虚拟环境，有自己的文件、进程、用户和超级用户帐户,能够为每个系统分配一个 IP 地址。
FreeBSD Jail 不仅仅有 chroot 的文件系统隔离，并且扩充了独立的进程和网络空间。
2001 年 Linux VServer 发行
与 FreeBSD Jails 一样，Linux VServer 是一种监狱机制，可以对计算机系统上的资源 （文件系统、网络地址、内存）进行分区。
2004 年 Solaris Containers 发行
2004 年， Solaris Containers 的第一个公开测试版发布，结合系统资源控制和区域进 行隔离，并添加了快照和克隆能力。
这个时期的进程隔离技术大多以 Jail 模式为核心，基本实现了进程相关资源的隔离操 作，没有更大的应用场景发展有限。
云时代
2006 年，Google 101 计划提出云的概念，对当前的主流开发模式产生深远的影响。 也许以后我们会更多考虑如果出现比现在多 1000 倍, 10000 倍的数据量的时候，我们 该如何处理?要想让”云”发挥潜能，与此相关的编程和操作就应该与使用互联网一样简 单。随后，亚马逊、IBM 等行业巨头也陆续宣布各自的“云”计划，宣告“云”技术时代的 来临。
云计算需要处理海量数据、超高并发、快速扩展等问题，此时不仅仅需要隔离还需要 能够对资源进行控制和调配。
2006 年 google 推出 Process Containers
Process Containers（由 Google 于 2006 年推出）旨在限制、统计和隔离一组进程的 资源使用（CPU、内存、磁盘 I/O、网络）。一年后它更名为“Control Groups (cgroups)”，并最终合并到 Linux 内核 2.6.24。
2008 年 LXC 推出
LXC（Linux 容器）是 Linux 容器管理器的第一个、最完整的实现。它是在 2008 年使用 cgroups 和 Linux 命名空间实现的，它可以在单个 Linux 内核上运行，不需要任何补丁。
同年谷歌推出 GAE（Google App Engine），首次把开发平台当做一种服务来提供，采 用云计算技术，跨越多个服务器和数据中心来虚拟化应用程序。
同时 Google 在 GAE 中使用了 Borg （Kubernetes 的前身）来对容器进行编排和调度。 LXC 和 Borg 其实就相当于最早的 docker 和 k8s.
2011 年 CloudFoundry 推出 Warden
2011 年启动了 Warden，早期使用 LXC，后来替换为自己的实现,直接对 Cgroups 以及 Linux Namespace 操作。开发了一个客户端-服务器模型来管理跨多个主机的容器 集合，并且可以管理 cgroups、命名空间和进程生命周期。
2013 年 LMCTFY 启动
Let Me Contain That For You (LMCTFY) 于 2013 年作为 Google 容器堆栈的开源版本 启动，提供 Linux 应用程序容器。应用程序可以“容器感知”，创建和管理它们自己的子 容器。在谷歌开始和 docker 合作，后续转向了 docker 公司的 libcontainer，LMCTFY 的于 2015 年停止。
2013 年 Docker 推出到风靡全球
Docker 最初是一个叫做 dotCloud 的 PaaS 服务公司的内部项目，后来该公司改名为 Docker。Docker 在初期与 Warden 类似，使用的也是 LXC，之后才开始采用自己开发 的 libcontainer 来替代 LXC，它是将应用程序及其依赖打包到几乎可以在任何服务器 上运行的容器的工具。与其他只做容器的项目不同的是，Docker 引入了一整套管理容 器的生态系统，这包括高效、分层的容器镜像模型、全局和本地的容器注册库、清晰 的 REST API、命令行等等。
Docker 为提供了一整套的解决方案，不仅解决了容器化问题，而且解决了分发问题， 很快被各大厂商选择变成了云基础设施，厂商围绕 Docker 也开始了生态建设。
云原生时代
Google &Docker 竞争
2013 年 CoreOS 发布和 Docker 由合作终止
技术革命带来新的市场机遇，CoreOS 也是其中的一员，在容器生态圈中贴有标签： 专为容器设计的操作系统 CoreOS。作为互补，CoreOS+Docker 曾经也是容器部署的 灵魂伴侣。CoreOS 为 Docker 的推广和源码社区都做出了巨大的贡献。
Docker 生态扩张，与最开始是“一个简单的基础单元”不同，Docker 也在通过开发或收购逐步完善容器云平台的各种组件，准备打造自己的生态圈，而这与 CoreOS 的布局 有直接竞争关系。
2014 年 6 月 Google 发布开源的容器编排引擎 Kubernetes（K8S）
容器只是解决了容器化 ，分发问题，但是一个软件的网络问题、 负载均衡问题 、监控、部署、更新、镜像管理、发布等很多问题并没有有效的解决。
Google 内部调度系统 Borg 已经拥有 10 多年的使用容器经验，在 2014 年 6 月推出了开源的 K8S,可以支持对容器的编排和管理，完成生态的闭环。
同年 7 月，微软、Red Hat、IBM、Docker、CoreOS、 Mesosphere 和 Saltstack 等 公司，相继加入 K8S。之后的一年内，VMware、HP、Intel 等公司，也陆续加入。
2014 年 12 月 CoreOS 发布开源容器引擎 Rocket(rkt)
2014年底，CoreOS 正式发布了 CoreOS 的开源容器引擎 Rocket（简称 rkt），和 Docker 正式分开发展。Google 于 2015 年 4 月领投 CoreOS 1200 万美元，而 CoreOS 也发布了 Tectonic，成为首个支持企业版本 kubernetes 的公司。从此，容器 江湖分为两大阵营，Google 派系和 Docker 派系。
2015年 Docker 推出容器集群编排组件 Swarm
在 Docker 1.12 及更高版本中，Swarm 模式与 Docker 引擎集成,为 Docker 容器提供 原生集群管理功能。
两大派系的竞争愈演愈烈，行业标准的诉求越来越强烈。
2015 年 6 月 Docker 成立 OCI
Docker 公司在容器运行因为高速迭代导致变更频繁，影响较大。
2015 年 6 月 22 日，由 Docker 公司牵头，CoreOS、Google、RedHat 等公司共同宣 布，Docker 公司将 Libcontainer 捐出，并改名为 RunC 项目，交由一个完全中立的基 金会管理，然后以 RunC 为依据，大家共同制定一套容器和镜像的标准和规范。 RUNC 的本质就是可以不通过 Docker Damon 直接运行容器。
规范就是 OCI，旨在“制定并维护容器镜像格式和容器运行时的正式规范（OCI Specifications）”。其核心产出是 OCI Runtime Spec（容器运行时规范）、OCI Image Spec（镜像格式规范）、OCI Distribution Spec （镜像分发规范）。所以 OCI 组织解决 的是容器的构建、分发和运行问题。
社区们期望通过标准来约束 Docker 公司的话语权，不过 Docker 公司并没有积极推动 OCI 的发展，而且 OCI 也无法影响 Docker 的地位，因为 Docker 已经是事实的容器标 准。
Google 和 RedHat 等公司将方向调转到容器上面的平台层。
2015 年 7 月 Google 带头成立 CNCF
Google 联合 Linux 基金会成立 CNCF （Cloud Native Computing Foundation）云原 生计算基金会。旨在构建云原生基础设施。K8S 是第一个纳入进来的项目，像后续有名的监控设施 Prometheus，配置设施 ETCD 都加入进来。CNCF 组织解决的是应用 管理及容器编排问题。和 OCI 共同制定了一系列行业事实标准。
k8s 成为云原生事实标准
2016 年 发布 CRI 标准
Google 就和红帽主导了 CRI 标准，用于 k8s 和特定的容器运行时解耦。 CRI(Container Runtime Interface 容器运行时接口)本质上就是 k8s 定义的一组与容器 运行时进行交互的接口，所以只要实现了这套接口的容器运行时都可以对接 k8s。
但是这个适合 Docker 还是事实标准，并 CRI 并没有话语权，但是又必须支持 Docker， 所以就有了 dockershim,dockershim 的本质其实就是 k8s 对接 docker 的一个 CRI 的实现。
2016 年 Docker 捐献 containerd
containerd 作为运行时标准，Docker 从 Docker Engine 种剥离出来，捐献给 CNCF.这个时候 Google 为了将 containerd 加入到 cri 标准中，又开发了 cri-containerd，用来完 成 k8s 和容器之间的交互。
2016 年 CRI-O 发布
CRI-O 可以让开发者直接从 Kubernetes 来运行容器，这意味着 Kubernetes 可以不依赖于传统的容器引擎（比如 Docker），也能够管理容器化工作负载。容器此时也回归 到自己的位置，如何更好的封装云原生的程序。
在 2016 年，Docker 公司宣布了一个震惊全部人的计划：放弃现有的 Swarm 项目，将容器编排和集群管理功能所有内置到 Docker 项目中。
而 Kubernetes 的应对策略则是反其道而行之，开始在整个社区推动 “民主化”架构，从 API 到容器运行时的每一层，Kubernetes 项目都为开发者暴露出了能够扩展的插件机 制，鼓励用户经过代码的方式介入到 Kubernetes 项目的每个阶段。
在进入 2017 年之后，更多的厂商愿意把宝压在 K8S 上，投入到 K8S 相关生态的建设 中来。这两年包括阿里云、腾讯、百度等中国科技企业也陆续加入 CNCF，全面拥抱 容器技术与云原生。
Swarm 的失败后, 社区版 Docker 项目改名为 moby，将 Docker 引流到 Docker 的企业 版上去，螳臂挡车。
2017 年 containerd 确定作为标准 CRI
2017 年各大厂商都开始拥抱 Kubernetes，亚马逊 AWS，Microsoft Azure，VMware， 有的甚至抛弃了自家的产品。
亚马逊网络服务（AWS）于八月份以白金会员（最高级别）加入了 CNCF。 VMware 都作为 CNCF 的白金会员注册.
Docker Inc.ocker 企业版框架中添加了本地 Kubernetes 支持。Docker 自己的 Swarm 技术也借鉴了 k8s 的技术进一步发展。
Kubernetes 已成了容器编排领域的绝对标准， Docker 已成容器事实的标准。
编排与容器的技术演进之路
核心问题：容器哪些技术过时了
DockerClient
此时 K8s 只是编排领域的一个选择，而 Docker 此时一家独大，所以 K8s 的客户端只是作为 Docker 的客户端来调用 Docker 引擎来完成服务。
RUNC&Shim
OCI 催生 runc，剥离 Docker Engine 的一家独大的情况，确保各个厂商都可以搭建自己的容器平台。CRI 标准确立了但是 Docker 并没有接入该标准。此时催生了临时技术 shim.
CRI-Containerd
containerd 被捐献出来，谷歌开发 cri-containerd 接入 CRI 标准。
CRI-O
k8s 已经成为事实的编排标准，促使容器回归云原生本质。
Containerd
containerd 实现 CRI，成为 CRI 的事实标准.
实际生产的集群采用的什么运行时组件？
以腾讯的 TKE（腾讯商用 K8S 产品) 为例，支持选择 containerd 和 docker 两种模式的选择。
如何选择呢？
(1). Containerd 调用链更短，组件更少，更稳定，占用节点资源更少。建议选择 Containerd。
(2). 以下情况还是要用 docker
-
使用 docker build/push/save/load 等命令。 调用 docker API 需要 docker compose 或 docker swarm。
