目录

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 标准

编排与容器的技术演进之路

核心问题：容器哪些技术过时了

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​​​​​​