【Docker】容器技术的发展 & 演进之路

【Docker】容器技术的发展 & 演进之路

引用

CSDN

1.

https://m.blog.csdn.net/weixin_74531333/article/details/140755707

容器技术的发展历程是一部充满创新与竞争的科技史。从早期的Jail技术到现代的Docker和Kubernetes，容器技术经历了数十年的演进，逐渐成为云计算和DevOps领域的核心技术。本文将带你回顾容器技术的发展历程，了解其背后的技术创新和产业变革。

一、容器技术发展史

1、Jail 时代

容器不是一个新概念或者新技术，很早就有了，只是近几年遇到了云计算，整个技术被彻底引爆了。

（1）1979 年贝尔实验室发明 chroot

chroot 系统调用是在1979年开发第7版Unix期间引入的。贝尔实验室在Unix V7 的开发过程中，发现当一个系统软件编译和安装完成后，整个测试环境的变量就会发生改变，下一次测试需要重新配置环境信息。设计者们思考能否隔离出来一个独立的环境，来构建和搭建测试环境，所以发明了chroot，可以把一个进程的文件系统隔离起来。

chroot 系统调用可以将进程及其子进程的根目录更改为文件系统中的新位置。隔离以后，该进程无法访问到外面的文件，因此这个被隔离出来的新环境像监狱一样，被命名为 Chroot Jail （监狱）。后续测试只需要把测试信息放到 Jail 中就可以完成测试了。

这一进步是进程隔离的开始：为每个进程隔离文件访问。所以 chroot 可以认为是容器技术的鼻祖。

（2）2000年FreeBSD 4.0发行 FreeBSD Jail

2000年，当时一家小型共享环境托管提供商提出了FreeBSD Jail，以实现其服务与其客户服务之间的明确分离，以实现安全性和易于管理。每个 Jail都是一个在主机上运行的虚拟环境，有自己的文件、进程、用户和超级用户帐户，能够为每个系统分配一个 IP 地址。

FreeBSD Jail 不仅仅有chroot的文件系统隔离，并且扩充了独立的进程和网络空间。

（3）2001年Linux VServer发行

与FreeBSD Jails一样，Linux VServer是一种监狱机制，可以对计算机系统上的资源（文件系统、网络地址、内存）进行分区。

（4）2004年Solaris Containers 发行

2004年，Solaris Containers的第一个公开测试版发布，结合系统资源控制和区域进行隔离，并添加了快照和克隆能力。

这个时期的进程隔离技术大多以 Jail模式为核心，基本实现了进程相关资源的隔离操作，没有更大的应用场景发展有限。

2、云时代

2006年，Google 101计划提出云的概念，对当前的主流开发模式产生深远的影响。也许以后我们会更多考虑如果出现比现在多1000倍, 10000倍的数据量的时候，我们该如何处理？要想让 “云” 发挥潜能，与此相关的编程和操作就应该与使用互联网一样简单。随后，亚马逊、IBM等行业巨头也陆续宣布各自的 “云” 计划，宣告 “云” 技术时代的来临。

云计算需要处理海量数据、超高并发、快速扩展等问题，此时不仅仅需要隔离还需要能够对资源进行控制和调配。

（1）2006年google推出Process Containers

Process Containers（由Google于2006年推出）旨在限制、统计和隔离一组进程的资源使用（CPU、内存、磁盘I/O、网络）。一年后它更名为 "Control Groups（cgroups）"，并最终合并到Linux内核2.6.24。

（2）2008 年LXC 推出

LXC（Linux容器）是Linux容器管理器的第一个、最完整的实现。它是在2008年使
用cgroups和Linux命名空间实现的，它可以在单个Linux内核上运行，不需要任何
补丁。

同年谷歌推出GAE（Google App Engine），首次把开发平台当做一种服务来提供，采
用云计算技术，跨越多个服务器和数据中心来虚拟化应用程序。

同时Google在GAE中使用了Borg（Kubernetes的前身）来对容器进行编排和调度。

LXC和Borg其实就相当于最早的docker和k8s.

（3）2011 年CloudFoundry 推出 Warden

2011年启动了Warden，早期使用LXC，后来替换为自己的实现，直接对Cgroups以及 Linux Namespace操作。开发了一个客户端-服务器模型来管理跨多个主机的容器集合，并且可以管理 cgroups、命名空间和进程生命周期。

（4）2013 年LMCTFY 启动

Let Me Contain That For You（LMCTFY）于2013年作为Google容器堆栈的开源版本启动，提供 Linux应用程序容器。应用程序可以 “容器感知”，创建和管理它们自己的子容器。在谷歌开始和docker合作，后续转向了docker公司的 libcontainer，LMCTFY 的于 2015年停止。

（5）2013 年Docker 推出到风靡全球

Docker最初是一个叫做dotCloud的PaaS 服务公司的内部项目，后来该公司改名为 Docker。Docker在初期与Warden类似，使用的也是LXC，之后才开始采用自己开发的 libcontainer来替代LXC，它是将应用程序及其依赖打包到几乎可以在任何服务器上运行的容器的工具。与其他只做容器的项目不同的是，Docker引入了一整套管理容器的生态系统，这包括高效、分层的容器镜像模型、全局和本地的容器注册库、清晰的 REST API、命令行等等。

Docker 为提供了一整套的解决方案，不仅解决了容器化问题，而且解决了分发问题，很快被各大厂商选择变成了云基础设施，厂商围绕 Docker也开始了生态建设。

3、云原生时代

（1）Google & Docker竞争

A. 2013年CoreOS发布和Docker由合作终止

技术革命带来新的市场机遇，CoreOS也是其中的一员，在容器生态圈中贴有标签：专为容器设计的操作系统 CoreOS。作为互补，CoreOS + Docker曾经也是容器部署的灵魂伴侣。CoreOS为Docker的推广和源码社区都做出了巨大的贡献。

Docker 生态扩张，与最开始是 “一个简单的基础单元” 不同，Docker也在通过开发或收购逐步完善容器云平台的各种组件，准备打造自己的生态圈，而这与 CoreOS的布局有直接竞争关系。

B. 2014年6月Google发布开源的容器编排引擎Kubernetes（K8S）

容器只是解决了容器化，分发问题，但是一个软件的网络问题、负载均衡问题、监控、部署、更新、镜像管理、发布等很多问题并没有有效的解决。

Google 内部调度系统Borg已经拥有10多年的使用容器经验，在2014年6月推出了开源的 K8S,可以支持对容器的编排和管理，完成生态的闭环。

同年 7月，微软、Red Hat、IBM、Docker、CoreOS、Mesosphere和Saltstack等公司，相继加入 K8S。之后的一年内，VMware、HP、Intel等公司，也陆续加入。

C. 2014年12月CoreOS发布开源容器引擎Rocket（rkt）

2014年底，CoreOS正式发布了CoreOS的开源容器引擎Rocket（简称rkt），和 Docker 正式分开发展。Google于2015年4月领投CoreOS 1200万美元，而 CoreOS 也发布了Tectonic，成为首个支持企业版本kubernetes的公司。从此，容器江湖分为两大阵营，Google派系和Docker派系。

D. 2015年Docker推出容器集群编排组件 Swarm

在Docker 1.12及更高版本中，Swarm模式与Docker引擎集成，为Docker容器提供原生集群管理功能。

两大派系的竞争愈演愈烈，行业标准的诉求越来越强烈。

E. 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等公司将方向调转到容器上面的平台层。

F. 2015年7月Google带头成立CNCF

Google联合Linux基金会成立CNCF（Cloud Native Computing Foundation）云原生计算基金会。旨在构建云原生基础设施。K8S是第一个纳入进来的项目，像后续有名的监控设施 Prometheus，配置设施ETCD都加入进来。CNCF组织解决的是应用管理及容器编排问题。和 OCI共同制定了一系列行业事实标准。

（2）k8s成为云原生事实标准

A. 2016年 发布CRI标准

Google就和红帽主导了CRI标准，用于k8s和特定的容器运行时解耦。

CRI（Container Runtime Interface 容器运行时接口）本质上就是k8s定义的一组与容器运行时进行交互的接口，所以只要实现了这套接口的容器运行时都可以对接 k8s。

但是这个适合 Docker还是事实标准，并CRI并没有话语权，但是又必须支持Docker，所以就有了 dockershim,dockershim的本质其实就是k8s对接docker的一个CRI的实现。

B. 2016年Docker捐献containerd

containerd作为运行时标准，Docker从Docker Engine种剥离出来，捐献给CNCF。这个时候 Google为了将containerd加入到cri标准中，又开发了cri-containerd，用来完成 k8s和容器之间的交互。

C. 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的企业版上去，螳臂挡车。

D. 2017年containerd确定作为标准CRI

2017年各大厂商都开始拥抱Kubernetes，亚马逊AWS，Microsoft Azure，VMware，有的甚至抛弃了自家的产品。

亚马逊网络服务（AWS）于八月份以白金会员（最高级别）加入了CNCF。

VMware都作为CNCF的白金会员注册。

Docker Inc.ocker企业版框架中添加了本地Kubernetes支持。Docker自己的Swarm 技术也借鉴了 k8s的技术进一步发展。

Kubernetes已成了容器编排领域的绝对标准，Docker已成容器事实的标准。

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

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

1、DockerClient

此时K8s只是编排领域的一个选择，而Docker此时一家独大，所以K8s的客户端只是作为 Docker的客户端来调用Docker引擎来完成服务。

2、RUNC & Shim

OCI催生runc，剥离Docker Engine的一家独大的情况，确保各个厂商都可以搭建自己的容器平台。CRI标准确立了，但是Docker并没有接入该标准。此时催生了临时技术 shim。

3、CRI-Containerd

containerd被捐献出来，谷歌开发cri-containerd接入CRI标准。

4、CRI-O

k8s已经成为事实的编排标准，促使容器回归云原生本质。

4、Containerd

containerd实现CRI，成为CRI的事实标准。

5、实际生产的集群采用的什么运行时组件

以腾讯的 TKE（腾讯商用K8S产品）为例，支持选择containerd和docker 两种模式的选择。

该如何选择呢？

1. Containerd调用链更短，组件更少，更稳定，占用节点资源更少。（建议选择 Containerd）

2. 以下情况还是要用docker：

• 使用 docker build/push/save/load等命令。
• 调用 docker API
• 需要 docker compose或docker swarm。