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）