容器技术前世今生

1_1979年 — chroot

容器技术的概念可以追溯到1979年的UNIX chroot。

它是一套“UNIX操作系统”系统，旨在将其root目录及其它子目录变更至文件系统内的新位置，且只接受特定进程的访问。

这项功能的设计目的在于为每个进程提供一套隔离化磁盘空间。

1982年其被添加至BSD当中。

2_2000年 — FreeBSD Jails

FreeBSD Jails是由Derrick T. Woolworth于2000年在FreeBSD研发协会中构建而成的早期容器技术之一。

这是一套“操作系统”系统，与chroot的定位类似，不过其中包含有其它进程沙箱机制以对文件系统、用户及网络等资源进行隔离。

通过这种方式，它能够为每个Jail、定制化软件安装包乃至配置方案等提供一个对应的IP地址。

3_2001年 — Linux VServer

Linux VServer属于另一种jail机制，其能够被用于保护计算机系统之上各分区资源的安全(包括文件系统、CPU时间、网络地址以及内存等)。

每个分区被称为一套安全背景(security context)，而其中的虚拟化系统则被称为一套虚拟私有服务器。

4_2004年 — Solaris容器

Solaris容器诞生之时面向x86与SPARC系统架构，其最初亮相于2004年2月的Solaris 10 Build 51 beta当中，随后于2005年正式登陆Solaris 10的完整版本。

Solaris容器相当于将系统资源控制与由分区提供的边界加以结合。各分区立足于单一操作系统实例之内以完全隔离的虚拟服务器形式运行。

5_2005年 — OpenVZ

OpenVZ与Solaris容器非常相似，且使用安装有补丁的Linux内核以实现虚拟化、隔离能力、资源管理以及检查点交付。

每套OpenVZ容器拥有一套隔离化文件系统、用户与用户群组、一套进程树、网络、设备以及IPC对象。

6_2006年 — Process容器

Process容器于2006年由谷歌公司推出，旨在对一整套进程集合中的资源使用量(包括CPU、内存、磁盘I/O以及网络等等)加以限制、分配与隔离。

此后其被更名为Control Groups(即控制组)，从而避免其中的“容器”字眼与Linux内核2.6.24中的另一术语出现冲突。这表明了谷歌公司率先重视容器技术的敏锐眼光以及为其做出的突出贡献。

7_2007年 — Control Groups

Control Groups也就是谷歌实现的cgroups，其于2007年被添加至Linux内核当中。

8_2008年 — LXC

LXC指代的是Linux Containers

是第一套完整的Linux容器管理实现方案。

其功能通过cgroups以及Linux namespaces实现。

LXC通过liblxc库进行交付，并提供可与Python3、Python2、Lua、Go、Ruby以及Haskell等语言相对接的API。

相较于其它容器技术，LXC能够在无需任何额外补丁的前提下运行在原版Linux内核之上。

9_2011年 — Warden

Warden由CloudFoundry公司于2011年所建立，其利用LXC作为初始阶段，随后又将其替换为自家实现方案。

与LXC不同，Warden并不会与Linux紧密耦合。

相反，其能够运行在任意能够提供多种隔离环境方式的操作系统之上。

Warden以后台进程方式运行并提供API以实现容器管理。

10_2013年 — LMCTFY

Lmctfy代表的是“Let Me Contain That For You(帮你实现容器化)”。

它其实属于谷歌容器技术堆栈的开源版本，负责提供Linux应用程序容器。

谷歌公司在该项目的起步阶段宣称其能够提供值得信赖的性能表现、高资源利用率、共享资源机制、充裕的发展空间以及趋近于零的额外资源消耗。

2013年10月lmctfy的首个版本正式推出，谷歌公司在2015年决定将lmctfy的核心概念与抽象机制转化为libcontainer。

在失去了主干之后，如今lmctfy已经失去一切积极的发展势头。

Libcontainer项目最初由Docker公司建立，如今已经被归入开放容器基金会的管辖范畴。

11_2013年 — Docker

在2013年Docker刚发布的时候，它是一款基于LXC的开源容器管理引擎。

把LXC复杂的容器创建与使用方式简化为Docker自己的一套命令体系。

随着Docker的不断发展，它开始有了更为远大的目标，那就是反向定义容器的实现标准，将底层实现都抽象化到Libcontainer的接口。

这就意味着，底层容器的实现方式变成了一种可变的方案，无论是使用namespace、cgroups技术抑或是使用systemd等其他方案，只要实现了Libcontainer定义的一组接口，Docker都可以运行。

这也为Docker实现全面的跨平台带来了可能。

12_Docker Hub

Docker Hub 是 Docker 官方推出的容器镜像仓库，旨在为开发者提供一个集中的公共存储库来存放和共享 Docker 镜像。

Docker Hub 的推出使得开发人员能够快速地上传、下载和分享容器镜像，大大简化了容器的分发和管理过程。

Docker Hub 提供了数千个官方和社区镜像，包括操作系统镜像、数据库镜像、编程语言环境镜像等。

用户可以通过 Docker Hub 提供的 API 进行自动化操作，同时也可以直接使用命令行工具 docker pull 来从 Docker Hub 拉取镜像，或者通过 docker push 上传镜像。

影响：

Docker Hub 的推出推动了容器技术的普及，提供了一个标准化的镜像仓库，使得镜像的创建、管理和共享变得更加高效。

随着时间的推移，Docker Hub 逐渐成为了容器生态系统的核心组成部分。

13_Docker Compose

Docker Compose 是一个用于定义和运行多容器 Docker 应用的工具。

它允许用户通过一个配置文件（docker-compose.yml）来定义多个服务，并通过一个简单的命令启动所有相关容器。

Compose 文件中定义的每个服务都可以包含镜像、网络、存储卷等配置信息。

它让用户能够以一种声明性的方式来描述和管理应用中的多个容器及其关系。

影响：

Docker Compose 使得多容器应用的部署更加简洁和高效，特别适用于微服务架构和开发环境中的容器编排。

开发者可以使用 Compose 快速地搭建复杂的开发环境，并轻松切换不同的环境配置。

14_ Docker Desktop for Mac 和 Windows

Docker Desktop 是 Docker 官方提供的针对 Mac 和 Windows 平台的容器开发工具，它集成了 Docker Engine、Docker Compose、Docker CLI 等工具，允许开发者在本地环境中构建、测试和运行容器化应用。

Docker Desktop 通过虚拟化技术在非 Linux 系统上模拟 Docker 引擎，使得开发者能够在不同操作系统上无缝使用 Docker。

影响：

Docker Desktop 为开发人员提供了一个简洁易用的本地容器开发环境，它成为了跨平台容器开发的重要工具。

开发者可以在 Mac 和 Windows 上开发、测试并调试容器应用，然后无缝地将应用部署到生产环境中的 Linux 系统。

15_2014年 — Kubernetes

2013 年 docker 公司在推出 docker 产品后，由于其对全球技术产生了一定的影响力，Google公司明显感觉到自己内部所使用的Brog系统江湖地位受到威胁；

希望Docker公司能够与自己联合打造一款开源的容器运行时作为Docker核心依赖，但Docker公司拒绝了。

为了进一步遏制Docker在未来技术市场影响力，避免在容器市场上Docker一家独大，Google公司带领导RedHat、IBM等成立了CNCF(Cloud Native Computing Fundation)基金会，即云原生计算基金会。

CNCF的目标很明确，既然在容器应用领域无法与Docker相抗衡，那就做Google更有经验的技术市场——大规模容器编排应用场景。

Google公司把自己内部使用的 Brog 系统开源——Kubernetes，也就是我们今天所说的云原生技术生态。

Kubernetes 是由 Google 贡献并由 Cloud Native Computing Foundation (CNCF) 管理的开源容器编排平台。

Kubernetes 旨在自动化容器化应用的部署、扩展和管理。

它支持跨主机管理容器集群，提供服务发现、负载均衡、自动扩展、容错等功能。

影响：

Kubernetes 被认为是现代云原生架构的核心组件之一。

它的出现使得容器编排变得更加标准化，解除了开发者和运维人员在大规模容器管理中的困扰，并加速了微服务架构的普及。

16_2015年 — OCI 规范

Open Container Initiative（OCI）是一个开放标准项目，旨在制定容器镜像格式和容器运行时的规范。

OCI 规范由 Docker、CoreOS 和其他多个开源项目联合创建，目标是确保容器镜像和运行时的互操作性。

OCI 定义了两个核心规范：

1. OCI 镜像规范：定义了容器镜像的格式，以确保不同容器工具和平台可以共享和运行相同的镜像。

2. OCI 运行时规范：定义了如何运行容器，包括启动、停止、资源限制等操作。

影响：

OCI 规范使得容器镜像格式和运行时的标准化成为可能，它消除了不同容器平台之间的兼容性问题。

随着 OCI 规范的推广，容器技术逐渐走向开放、可互操作的生态。

17_2016年 — Docker Swarm

Docker Swarm 是 Docker 官方提供的容器编排工具，它允许用户以集群模式运行多个 Docker 主机上的容器，并提供高可用性、负载均衡、自动扩展等功能。

Swarm 与 Kubernetes 类似，但其更加紧密集成于 Docker 环境中，适用于希望使用 Docker 原生功能而无需额外学习其他工具的用户。

Swarm 提供了简单的命令行接口，用户可以很容易地管理 Docker 集群，进行容器的部署、扩展和滚动更新。

影响：

虽然 Kubernetes 最终成为容器编排的行业标准，但 Docker Swarm 仍然为一些小型和中型项目提供了简便的容器编排解决方案。

Swarm 与 Docker 的紧密集成使得它在简单的容器编排需求中仍然具有一定的竞争力，但是最终以 Kubernetes 胜出。

18_2017年 — Containerd

Containerd 是一个高性能的容器运行时，专注于容器的生命周期管理，包括镜像拉取、容器创建、运行、停止以及删除等。

它原本是 Docker 的一部分，后来被剥离并成为一个独立的项目，由 CNCF 管理。

Containerd 提供了一组 API 和功能，使得开发人员能够创建自己的容器引擎，或者在现有的容器平台上实现容器管理功能。

2016年Docker公司推出了Docker Swarm，意在一统Docker生态，让Docker既可以实现容器应用管理，也可以实现大规模容器编排。

经过近1年左右时间的市场验证后，发现在容器编排方面无法独立抗衡kubernetes。

所以Docker公司于2017年正式宣布原生支持Kubernetes，至此，Docker在大规模容器编排应用市场败下阵来。

但是Docker依然不甘心失败，把Docker核心依赖 Containerd 捐给了CNCF，依此说明Docker依旧是一个PaaS平台。

2020年CNCF基金会宣布Kubernetes 1.20版本将不再仅支持Docker容器管理工具，此事的起因主要也与Docker捐给CNCF基金会的Containerd有关。

早期为了实现Kubernetes能够使用Docker实现容器管理，专门在Kubernetes组件中集成一个shim（垫片）技术，用来将Kubernetes容器运行时接口（CRI，Container Runntime Interface）调用翻译成Docker的API。

这样就可以很好地使用Docker了，但是随着Kubernetes在全球技术市场的广泛应用，有更多的容器管理工具的出现，它们都想能够借助于Kubernetes被用户所使用。

所以就提出标准化容器运行时接口，只要适配了这个接口就可以集成到Kubernetes生态当中，所以Kubernetes取消了对shim的维护。

并且由于Containerd技术的成功，可以实现无缝对接Kubernetes，所以接下来Kubernetes容器运行时的主角是Containerd。

影响：

Containerd 的独立性使得它成为容器技术的关键基础设施组件，它不仅为 Kubernetes 提供了容器运行时，还被其他容器平台（如 Docker、K3s、CRI-O）广泛使用。

Containerd 提供了一个轻量级的、标准化的容器管理接口，有助于容器生态的进一步发展。

19_2019年 — Podman

Podman 是由 Red Hat 提供的一个开源容器管理工具，它支持容器和容器集群的管理。

与 Docker 类似，Podman 提供了类似的命令行接口，但与 Docker 的不同之处在于，Podman 不依赖守护进程（Daemon）。

这使得 Podman 成为更加安全和灵活的容器管理工具。

Podman 还提供了对 Docker 镜像和容器的兼容性支持，用户可以轻松地将现有的 Docker 项目迁移到 Podman。

影响：

Podman 的推出为容器技术提供了一个新的选择，尤其是在没有 Docker Daemon 的安全环境下。

它的无守护进程设计使得它在 Kubernetes、CI/CD 等自动化环境中有了新的应用场景。

20_总结

容器技术自1979年UNIX的 chroot 起步，经历了多个阶段的演化。从最初的资源隔离到现在的全面容器化生态，容器技术已经成为现代软件开发和部署的基础设施之一。随着 Kubernetes、Docker 和相关技术的广泛采用，容器化正在加速云原生应用和微服务架构的普及，推动着开发、运维和运作模式的变革。