容器技术发展史

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模式为核心，基本实现了进程相关资源的隔离操作，没有更大的应用场景发展有限。

云时代

云时代即云计算时代，其核心是通过互联网提供计算资源和服务，用户可按需使用并支付费用，无需自行建设和维护硬件设施。这一时代的标志是IaaS、PaaS、SaaS等云服务模式的普及，例如企业通过AWS、Azure等平台租用服务器，或使用Salesforce等在线软件服务。云时代的本质是计算资源的抽象化与集中管理，用户无需关注底层硬件，只需通过互联网获取资源。

随着互联网的蓬勃发展，业务规模也在不断扩大，我们会更多考虑如果出现比现在多1000倍, 10000倍的数据量的情况，我们该如何处理?如果还想以前一样原子化的根据业务购置机器进行部署，对于很多企业来说维护并不方便，同时这种原子化的配置也不能很好的将资源利用起来。

2006年，Google 101 计划提出云的概念，对当前的主流开发模式产生深远的影响。随后，亚马逊、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也开始了生态建设。

云原生时代

云原生时代则是云计算发展的高级阶段，其核心是为云环境设计应用程序和架构，以充分利用云的弹性、可扩展性和自动化能力。云原生技术包括容器化（如Docker）、微服务架构、服务网格（如Istio）、不可变基础设施和声明式API等，代表工具如Kubernetes。云原生应用强调快速迭代、持续集成/交付（CI/CD）、自动化运维和弹性伸缩，例如电商平台在促销时自动扩展服务器资源，或通过微服务架构实现独立部署和故障隔离。

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。