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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2013年：Docker

隨著2013年Docker的出現，容器開始迅速普及。它最初是一個叫做 dotCloud 的 PaaS 服務公司的內部項目，后來該公司改名為 Docker。Docker的增長并非偶然，它引入了一整套管理容器的生態(tài)系統(tǒng)，包括高效、分層的容器鏡像模型、全局和本地的容器注冊庫、清晰的 REST API、命令行等。 跟Warden一樣，Docker開始階段使用的也是LXC，后來用自己的庫libcontainer進行替換。Docker 推動實現了一個叫做 Docker Swarm 的容器集群管理方案。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）不安全的鏡像源

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

（2）容器入侵事件

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

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

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

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

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

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

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

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