40 年回顾，一文读懂容器发展史

随着云计算的发展，容器的使用越来越广泛。最近几年，越来越多的企业开始采用容器作为新的 IT 基础设施。如果我们回顾历史，容器早在 20 世纪 70 年代末就已出现雏形。Jails、Zones、VPS、VM 和容器都是为了隔离和资源控制，但每种技术是通过不同的方式实现，每种方式都有其局限性和优势。

1979 年：Unix V7

这个年代，计算资源匮乏，想要通过快速销毁和重建基础设施来解决测试环境污染问题变得几乎不可能。为隔离出可供软件进行构建和测试的环境，chroot（change root）系统调用程序横空出现。

在 1979 年 Unix V7 的开发过程中，正式引入 chroot 系统调用，为每个进程提供一个独立的磁盘空间，将一个进程及其子进程的根目录改变到文件系统中的新位置，让这些进程只能访问到该目录。这个被隔离出来的新环境被叫做 Chroot Jail。这标志着进程隔离的开始，隔离每个进程的文件访问权限。

如下图所示，贝尔实验室正在为 Unix V7 操作系统的发布进行最后的开发和测试工作。

2000 年：FreeBSD Jails

2000 年，FreeBSD 操作系统正式发布 FreeBSD jails 隔离环境，真正意义上实现进程的沙箱化。这为文件系统、用户、网络等隔离增加了进程沙盒功能，实现了客户服务之间的隔离和管理。

据悉，这种沙箱的实现，依靠操作系统级别的隔离与限制能力而非硬件虚拟化技术。FreeBSD Jails 允许管理员将 FreeBSD 计算机系统划分为几个独立的、较小的系统，称为“ jails”，并能为每个系统和配置分配 IP 地址，可以对软件的安装和配置进行定制。

2001 年：LinuxVServer

与 FreeBSD Jails 一样，Linux VServer 也是采取一种类似的上述 Jails 机制，它可以对计算机系统上的资源（文件系统、网络地址、内存）进行分区。每个所划分的区域叫做一个安全上下文（security context），其中的虚拟系统叫做虚拟私有服务器（virtual private server，VPS）。该操作系统虚拟化于 2001 年推出，通过修补 Linux 内核来实现，测试性补丁目前仍然可用，但最后一个稳定的修补程序是 2006 年发布。

2004 年：Solaris 容器

2004 年 2 月，Oracle 发布 Oracle Solaris Containers，这是一个用于 X86 和 SPARC 处理器的 Linux-Vserver 版本。Solaris Container 是由系统资源控制和通过 zones 提供的边界分离（boundary separation）所组合而成的。zones 是一个单一操作系统实例中的完全隔离的虚拟服务器。

2005 年：Open VZ（Open Virtuzzo）

这是 Linux 操作系统级虚拟化技术，它通过 Linux 内核补丁形式进行虚拟化、隔离、资源管理和状态检查。

操作系统级虚拟化有一些限制，因为容器共享相同的体系结构和内核版本，当客户需要不同于主机的内核版本情况下，这种缺点就会显现出来。该代码未作为正式 Linux 内核的一部分发布。每个 OpenVZ 容器都有一套隔离的文件系统、用户、用户组、进程树、网络、设备和 IPC 对象。

2006 年：Process Containers

Process Containers（由 Google 在 2006 年推出）旨在用于限制、计算和隔离一系列流程的资源使用（CPU、内存、磁盘 I / O、网络）。

一年后，为了避免和 Linux 内核上下文中的“容器”一词混淆而改名为 ControlGroups 简称 Cgroups，并最终合并到 Linux 内核 2.6.24 中。

这也可以说明 Google 很早就参与了容器技术的开发。

2008 年：LXC

Linux 容器（LXC）是第一个、最完整的 Linux 容器管理器的实现方案。2008 年，通过将 Cgroups 的资源管理能力和 Linux Namespace 的视图隔离能力组合在一起，LXC 完整的容器技术出现在 Linux 内核中，并且可以在单个 Linux 内核上运行而无需任何补丁。

LXC 存在于 liblxc 库中，提供各种编程语言的 API 实现，包括 Python3、Python2、Lua、Go、Ruby 和 Haskell。现在 LXC project 由 Canonical 公司赞助并托管的。

2011 年：Warden

Warden 由 CloudFoundry 在 2011 年成立，这是一个管理隔离、短暂存在和被资源控制的环境的 API。在其第一个版本中，Warden 使用 LXC，之后替换为他们自己的实现方案。

不像 LXC，Warden 并不紧密耦合到 Linux 上，可以为任何系统提供隔离运行环境。Warden 以后台保护程序运行，而且能提供用于容器管理的 API。它开发了一个 CS（客户端-服务端）模型来管理跨多个主机的容器集群，并且 Warden 提供用于管理 cgroup、名称空间和进程生命周期的相关服务。

2013 年：LMCTFY

LMCTFY 是 2013 年 Google 容器技术的开源版本，它提供 Linux 应用程序容器，旨在提供性能可保证的、高资源利用率的、资源共享的、可超售的、接近零消耗的容器。

2015 年，Google 开始向由 Docker 发起的 Libcontainer 贡献 LMCTFY 核心概念后，LMCTFY 在 2015 年主动停止部署，Libcontainer 现在是 Open Container Foundation（开放容器基金会）的一部分。

2013 年：Docker

2013 年，随着 Docker 的出现，容器开始迅速普及。

它最初是一个叫做 dotCloud 的 PaaS 服务公司的内部项目，后来该公司改名为 Docker。Docker 的迅速普及并非偶然，它引入了一整套管理容器的生态系统，包括高效、分层的容器镜像模型、全局和本地的容器注册库、清晰的 REST API、命令行等。

与 Warden 一样，Docker 最初阶段使用的也是 LXC，后来用自己的库 libcontainer 进行替换。Docker 推动实现了一个叫做 Docker Swarm 的容器集群管理方案。

2014 年：Rocket

Rocket 是由 CoreOS 所启动的项目，类似于 Docker，但是其修复了一些 Docker 中发现的问题。

CoreOS 的初衷是旨在提供一个比 Docker 更严格的安全性和产品需求。更重要的是，它是在一个更加开放的标准 AppContainer 规范上实现的。在 Rocket 之外，CoreOS 也开发了其它几个可用于 Docker 和 Kubernetes 容器相关的产品，例如，CoreOS 操作系统、etcd 和 flannel。

2016 年：Windows Containers

2015 年，微软在 Windows Server 上为基于 Windows 的应用添加了容器支持，称之为 Windows Containers。它与 Windows Server 2016 一同发布，Docker 可以原生地在 Windows 上运行 Docker 容器，而不需要启动一个虚拟机来运行 Docker（ Windows 上早期运行 Docker 需要使用 Linux 虚拟机）。

2017 年：容器工具日趋成熟

在 2017 年以前，市场上已经有上百种工具用来管理容器，这些类型的工具已存在多年。

但是，2017 年许多工具脱颖而出，最知名的是 Kubernetes。自从 2016 年被纳入 CNCF 以来，VMWare、Azure、AWS甚至Docker都宣布在其基础架构上提供相关支持。

随着容器市场的发展，一些工具已经开始定义容器的某些功能。Ceph和REX-Ray为容器存储设定了标准，在CI / CD中，Jenkins完全改变了构建和部署应用程序的方式。

2017 年，CoreOS 和 Docker 联合提议将 rkt 和 containerd 作为新项目纳入 CNCF，这标志着容器生态系统初步形成，容器项目之间协作更加丰富。

从 Docker 最初宣布将剥离其核心运行时到 2017 年捐赠给 CNCF 协会，“containerd”项目在过去两年经历显著增长。Docker 捐赠的主要目的是通过提供一个核心容器运行时来促进容器生态系统的进一步创新，容器系统供应商和编排项目(如 Kubernetes、Swarm 等)可以利用这个核心容器运行时。

“containerd”的一个重要设计原则是可以对 Kubernetes 提供一流支持，但又不完全依赖于 Kubernetes，这也为许多容器的用例打开新大门，如 developer desktop、CI/CD、单节点部署、edge 和物联网等。

2018 年：规范化向前发展

容器化成为现代软件基础架构的基础。众所周知，Kubernetes 也被用于大多数企业容器项目。

2018 年，GitHub 上的 Kubernetes 项目有 27000 多个 Star，1500 多个贡献者，成为最重要的开源社区之一。

Kubernetes 的广泛采用推动了诸如 AWS 云供应商提供托管的 Kubernetes 服务。

此外，VMWare、RedHat 和 Rancher 等领先的软件供应商也开始提供基于 Kubernetes 的管理平台。

2019 年：历史变革

2019 年是容器发生历史性变革的一年。

这一年发生许多历史性变革事件，包括容器生态变化、产业资本并购和出现新技术解决方案等。

在 2019 年，新的运行时引擎开始替代 docker 运行引擎，其最具代表性的新引擎就是 CNCF 的 Containerd 和CRI-O（一个用于 Kubernetes 的轻量级运行时）。CRI-O 能让用户直接从 Kubernetes 运行容器，而无需任何不必要的代码或工具。只要容器符合 OCI 标准，CRI-O 就可以运行它。

在 2019 年，产业方面也发送巨大变化，DockerEnterprise 卖给 Mirantis（一家专注于 OpenStack、Kubernetes 的云计算公司），可以预见的是 Docker Swarm 将逐步被淘汰。

同时，虽然 rkt 已经正式成为 CNCF 一部分，但是其普及率正在、逐步下降。此外，VMware 先后收购 Heptio 和Pivotal Software（包括 PAS 和 PKS），此举可以帮助企业客户更好建立并运行基于 Kubernetes 的容器化架构。其中，Heptio 公司是由两位曾在 2014 年帮助谷歌联合建立 Kubernetes 项目的主力（当时的项目负责人共有三名）共同建立，创始人及其团队都将一同加盟 VMware 公司。如此清晰的创始人背景，可能意味着 VMware 有意在 Kubernetes 领域发动全面冲击，甚至预示 VMware 已经把 Kubernetes 视为企业业务运营的根本性基石之一。

2019 年，容器技术领域也出现新变革，函数即服务（‘函数’或者‘无服务器’）已经成为一种新的抽象趋势。其允许开发人员更轻松地运行并部署代码片段，且这些代码片段将能快速实现规模伸缩以响应事件需求。

例如，企业只要使用由 Google 与 Pivotal、IBM、红帽和 SAP 等企业共同开发的跨云 Serverless 管理平台 Knative，就能在支持 Kubernetes 的云平台上自由的迁移工作负载，无论是跨私有云或是公有云及各种混合云架构都没问题。

2019 年也出现了基于 Kubernetes -混合云解决方案，如 IBM CloudPaks、谷歌Anthos，AWS Outposts、和Azure Arc。这些云平台模糊了云环境与本地环境之间的传统界限，可以更方便管理本地和供应商云服务。

Kubernetes 已经成为构建容器化平台体系的默认抽象方案，上诉这些新功能的出现也代表着 Kubernetes 的下一步演进方向，诸如 Anthos、Arc 和 Outposts 之类超抽象。在超抽象中，计算资源从管理层解耦，类似于 Kubernetes 的工作方式，它将工作负载从管理层解耦。

2020：容器安全成为新挑战

作为一种轻量级的虚拟化技术，容器使用方便、操作便捷，大大提高开发人员的工作效率，并得到业内的广泛使用。但与此同时，容器安全事故频发，包括不安全的镜像源、容器入侵事件、运行环境的安全问题等等。

1.不安全的镜像源

开发者通常会在 Docker 官方的 Docker Hub 仓库下载镜像，这些镜像一部分来源于开发镜像内相应软件的官方组织，还有大量镜像来自第三方组织甚至个人。从这些镜像仓库中获取镜像的同时，也带来潜在的安全风险。例如，下载镜像内软件本身是否就包含漏洞，下载的镜像是否被恶意植入后门，镜像在传输过程中是否被篡改。

2.容器入侵事件

由 docker 本身的架构与机制可能产生的问题，这一攻击场景主要产生在黑客已经控制了宿主机上的一些容器（或者通过在公有云上建立容器的方式获得这个条件），然后对宿主机或其他容器发起攻击来产生影响。

3.运行环境的安全

除 docker 本身存在的问题外，docker 运行环境存在的问题同样给 docker 的使用带来风险。

由于容器是介于基础设施和平台之间的虚拟化技术，因此面向基础设施虚拟化的传统云安全解决方案无法完全解决前述安全问题。如以容器为支撑技术构建 DevOps 环境，就需要设计涵盖从容器镜像的创建到投产上线的整个生命周期的容器安全方案。

（本文转自 freebuf.com）