隨著云計算的發展，容器的使用越來越廣泛，尤其是近兩年，越來越多企業機構都開始采用容器作為新的IT基礎設施。回顧一下歷史，其實容器在上世紀的70年代末就已經出現了雛形。Jails，Zones，VPS，VM和容器都是為了隔離和資源控制，但每種技術是通過不同的方式實現它，每種方式都有其局限性和優勢。

1979年：Unix V7

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

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

[[318045]]

2000年：FreeBSD Jails

在2000年，FreeBSD操作系統正式發布FreeBSD jails隔離環境，真正意義上實現了進程的沙箱化。這為文件系統、用戶、網絡等隔離增加了進程沙盒功能，實現了客戶服務之間的隔離和管理。

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

2001年：LinuxVServer

與FreeBSD Jails一樣，Linux VServer也是一種類似上述Jails機制，可以對計算機系統上的資源(文件系統，網絡地址，內存)進行分區。每個所劃分的分區叫做一個安全上下文(security context)，在其中的虛擬系統叫做虛擬私有服務器(virtualprivate 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年被納入Cloud Native Computing Foundation(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項目有1500多個貢獻者，是最重要的開源社區之一，擁有27000多顆星。

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

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的云平臺上自由的遷移工作負載，無論是跨私有云或是公有云及各種混合云架構都沒問題。 

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

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

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

2020年：容器安全亟待解決

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

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

由于容器是介于基礎設施和平臺之間的虛擬化技術，因此面向基礎設施虛擬化的傳統云安全解決方案無法完全解決前述安全問題。如以容器為支撐技術構建DevOps環境，就需要設計涵蓋從容器鏡像的創建到投產上線的整個生命周期的容器安全方案。

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

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

基于宿主機Agent的技術方案：即基于青藤Agent的主機防護能力，監控宿主機上容器相關的文件、進程、系統調用等等信息，增加其Agent中對于容器的清點、監控、防護能力，以便通過一個Agent即可實現宿主機安全、容器安全兩種防護的效果。

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