Docker(二) 容器技术发展史

容器技术发展史

Jail 时代

chroot

1979年, 贝尔实验室在开发UnixV7的时候, 发现一个系统软件编译和链接完成后, 整个测试环境的变量都发生变化, 下一次测试需要重新配置环境信息. 于是设计者就思考能否隔离出一个环境, 构建和搭建测试环境, 所以发明了 chroot, 可以把一个进程的文件系统隔离起来.
chroot 的本质是改变进程的根目录, 通过 chroot /newroot /bin/bash (将target作为根目录, 运行其中的/bin/bash)命令, 可以把 /newroot 改为当前进程的根目录/.
隔离以后, 该进程无法访问到 /newroot 外面的文件, 因此这个被隔离出来的新环境像监狱一样, 被命名为 Chroot Jail .后续测试只需要把测试信息放到 Jail 中就可以完成测试了.

FreeBSD Jail

2000 年, 当时一家小型共享环境托管提供商提出了 FreeBSD Jail，以实现其服务与其客户服务之间的明确分离, 每个 Jail 都是一个在主机上运行的虚拟环境, 有自己的文件、进程、用户和超级用户帐户, 能够为每个系统分配一个 IP 地址. FreeBSD Jail 不仅仅有 chroot 的文件系统隔离, 并且扩充了独立的进程和网络空间

Linux VServer(Namespace)

2001 年 Linux VServer 发行, 可以对计算机系统上的资源（文件系统、网络地址、内存）进行分区. 此时 Linux 内有一个重要的机制 Namespace 作为 VServer 项目的一部分引入, 内核版本为 Linux 2.4

Solaris Containers

2004 年 Solaris Containers 发行, 添加了快照和克隆能力

总结:这个时期的进程隔离技术大多以 Jail 模式为核心, 基本实现了进程相关资源(文件系统, 网络, 内存等) 的隔离操作, 没有更大的应用场景发展.

云时代

云的提出

2006 年, Google 101 计划提出云的概念, 对当前的主流开发模式产生深远的影响. 云是为了解决传统服务器模式难以支撑海量数据处理, 于是需要通过云计算进行分布式集群动态扩缩容 满足不同的业务场景.

“云”在这里指的是云计算, 它是一种将计算资源(如服务器、存储、网络、数据库、AI能力等) 以服务的形式通过网络提供给用户的模式, 用户无需自建机房或购买昂贵的硬件设备, 只需要像使用水、电等基础资源一样, 按需获取, 按量付费地使用计算资源, 如果我们需要指定的算力资源(比如2C16G), 我们直接向云厂商下单即可, 不需要自己去考虑搭建机房和购买硬件设施的问题.

cgroups

云计算需要处理海量数据, 超高并发, 快速扩展等问题, 此时不仅仅需要逻辑上的隔离还需要能够对资源进行控制和调配.
2006 年 Google 推出Process Containers, 其旨在限制、统计和隔离一组进程的资源使用(CPU、内存、磁盘 I/O、网络). 一年后它更名为 “cgroups”, 并最终合并到 Linux 内核 2.6.24.

LXC

2008 年 LXC 推出, LXC(Linux 容器) 是 Linux 容器管理器的第一个, 最完整的实现. 它是在 2008 年使用 cgroups + Namespace实现的, 它可以在单个 Linux 内核上运行, 不需要任何补丁.

• Namespace

Namespace 是为了隔离系统视图, 让进程以为自己拥有独立的资源, 是逻辑分离.

Namespace 类型	让进程“看到的世界”
PID	觉得自己是 PID=1，系统里只有自己
UTS	以为 hostname 就是“container-A”
Network	拥有一个独立的 eth0、IP、路由表
Mount	拥有自己的 / 根文件系统
User	UID 0（root）只在这个世界里有效
IPC	共享内存、管道只在内部世界存在

• cgroups

cgroups 是为了限制资源使用上限, 防止一个 “逻辑世界” 无限消耗"现实世界"资源, 是"物理分离"

• Linux 容器

Namespace + cgroups 结合, 才成就了真正意义上的 Linux 容器.

总结:
LXC 是 Docker 的鼻祖, Docker 最开始并没有像 LXC 一样, 重新使用 cgroups 和namespace 实现一遍, 而是基于 LXC, 对它包装了一下, 加上一些自己的理念, 发行出了Docker 这个产品.

补充:
同年谷歌推出 GAE（Google App Engine）, 首次把开发平台当做一种服务来提供, 采用云计算技术, 跨越多个服务器和数据中心来虚拟化应用程序. 同时 Google 在 GAE 中使用了 Borg (Kubernetes 的前身) 来对容器进行编排和调度.

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

Warden

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

LMCTFY

Let Me Contain That For You (LMCTFY) 于 2013 年作为 Google 容器堆栈的开源版本
启动, 简单来说是 Google 版 Docker 的早期尝试.
在 Docker及其生态崛起后, Google 不再单独发展 LMCTFY, 而是与 Docker 合作, 将技术贡献给 Docker, 推动 runC, OCI 标准 发展, 最终于2015年停止.

Docker

Docker 最初是一个叫做 dotCloud 的 PaaS 服务公司的内部项目, 后来该公司改名为
Docker. Docker 在初期与 Warden 类似, 使用的也是 LXC, 之后才开始采用自己开发的 libcontainer 来替代 LXC, 它是将应用程序及其依赖打包到几乎可以在任何服务器上运行的容器的工具.

与其他只做容器的项目不同的是, Dokcer不仅仅实现了类似容器化技术的点式技术, 它还实现了一套解决方案, 从容器隔离到镜像构建、发布、运行、部署全链路, 开发者可以“一条命令搞定”. 是一个"解决方案级别"的产品.

总结

层次：底层技术
namespace/cgroups│▼层次：平台容器/Runtime
┌───────────────┐    ┌───────────────┐
│ LMCTFY (Google)│    │ Warden (CF)   │
│ 低层 API 管理  │    │ PaaS 容器运行 │
└───────────────┘    └───────────────┘│                        │└──────────────┬─────────┘▼层次：解决方案/开发者
┌────────────────────────────────────┐
│ Docker                               │
│ namespace/cgroups 封装 + 镜像管理   │
│ CLI/工具链 + 部署                     │
└────────────────────────────────────┘│▼层次：容器编排/集群管理
┌────────────────────────────────────┐
│ Kubernetes                           │
│ 管理 Docker/OCI 容器运行时           │
│ 调度、伸缩、服务发现、集群管理       │
└────────────────────────────────────┘

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

云原生时代

云时代通过 lass+容器技术 已经解决了容器基本的打包, 服务基本的运行问题, 而云原生时代注重解决容器的管理和编排问题.
简单来说 云原生=容器化+微服务化+devops流水线自动部署 , 来构建一套像乐高积木一样可以灵活扩展的系统架构, 可以通过流水线自动交付, 让软件快速变化, 高速更新 且 稳定.

两次大战

云原生时代主要是**容器标准(OCI)和容器运行时标准(CRI)**的争夺.

第一次大战: 容器标准争夺

2013 年Docker含着金钥匙出生, 此时 CoreOS 和 Docker是灵魂伴侣, CoreOS号称专为容器设计的操作系统 CoreOS, 但Docker的生态扩张和CoreOS产生竞争, 于是两者终止合作.

2014年6月, Google 发布开源的容器编排引擎 Kubernetes, 专门为了解决容器的编排问题, 此前Google内部已经长期使用一个容器管理系统Borg, 而 K8S 只是 Google 用go语言重写了 Borg.

2014年12月, CoreOS发布新的容器引擎 Rocket. 2015年 Google 投资CoreOS发布Tectonic, 成为首个支持企业版本 kubernetes 的公司. 从此容器江湖分为两大派系: Google 派系和 Docker 派系

2015年, Docker发布容器编排组件Swarm.

第一次大战(容器大战)正式开始了

2015年6月, 为了不让Docker的容器标准一家独大, 由 Docker 公司牵头, CoreOS、 Google、 RedHat 等公司共同宣布, Docker 公司将 Libcontainer 捐出, 并改名为 RunC 项目, 交由一个完全中立的基金会管理, 然后以 RunC 为依据, 大家共同制定一套容器和镜像的标准和规范–OCI, 但是 Docker 已经是事实的容器标准. 占据了市场主导, 因此OCI并没有撼动Docker的地位, 反而 Docker 的技术成为了容器技术的标准模板.

至此第一次大战结束, Docker 胜出.

第二次大战: 容器运行时标准争夺 和 容器编排争夺

之后 Google 和 RedHat 等公司将方向调转到容器上面的平台层.

2015 年7月, Google 联合 Linux 基金会成立 CNCF.

K8S 是第一个纳入进来的项目, 像后续有名的监控设施 Prometheus, 配置设施 ETCD 都加入进来

2016年, Google 发布CRI标准, 本质上就是 k8s 定义的一组与容器运行时进行交互的接口, 所以只要实现了这套接口的容器运行时都可以对接 k8s. 但是此时 Docker 还是事实标准, 并没有接入CRI, 所以CRI 并没有话语权, 但是又必须支持 Docker, 所以就有了临时的技术dockershim, dockershim 的本质其实就是 k8s 对接 docker 的一个 CRI 的实现.

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

容器编排大战结束–K8S胜出

2016 年, Docker 公司宣布了一个震惊全部人的计划: 放弃现有的 Swarm 项目, 将 容器编排和集群管理功能所有内置到 Docker 项目中, 走"专制化"道路.
而 Kubernetes 的应对策略则是反其道而行之, 开始在整个社区推动“民主化”架构，从API 到容器运行时的每一层, Kubernetes 项目都为开发者暴露出了能够扩展的插件机制, 鼓励用户经过代码的方式介入到 Kubernetes 项目的每个阶段.
2017年以后, 更多厂商愿意把宝压在K8S身上, 投入K8S生态建设, 国产企业阿里云, 腾讯, 百度等也加入CNCF, 此时容器编排大战 K8S 胜出.

Swarm 的失败后, 社区版 Docker 项目改名为 moby, 将 Docker 引流到 Docker 的企业版上去, 螳臂挡车.

于是 K8S发布 CRI-O , 可以让开发者直接从 Kubernetes 来调用 runc 运行容器, 这意味着 Kubernetes 可以不依赖于传统的容器引擎(比如 Docker), 也能够管理容器化工作负载.

于是这就倒逼Docker公司 containd 去实现CRI标准, 2017年 containerd 确定作为标准 CRI

自此大战结束, 第一次大战的结果是 Docker的runc作为了容器标准; 第二次大战的结果是 K8S 作为容器编排标准, 而 containerd 实现 CRI 作为运行时标准.