摘要：無論公有云還是私有云廠商，都認識到了將虛擬化的隔離性和容器的高效運維特性相結合，是雲原生平臺發展的必然趨勢。
容器是如何解決隔離問題的
衆所周知，容器技術的出現有兩個關鍵原因：
1. 軟件運行過程中的資源和環境的隔離。
2. 軟件因爲運行環境多樣帶來的打包和配置的複雜性。
而對於軟件運行環境的隔離需求，從計算機出現之初就已經開始了，多任務分時操作系統和虛擬地址的引入，都是爲了解決多個任務在同一主機上運行，並且讓任務本身認爲自己獨佔機器。當然這樣的隔離是遠遠不夠的，當今軟件，根據不同的層級，可以將隔離技術分爲以下三類：
1. 進程級別的隔離
2. 操作系統級別的隔離
3. 虛擬化級別的隔離
操作系統以進程作爲程序運行過程的抽象，進程擁有獨立的地址空間，進程的執行依靠操作系統的調度。但是進程共享了文件系統，函數庫等資源，程序之間出現互相干擾的可能性很大。這個層級的隔離適合在相同主機上運行單個用戶的不同程序，由用戶自己保證程序之間的資源分配。
上世紀70年代出現了chroot，進行文件系統的隔離，21世紀初開始，隨着計算硬件的性能提升，軟件隔離的需求更加強烈，這時候開始出現如jail，cgroup，namespace等各種不同資源的隔離技術。我們將這些技術統一劃分到操作系統的隔離技術，這類隔離技術可以實現軟件在諸如硬件資源、文件系統、網絡、進程號等方面的隔離，但是不同的應用依然是運行在相同的操作系統內核上，對於惡意的利用漏洞攻擊的場景，這種隔離技術依然會捉襟見肘。但是這種級別的隔離帶來的額外資源消耗較小，適合相同的組織內不同用戶的應用在相同主機上運行。
虛擬化技術的出現，讓相同的物理機上也能運行多個不同的操作系統。操作系統對硬件的接口，由虛擬機管理程序(VMM)負責模擬。運行在不同系統中的程序，內核也是隔離的。硬件資源則通過各種硬件輔助手段進行劃分，虛擬機上的程序很難突破虛擬化層加上的資源限制。並且因爲內核的隔離，資源的可見性也做到了很強的隔離性。即使是惡意的用戶，也很難突破這層虛擬化的限制，已達到攻擊物理機，或者相同主機上其他虛擬機的目的。
以上三種隔離是按照層級一步一步加強的，同時帶來的理論損耗也是逐步遞進的。虛擬化由於需要模擬各種設備，帶來的資源損耗比其他兩種隔離方式要大很多。
什麼是“安全容器”
容器概念出來的時候，最初大家做隔離的思路，幾乎都是操作系統級的隔離，也就是基於內核提供的namespace、cgroup、seccomp等機制，實現容器內的資源、文件、系統調用等限制和隔離。這種隔離方式更加高效，損耗更小。但是隨着容器的大規模使用，尤其是各種容器編排系統，如k8s的深入使用，人們逐漸發現這樣的隔離級別往往不能滿足要求。在公有云場景下，相同主機如果需要運行不同租戶的應用，因爲這種隔離級別依然採用了共內核的機制，存在這廣泛的攻擊面，容器的隔離級別完全不能滿足要求。所以最初的公有云上的容器服務，都是配合虛擬機的使用來完成的，首先是用戶需要創建一批虛擬機作爲運行容器的節點，形成一個私有的集羣，然後才能在其上創建容器應用。虛擬化級別的隔離已經被各種公有云的實踐證明，是一種安全的隔離技術。
自從雲計算的概念提出開始，虛擬機一直是雲平臺的基礎，無論是平臺本身服務還是用戶的使用，都是從IaaS平臺創建通用虛擬機開始的。一般都是創建相應的規格的虛擬機，使用一個完成操作系統鏡像啓動一個完整的操作系統，隨後在其安裝，配置，運行軟件和服務。包括我們上節提到的公有云容器服務的提供形式也是如此。
虛擬化本身帶來的隔離能力是受到普遍認可的，不過IaaS層希望提供的是一個和應用完全無關的基礎設施層，它幾乎完全不感知應用的任何信息。於是從基礎設施到應用運維，中間巨大的鴻溝則是由PaaS和用戶自己來填平，這中間依然需要耗費無數的人力和成本。通用的虛擬機服務誠然有它的好處，比如完整的操作系統很適合程序調試，或者作爲工作辦公環境等等。但是對於多數運行於雲平臺的軟件，它需要的是它獨有的運行環境，它的運行環境由它的鏡像已經完全定義好了。如果在此之外，又啓動一個完整的操作系統，既浪費資源，也增加了運維的成本。爲什麼不能直接將虛擬化級別的隔離引入到容器技術中呢？結合虛擬化的安全性和容器在軟件生命週期管理方面的優勢，是不是可以給軟件開發運維帶來巨大的便利呢？
也就是在這個時間，docker和coreos等一起成立了OCI組織，其目的是將容器的運行時和鏡像管理等流程標準化。OCI標準定義了一套容器運行時的命令行接口和文件規範，docker將其RunC捐給OCI作爲運行時標準的一個參考實現。2015年Hyper.sh開源了RunV，則是一種基於虛擬化的容器運行時接口的實現，它很好地結合了虛擬化的安全性和容器的便利性。後來RunV和ClearContainer合併成立了kata項目，kata提供了更加完整的基於虛擬化的容器實現。我們把這種基於虛擬化的容器實現稱作安全容器。
除kata之外，還相繼出現了多個安全容器的實現方式，比如google的gVisor、AWS的firecracker-containerd、IBM的Nabla、VMware的CRX等等，其原理不盡相同，但共同反應了一個趨勢，就是將容器的便利和虛擬化的安全隔離結合起來，讓虛擬化直接和應用運維結合，成爲雲原生技術的大勢所趨。下面對這些“安全容器”的實現技術進行簡要的介紹和對比。
Google gVisor
相比於其他幾種實現，gVisor的顯著不同之處在於，它通過攔截容器中應用的系統調用，模擬了一個操作系統內核，因此gVisor實際上沒有虛擬化，而是在用戶態實現了一個操作系統。這種方式可以降低因爲虛擬化帶來的模擬設備內存損耗。gVisor提供的runsc符合OCI標準，可以直接對接docker、containerd等容器平臺，同時它也完全兼容docker的鏡像格式。但是由於不是一個標準linux內核，因爲應用的兼容性有較大問題。另外攔截系統調用帶來的巨大的性能損耗也是阻止其廣泛使用的一個阻礙。
IBM nabla
nabla是繼承於unikernel的隔離方式，應用採用rumprun打包成一個unikernel鏡像，直接運行在一個專爲運行unikernel定製虛擬機(ukvm)中。應用直接打包首先可以降低很多內核態和用戶態轉換的開銷，另外通過ukvm暴露非常有限的主機上的syscall(只剩7個)，可以大大縮小主機的攻擊面。它是這些安全容器實現中，最安全的。不過由於它要求應用打包成unikernel鏡像，因此和當前docker的鏡像標準是不兼容的。另外，unikernel應用在諸如支持創建子進程等一些常規操作上都有很難解決的問題。
AWS Firecracker
最初firecracker是爲AWS的Lambda打造的高密度輕量級虛擬化組件。由於它是從頭開始構建虛擬化，帶着輕量化的目的，因此他拋掉了qemu這種通用虛擬化組件的大部分功能，只留下運行容器和Function必要的一些模擬設備。因此它的內存開銷非常小（小於5M），啓動速度非常快（小於125ms），一秒鐘可以在一個節點上運行150個輕量級虛擬機。
爲了讓firecracker-microvm更好的運行容器，AWS啓動了firecracker-containerd項目，firecracker-containerd是containerd-shim-v2的一個實現，不符合OCI標準，但是可以直接對接containerd啓動容器，也就很容易通過containerd對接k8s的CRI接口。containerd-shim-v2是containerd定義的新的runtime接口，它是對最初shim-v1的一個簡化，可以大大精簡runtime的組件和內存使用。containerd是一個全插件化的代碼框架，擴展性非常好。firecracker-containerd在該框架下，實現了一個snapshotter作爲鏡像插件，負責塊設備鏡像的生成；實現了一個shim-v2的runtime，負責容器的生命週期管理。另外還有個fc-control-plugin作爲虛擬機的管理插件，提供grpc接口供runtime調用。在輕量級虛擬機內部，有一個agent負責監聽runtime傳進來的vsock，接收runtime的指令進行虛機內部真正的容器生命週期管理操作，它是直接調用runc來管理容器的。
圖片來自https://github.com/firecracker-microvm/firecracker-containerd/blob/master/docs/architecture.md
VMware CRX
VMware發佈的vSphere 7與kubernetes進行了融合，它利用k8s的CRD將其集羣的虛擬機、容器、函數等運行實體管理的所有功能都集成到了k8s中。VMware是一個做虛擬化起家的公司，因此虛擬化作爲它的老本行，這塊的積累是很深厚的。它將虛擬化融合到它的容器runtime CRX中，因此和firecracker-containerd和kata類似，也是一個基於輕量級虛擬化的容器runtime的實現。通過對其虛擬化組件和guest內核的精簡，CRX 容器同樣做到了很低的內存損耗(20MB)、快速(100ms)的啓動以及高密度部署(單個節點大於1000個pod)。
圖片來自https://cormachogan.com/2019/11/22/project-pacific-vmworld-2019-deep-dive-updates/
vSphere對node上的kubelet組件改造比較大，節點上的Spherelet部分功能和kubelet重合，負責pod的生命週期管理（他們稱之爲Native Pod），運行在虛擬機中的SphereletAgent則集成了符合OCI接口規範的libcontainer，實現容器的生命週期管理，以及容器的監控日誌採集、容器的shell登錄(kubectl exec)。Spherelet和虛機中的SphereletAgent交互實現類似於kubelet使用CRI接口管理pod的效果。
kata containers
相比於以上幾種，kata containers 最大的特點是它專注於實現一個開放的符合OCI標準的安全容器runtime實現，對於對接什麼樣的虛擬化方案，它抽象了一套hypervisor接口，如今已經對接了多種虛擬化實現，比如qemu、nemu、firecracker、cloud-hypervisor等等。
圖片來自https://katacontainers.io/
通過containerd-shim-v2和vsock技術，kata精簡了大量的組件，配合輕量級hypervisor和精簡內核，kata可以做到將額外內存消耗降低到10MB以下。容器啓動時間降低到100ms以下。後續還會通過rust語言重寫等方式，提供更低內存額外消耗。
圖片來自https://github.com/kata-containers/documentation/blob/master/design/architecture.md
現有安全容器技術對比
|
|
實現方式 |
安全隔離 |
性能/輕量化 |
兼容性 |
|
Google gVisor |
用戶態內核 |
攔截系統調用 |
IO、網絡性能差 |
OS兼容性差 |
|
IBM nabla |
Unikernel |
裁剪系統調用+虛擬化 |
暫無數據 |
和現有鏡像不兼容 |
|
AWS Firecracker |
輕量級虛擬化 |
虛擬化 |
高 |
僅對接firecracker-microvm虛擬化 |
|
VMware CRX |
輕量級虛擬化 |
虛擬化 |
高 |
僅對接VMware的ESXi |
|
kata-containers |
輕量級虛擬化 |
虛擬化 |
高 |
適配多種輕量級虛擬化技術 |
安全容器技術發展趨勢
隨着Serverless等技術的興起，應用部署和運維工作已經下沉到雲平臺上，人們需要一個更加高效的雲原生技術平臺。從這幾年湧現的安全容器實現技術可以觀察到，無論公有云還是私有云廠商，都認識到了將虛擬化的隔離性和容器的高效運維特性相結合，是雲原生平臺發展的必然趨勢。結合當前安全容器實現中遇到的一些問題，我們可以預見到，未來這項技術發展的幾個走向：
1. 需要一個爲安全容器而生的輕量級hypervisor，當前qemu+kvm是主流的虛擬化技術，但因爲qemu是爲通用的虛擬機而設計的，其體量過於龐大，而對於安全容器而言，一個模塊化可定製的虛擬化實現尤爲重要。如果結合gVisor和nabla的實現來看，內核的可定製性也是安全容器場景的必然要求。rust-vmm即是這樣一種模塊化的虛擬化組件庫。linux內核本身的模塊化特性可以部分滿足容器場景下的內核定製需求，不過也許像gVisor那樣實現一個專爲容器而生的內核也許是未來的趨勢。
2. 容器的啓動時間是衡量一個雲原生平臺效率的重要指標，尤其是在Serverless場景下，程序運行時間本身可能很短，這時候啓動時間可能佔用了其絕大部分，那麼這種低效就顯得尤爲明顯。安全容器通過極致的輕量化，可以將容器啓動時間降低到100ms以下，但是容器鏡像拉取時間過長仍是當前容器部署過程中的一個短板。由於當前容器鏡像格式和鏡像掛載方式等方面的限制，需要在啓動容器之前將容器鏡像拉取到本地以後，才能啓動容器。而容器啓動本身需要的數據只佔鏡像的6%左右。因此我們亟需一個高效的鏡像掛載方式，當前已經有一些免下載和懶加載（Lazy-Loading）的技術原型，後續需要儘快推出一個可商用的鏡像下載加速方案。
3. 當前公有云的網絡普遍採用原IaaS的網絡管理模式，在地址分配，網絡配置效率等方面完全趕不上容器快速啓停的需求，docker容器採用的veth方式在性能等方面也很難滿足高效轉發的要求。因此需要一個專爲雲原生設計的網絡管理方案。
4. 我們看到雲平臺對應用的管理逐步深入，從只管理基礎設施的IaaS層，發展到管理應用整體部署和運維的PaaS，再到如今服務網格（Service Mesh）技術將平臺管理能力深入到應用內部的微服務級別。同時我們也看到，以K8s容器、Istio服務網格爲代表的雲原生技術已經和下層的計算/網絡虛擬化等技術逐步整合到了一起，比如安全容器即是容器與計算虛擬化的結合，而Istio服務網格也會與虛擬化網絡進行深度整合以提供更高的性能與更精細的QoS控制。
5. 當前硬件加速技術在AI和大數據等領域大行其道，安全容器需要與各種計算加速硬件技術進行結合，使得AI、大數據、科學計算等批量計算領域的用戶可以利用雲平臺直接投遞其海量的計算任務，可大大降低他們在底層技術上的心智負擔。通過硬件加速也是提升雲平臺本身效率、降低雲平臺運行成本的有效手段。比如華爲雲擎天架構在硬件加速方面擁有的技術優勢在“安全容器”領域已得到充分的證明，CCE Turbo裸金屬容器已經實現了安全容器的部分硬件卸載能力。
總結
未來必然是雲原生技術大行其道的時代，我們已經看到很多傳統行業也逐漸認識到雲原生技術可以給傳統企業的IT軟件，工業自動化，線上運維和數據管理等帶來明顯的效率提升。我們將看到通過對底層硬件和上層服務的全棧整合，打造出一個高效智能的雲計算技術平臺，而這中間，容器將是串聯整個技術棧的關鍵所在。
點擊這裏，瞭解更多精彩內容