圖1：Unix操作系統(tǒng)測(cè)試

2000年：FreeBSD Jails

在2000年，F(xiàn)reeBSD操作系統(tǒng)正式發(fā)布FreeBSD jails隔離環(huán)境，真正意義上實(shí)現(xiàn)了進(jìn)程的沙箱化。這為文件系統(tǒng)、用戶、網(wǎng)絡(luò)等隔離增加了進(jìn)程沙盒功能，實(shí)現(xiàn)了客戶服務(wù)之間的隔離和管理。

這種沙箱的實(shí)現(xiàn)，依靠的是操作系統(tǒng)級(jí)別的隔離與限制能力而非硬件虛擬化技術(shù)。FreeBSD Jails允許管理員將FreeBSD計(jì)算機(jī)系統(tǒng)劃分為幾個(gè)獨(dú)立的、較小的系統(tǒng)，稱為“jails”，并能夠?yàn)槊總€(gè)系統(tǒng)和配置分配IP地址，可以對(duì)軟件的安裝和配置進(jìn)行定制。

2001年：LinuxVServer

與FreeBSD Jails一樣，Linux VServer也是一種類似上述Jails機(jī)制，可以對(duì)計(jì)算機(jī)系統(tǒng)上的資源(文件系統(tǒng)，網(wǎng)絡(luò)地址，內(nèi)存)進(jìn)行分區(qū)。每個(gè)所劃分的分區(qū)叫做一個(gè)安全上下文(security context)，在其中的虛擬系統(tǒng)叫做虛擬私有服務(wù)器(virtualprivate server，VPS)。該操作系統(tǒng)虛擬化于2001年推出，通過(guò)修補(bǔ)Linux內(nèi)核來(lái)實(shí)現(xiàn)，測(cè)試性補(bǔ)丁目前仍然可用，但最后一個(gè)穩(wěn)定的修補(bǔ)程序于2006年發(fā)布。

2004年：Solaris容器

2004年2月，Oracle發(fā)布了Oracle Solaris Containers，這是一個(gè)用于X86和SPARC處理器的Linux-Vserver版本。Solaris Container是由系統(tǒng)資源控制和通過(guò)zones提供的邊界分離(boundary separation)所組合而成的。zones是一個(gè)單一操作系統(tǒng)實(shí)例中的完全隔離的虛擬服務(wù)器。

2005年：Open VZ(Open Virtuzzo)

這是Linux操作系統(tǒng)級(jí)虛擬化技術(shù)，它通過(guò)Linux內(nèi)核補(bǔ)丁形式進(jìn)行虛擬化、隔離、資源管理和狀態(tài)檢查。操作系統(tǒng)級(jí)虛擬化有一些限制，因?yàn)槿萜鞴蚕硐嗤捏w系結(jié)構(gòu)和內(nèi)核版本，當(dāng)客戶需要不同于主機(jī)的內(nèi)核版本的情況下這種缺點(diǎn)就會(huì)顯現(xiàn)出來(lái)。該代碼未作為正式Linux內(nèi)核的一部分發(fā)布。每個(gè)OpenVZ容器都有一套隔離的文件系統(tǒng)、用戶及用戶組、進(jìn)程樹、網(wǎng)絡(luò)、設(shè)備和IPC對(duì)象。

2006年：Process Containers

Process Containers(由Google在2006年推出)旨在用于限制，計(jì)算和隔離一系列流程的資源使用(CPU、內(nèi)存、磁盤I/O、網(wǎng)絡(luò))。一年后，為了避免和Linux內(nèi)核上下文中的“容器”一詞混淆而改名為ControlGroups簡(jiǎn)稱Cgroups，并最終合并到Linux內(nèi)核2.6.24中。這也可以說(shuō)明Google很早就參與了容器技術(shù)的開發(fā)。

2008年：LXC

Linux容器(LXC)是第一個(gè)、最完整的Linux容器管理器的實(shí)現(xiàn)方案。2008年時(shí)候，通過(guò)將Cgroups的資源管理能力和Linux Namespace的視圖隔離能力組合在一起，LXC完整的容器技術(shù)出現(xiàn)在了Linux內(nèi)核當(dāng)中，并且可以在單個(gè)Linux內(nèi)核上運(yùn)行而無(wú)需任何補(bǔ)丁。

LXC存在于liblxc庫(kù)中，提供了各種編程語(yǔ)言的API實(shí)現(xiàn)，包括Python3、Python2、Lua、Go、Ruby和Haskell?，F(xiàn)在LXC project是由Canonical公司贊助并托管的。

2011年：Warden

Warden是由CloudFoundry在2011年成立，這是一個(gè)管理隔離，短暫存在和被資源控制的環(huán)境的API。在其第一個(gè)版本中，Warden使用了LXC，之后替換為他們自己的實(shí)現(xiàn)方案。不像LXC，Warden并不緊密耦合到Linux上，可以為任何系統(tǒng)提供隔離運(yùn)行環(huán)境。Warden以后臺(tái)保護(hù)程序運(yùn)行，而且能夠提供用于容器管理的API。它開發(fā)了一個(gè)CS(客戶端-服務(wù)端)模型來(lái)管理跨多個(gè)主機(jī)的容器集群，并且Warden提供用于管理cgroup，名稱空間和進(jìn)程生命周期的相關(guān)服務(wù)。

2013年：LMCTFY

LMCTFY是2013年Google容器技術(shù)的開源版本開始，提供Linux應(yīng)用程序容器，旨在提供性能可保證的、高資源利用率的、資源共享的、可超售的、接近零消耗的容器。

在2015年，Google開始向由Docker發(fā)起的Libcontainer貢獻(xiàn)LMCTFY核心概念之后，LMCTFY在2015年主動(dòng)停止部署，Libcontainer現(xiàn)在是Open Container Foundation(開放容器基金會(huì))的一部分。

2013年：Docker

隨著2013年Docker的出現(xiàn)，容器開始迅速普及。它最初是一個(gè)叫做dotCloud的PaaS服務(wù)公司的內(nèi)部項(xiàng)目，后來(lái)該公司改名為Docker。Docker的增長(zhǎng)并非偶然，它引入了一整套管理容器的生態(tài)系統(tǒng)，包括高效、分層的容器鏡像模型、全局和本地的容器注冊(cè)庫(kù)、清晰的REST API、命令行等。

跟Warden一樣，Docker開始階段使用的也是LXC，后來(lái)用自己的庫(kù)libcontainer進(jìn)行替換。Docker推動(dòng)實(shí)現(xiàn)了一個(gè)叫做Docker Swarm的容器集群管理方案。

2014年：Rocket

Rocket是由CoreOS所啟動(dòng)的項(xiàng)目，非常類似于Docker，但是修復(fù)了一些Docker中發(fā)現(xiàn)的問(wèn)題。CoreOS初衷是旨在提供一個(gè)比Docker更嚴(yán)格的安全性和產(chǎn)品需求。更重要的是，它是在一個(gè)更加開放的標(biāo)準(zhǔn)AppContainer規(guī)范上實(shí)現(xiàn)的。在Rocket之外，CoreOS也開發(fā)了其它幾個(gè)可以用于Docker和Kubernetes的容器相關(guān)的產(chǎn)品，如：CoreOS操作系統(tǒng)、etcd和flannel。

2016年：Windows Containers

2015年，微軟在Windows Server上為基于Windows的應(yīng)用添加了容器支持，稱之為Windows Containers。它與Windows Server 2016一同發(fā)布，Docker可以原生地在Windows上運(yùn)行Docker容器，而不需要啟動(dòng)一個(gè)虛擬機(jī)來(lái)運(yùn)行Docker(Windows上早期運(yùn)行Docker需要使用Linux虛擬機(jī))。

2017年：容器工具日趨成熟

在2017年以前，市場(chǎng)上已經(jīng)有上百種工具用來(lái)管理容器，這些類型的工具已經(jīng)存在多年了，但2017年是其中許多工具脫穎而出的一年。例如Kubernetes，自2016年被納入Cloud Native Computing Foundation(CNCF)以來(lái)，VMWare，Azure，AWS甚至Docker都宣布在其基礎(chǔ)架構(gòu)之上提供相關(guān)支持。

隨著容器市場(chǎng)的發(fā)展和增長(zhǎng)，一些工具已經(jīng)開始定義容器的某些功能。Ceph和REX-Ray為容器存儲(chǔ)設(shè)定了標(biāo)準(zhǔn)，在CI/CD中，Jenkins完全改變了構(gòu)建和部署應(yīng)用程序的方式。

隨著2017年，CoreOS和Docker聯(lián)合提議將rkt和containerd作為新項(xiàng)目納入CNCF，這標(biāo)志容器生態(tài)系統(tǒng)初步形成，容器項(xiàng)目之間協(xié)作更加豐富。

從Docker最初宣布將剝離其核心運(yùn)行時(shí)到2017年捐贈(zèng)給CNCF協(xié)會(huì)，“containerd”項(xiàng)目在過(guò)去兩年經(jīng)歷了顯著的增長(zhǎng)和進(jìn)步。Docker捐贈(zèng)的主要目的是通過(guò)提供一個(gè)核心容器運(yùn)行時(shí)來(lái)促進(jìn)容器生態(tài)系統(tǒng)的進(jìn)一步創(chuàng)新，容器系統(tǒng)供應(yīng)商和編排項(xiàng)目(如Kubernetes、Swarm等)可以利用這個(gè)核心容器運(yùn)行時(shí)?！癱ontainerd”的一個(gè)重要設(shè)計(jì)原則是可以對(duì)Kubernetes提供一流的支持，但又不完全依賴于Kubernetes，這也為許多容器的用例如developer desktop、CI/CD、單節(jié)點(diǎn)部署、edge和物聯(lián)網(wǎng)打開了新的大門。

2018年：越來(lái)越規(guī)范

容器化成為現(xiàn)代軟件基礎(chǔ)架構(gòu)的基礎(chǔ)，而Kubernetes被用于大多數(shù)企業(yè)容器項(xiàng)目。在2018年，GitHub上的Kubernetes項(xiàng)目有1500多個(gè)貢獻(xiàn)者，是最重要的開源社區(qū)之一，擁有27000多顆星。

Kubernetes的廣泛采用推動(dòng)了諸如AWS云供應(yīng)商提供托管的Kubernetes服務(wù)。此外，VMWare，RedHat和Rancher等領(lǐng)先的軟件供應(yīng)商也開始提供基于Kubernetes的管理平臺(tái)。

2019年：歷史變革

2019年是容器發(fā)生歷史性變革的一年，在這一年發(fā)生了很多歷史性變革事件，包括容器生態(tài)變化、產(chǎn)業(yè)資本并購(gòu)、新技術(shù)解決方案出現(xiàn)等等。

在這一年新的運(yùn)行時(shí)引擎開始替代docker運(yùn)行引擎，其最具代表性新引擎就是CNCF的Containerd和CRI-O(一個(gè)用于Kubernetes的輕量級(jí)運(yùn)行時(shí))。CRI-O可以讓用戶直接從Kubernetes運(yùn)行容器，而不需要任何不必要的代碼或工具。只要容器符合OCI標(biāo)準(zhǔn)，CRI-O就可以運(yùn)行它。

在2019年，產(chǎn)業(yè)方面也發(fā)送了巨大變化，DockerEnterprise賣給了Mirantis(一家專注于OpenStack、Kubernetes的云計(jì)算公司)，可以預(yù)見(jiàn)的是Docker Swarm將逐步被淘汰。同時(shí)，也可以看到雖然rkt已經(jīng)正式成為CNCF一部分但是其普及率正在逐步下降。此外，VMware先后收購(gòu)了Heptio和Pivotal Software(包括PAS和PKS)，此舉可以更好幫助企業(yè)客戶建立并運(yùn)行基于Kubernetes的容器化架構(gòu)。其中Heptio公司是由兩位曾在2014年幫助谷歌聯(lián)合建立Kubernetes項(xiàng)目的主力(當(dāng)時(shí)的項(xiàng)目負(fù)責(zé)人共有三名)共同建立，創(chuàng)始人及其團(tuán)隊(duì)都將一同加盟VMware公司。如此清晰的創(chuàng)始人背景，可能意味著VMware有意在Kubernetes領(lǐng)域發(fā)動(dòng)全面沖擊，甚至預(yù)示VMware已經(jīng)把Kubernetes視為企業(yè)業(yè)務(wù)運(yùn)營(yíng)的根本性基石之一。

2019年容器技術(shù)領(lǐng)域也出現(xiàn)了新的變革，函數(shù)即服務(wù)(‘函數(shù)’或者‘無(wú)服務(wù)器’)已經(jīng)成為一種新的抽象趨勢(shì)。其允許開發(fā)人員更輕松地運(yùn)行并部署代碼片段，且這些代碼片段將能夠快速實(shí)現(xiàn)規(guī)模伸縮以響應(yīng)事件需求。例如，企業(yè)只要使用由Google與Pivotal、IBM、紅帽和SAP等企業(yè)共同開發(fā)的跨云Serverless管理平臺(tái)Knative，就能在支持Kubernetes的云平臺(tái)上自由的遷移工作負(fù)載，無(wú)論是跨私有云或是公有云及各種混合云架構(gòu)都沒(méi)問(wèn)題。

圖2：盡可能使用最高的抽象

2019也出現(xiàn)了基于Kubernetes-混合云解決方案，如IBM CloudPaks，谷歌Anthos，AWS Outposts，和Azure Arc。這些云平臺(tái)模糊了云環(huán)境與本地環(huán)境之間的傳統(tǒng)界限，可以更方便管理本地和供應(yīng)商云服務(wù)。

Kubernetes現(xiàn)在已經(jīng)成為了構(gòu)建容器化平臺(tái)體系的默認(rèn)抽象方案，上述這些新功能的出現(xiàn)也代表著Kubernetes下一步演進(jìn)方向，諸如Anthos，Arc和Outposts之類超抽象。在超抽象中，計(jì)算資源從管理層解耦，類似于Kubernetes的工作方式，它將工作負(fù)載從管理層解耦。

2020年：容器安全亟待解決

容器作為一種輕量級(jí)的虛擬化技術(shù)，使用方便，操作便捷，大大提高了開發(fā)人員的工作效率，得到了業(yè)內(nèi)的廣泛使用。但與此同時(shí)，容器安全事故頻發(fā)，包括不安全的鏡像源、容器入侵事件、運(yùn)行環(huán)境的安全問(wèn)題等等。

• 不安全的鏡像源，開發(fā)者通常會(huì)在Docker官方的Docker Hub倉(cāng)庫(kù)下載鏡像，這些鏡像一部分來(lái)源于開發(fā)鏡像內(nèi)相應(yīng)軟件的官方組織，還有大量鏡像來(lái)自第三方組織甚至個(gè)人。在從這些鏡像倉(cāng)庫(kù)中獲取鏡像的同時(shí)，也帶來(lái)了潛在的安全風(fēng)險(xiǎn)。例如，下載鏡像內(nèi)軟件本身是否就包含漏洞，下載的鏡像是否被惡意的植入后門，鏡像在傳輸過(guò)程中是否被篡改。
•  容器入侵事件，由Docker本身的架構(gòu)與機(jī)制可能產(chǎn)生的問(wèn)題，這一攻擊場(chǎng)景主要產(chǎn)生在黑客已經(jīng)控制了宿主機(jī)上的一些容器(或者通過(guò)在公有云上建立容器的方式獲得這個(gè)條件)，然后對(duì)宿主機(jī)或其他容器發(fā)起攻擊來(lái)產(chǎn)生影響。
•  運(yùn)行環(huán)境的安全除了Docker本身存在的問(wèn)題以外，Docker的運(yùn)行環(huán)境存在的問(wèn)題同樣會(huì)給Docker的使用帶來(lái)風(fēng)險(xiǎn)。

由于容器是介于基礎(chǔ)設(shè)施和平臺(tái)之間的虛擬化技術(shù)，因此面向基礎(chǔ)設(shè)施虛擬化的傳統(tǒng)云安全解決方案無(wú)法完全解決前述安全問(wèn)題。如以容器為支撐技術(shù)構(gòu)建DevOps環(huán)境，就需要設(shè)計(jì)涵蓋從容器鏡像的創(chuàng)建到投產(chǎn)上線的整個(gè)生命周期的容器安全方案。

目前，市場(chǎng)上涌現(xiàn)了一批容器安全產(chǎn)品安全廠商，如Neuvector、Twistlock、StackRox、Aqua等等，國(guó)內(nèi)自研容器安全產(chǎn)品的則有青藤云安全。從容器安全產(chǎn)品的技術(shù)方案上來(lái)看，目前大部分的容器安全廠商均使用了平行容器的方式對(duì)宿主機(jī)上的容器進(jìn)行安全防護(hù)，而青藤云安全則采取了基于宿主機(jī)Agent的方式。

平行容器技術(shù)方案：利用容器的隔離性和良好的資源控制能力，在容器的宿主機(jī)中啟動(dòng)一個(gè)容器，該容器通過(guò)掛載宿主機(jī)的所有文件系統(tǒng)，而后在容器內(nèi)部對(duì)這些文件系統(tǒng)進(jìn)行實(shí)時(shí)監(jiān)控和處理響應(yīng)，以實(shí)現(xiàn)對(duì)容器進(jìn)行防護(hù)的作用。

基于宿主機(jī)Agent的技術(shù)方案：即基于青藤Agent的主機(jī)防護(hù)能力，監(jiān)控宿主機(jī)上容器相關(guān)的文件、進(jìn)程、系統(tǒng)調(diào)用等等信息，增加其Agent中對(duì)于容器的清點(diǎn)、監(jiān)控、防護(hù)能力，以便通過(guò)一個(gè)Agent即可實(shí)現(xiàn)宿主機(jī)安全、容器安全兩種防護(hù)的效果。

以上兩種方案示意圖如下：

zhupb