隨著云計算的發(fā)展，容器的使用越來越廣泛，尤其是近兩年，越來越多企業(yè)機構(gòu)都開始采用容器作為新的IT基礎(chǔ)設(shè)施?；仡櫼幌職v史，其實容器在上世紀(jì)的70年代末就已經(jīng)出現(xiàn)了雛形。Jails，Zones，VPS，VM和容器都是為了隔離和資源控制，但每種技術(shù)是通過不同的方式實現(xiàn)它，每種方式都有其局限性和優(yōu)勢。

[[318371]]

1979年：Unix V7

在那個計算資源匱乏年代，想要通過快速銷毀和重建基礎(chǔ)設(shè)施來解決測試環(huán)境污染問題幾乎不可能。為了隔離出來可供軟件進行構(gòu)建和測試的環(huán)境，chroot(change root)系統(tǒng)調(diào)用程序橫空出現(xiàn)。

在1979年Unix V7的開發(fā)過程中，正式引入了chroot系統(tǒng)調(diào)用，為每個進程提供一個獨立的磁盤空間，將一個進程及其子進程的根目錄改變到文件系統(tǒng)中的新位置，讓這些進程只能訪問到該目錄。這個被隔離出來的新環(huán)境被叫做 Chroot Jail。這標(biāo)志著進程隔離的開始，隔離每個進程的文件訪問權(quán)限。如下圖所示，貝爾實驗室正在為 Unix V7操作系統(tǒng)的發(fā)布進行最后的開發(fā)和測試工作。

[[318372]]

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

2000年：FreeBSD Jails

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

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

2001年：LinuxVServer

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

2004年：Solaris容器

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

2005年：Open VZ(Open Virtuzzo)

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

2006年：Process Containers

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

2008年：LXC

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

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

2011年：Warden

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

2013年：LMCTFY

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

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

2013年：Docker

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

跟Warden一樣，Docker開始階段使用的也是LXC，后來用自己的庫libcontainer進行替換。Docker 推動實現(xiàn)了一個叫做 Docker Swarm 的容器集群管理方案。

2014年：Rocket

Rocket 是由 CoreOS 所啟動的項目，非常類似于 Docker，但是修復(fù)了一些 Docker 中發(fā)現(xiàn)的問題。CoreOS 初衷是旨在提供一個比 Docker 更嚴(yán)格的安全性和產(chǎn)品需求。更重要的是，它是在一個更加開放的標(biāo)準(zhǔn) AppContainer 規(guī)范上實現(xiàn)的。在 Rocket 之外，CoreOS也開發(fā)了其它幾個可以用于 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 上運行 Docker 容器，而不需要啟動一個虛擬機來運行 Docker( Windows 上早期運行 Docker 需要使用 Linux 虛擬機)。

2017年：容器工具日趨成熟

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

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

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

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

2018年：越來越規(guī)范

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

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

2019年：歷史變革

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

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

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

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

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

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

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

2020年：容器安全急需解決

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

(1)不安全的鏡像源

開發(fā)者通常會在Docker 官方的Docker Hub倉庫下載鏡像，這些鏡像一部分來源于開發(fā)鏡像內(nèi)相應(yīng)軟件的官方組織，還有大量鏡像來自第三方組織甚至個人。在從這些鏡像倉庫中獲取鏡像的同時，也帶來了潛在的安全風(fēng)險。例如，下載鏡像內(nèi)軟件本身是否就包含漏洞，下載的鏡像是否被惡意的植入后門，鏡像在傳輸過程中是否被篡改。

(2)容器入侵事件

由docker本身的架構(gòu)與機制可能產(chǎn)生的問題，這一攻擊場景主要產(chǎn)生在黑客已經(jīng)控制了宿主機上的一些容器(或者通過在公有云上建立容器的方式獲得這個條件)，然后對宿主機或其他容器發(fā)起攻擊來產(chǎn)生影響。

(3)運行環(huán)境的安全

除了docker 本身存在的問題以外，docker的運行環(huán)境存在的問題同樣會給docker的使用帶來風(fēng)險。

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

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

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

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

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