【摘要】不管公有云仍是私有云廠商，都認識到了將虛擬化的隔離性和容器的高效運維特性相結合，是雲原平生臺發展的必然趨勢。
容器是如何解決隔離問題的
衆所周知，容器技術的出現有兩個關鍵緣由：node
1. 軟件運行過程當中的資源和環境的隔離。linux
2. 軟件由於運行環境多樣帶來的打包和配置的複雜性。git
而對於軟件運行環境的隔離需求，從計算機出現之初就已經開始了，多任務分時操做系統和虛擬地址的引入，都是爲了解決多個任務在同一主機上運行，而且讓任務自己認爲本身獨佔機器。固然這樣的隔離是遠遠不夠的，當今軟件，根據不一樣的層級，能夠將隔離技術分爲如下三類：github
1. 進程級別的隔離docker
2. 操做系統級別的隔離shell
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
現有安全容器技術對比
安全容器技術發展趨勢
隨着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軟件，工業自動化，線上運維和數據管理等帶來明顯的效率提高。咱們將看到經過對底層硬件和上層服務的全棧整合，打造出一個高效智能的雲計算技術平臺，而這中間，容器將是串聯整個技術棧的關鍵所在。