容器在公有云上的落地姿式

時間 2019-11-05

標籤容器公有落地简体版

原文原文鏈接

1.容器天生隔離能力不足

1.1 容器是一種進程隔離技術，並不是虛擬化技術

容器（container），並非一種虛擬化（virtualization）技術，而是一種進程隔離（isolation）技術，從內核空間、資源和安全等方面對進程作隔離。linux

Linux 容器採用 Linux 控制組（cgroups）和命名空間（namespace），其中，cgroups 定義了一個進程能使用什麼（CPU、內存、網絡等資源），namespace 定義了一個進程能看到什麼（uid，gid，pid，mount，filesystem等）。一方面，並不是全部系統資源均可以經過這些機制來控制（好比時間和Keyring，https://blog.jessfraz.com/post/two-objects-not-namespaced-linux-kernel/）。另外一方面，在Linux 容器中運行的應用程序與常規（非容器化）應用程序以相同的方式訪問系統資源；直接對主機內核進行系統調用。內核以特權模式運行，容許它與必要的硬件交互並將結果返回陰應用程序。所以，即便使用了不少限制，內核仍然面向惡意程序暴露出了過多的攻擊面。git

除了cgroups 和 namespace，Linux 容器還會使用到象 seccomp 這樣的技術。seccomp是內核防火牆，限制一個進程對內核系統調用（systemcall）的訪問限制，可以在應用程序和內核之間提供更好的隔離，可是它們要求用戶建立預約義的系統調用白名單。在實際中，很難事先羅列出應用程序所需的全部系統調用。若是你須要調用的系統調用存在漏洞，那麼這類過濾器也很難發揮做用。github

所以，容器被認爲不具有和虛擬機以及沙盒（sanbox）同樣的隔離能力。關於容器、虛擬機和沙盒之間的區別，Jessie 的這篇博文（Setting the Record Straight: containers vs. Zones vs. Jails vs. VMs ）給出了很好的解釋。編程

1.2 Kubernetes 的多租戶隔離

Jessie Frazelle（他的博客地址爲 https://blog.jessfraz.com，強烈推薦）將多租戶隔離模式分爲兩大類：安全

弱隔離（Soft multi-tenancy）：同一個組織中的多個用戶使用同一個集羣。這種隔離模式中，由於用戶處於同一個組織中，所以互相之間默認是信任關係，可是也存在可能的狀況，好比有惡意的員工。這種隔離模式的主要目的就是爲了防止這種惡意事件。服務器
強隔離（Hard multi-tenancy）:來自不一樣組織的多個用戶使用同一個集羣。這種隔離模式中，默認就假定全部用戶都是潛在惡意的，所以這種模式的主要目的是阻止租戶之間的互相訪問。

從上面的定義能夠看出，基本上，私有云的隔離模式是弱隔離模式，而公有云的隔離模式是強隔離模式。微信

由於容器天生隔離不足，若是隻是採用傳統 Linux 容器的話，公有云每每採用每一個用戶單首創建 Kubernetes 集羣的方式來實現強隔離：網絡

Jessie Frazelle 的這個圖是假設 K8S 可以在不一樣的宿主機上建立和管理不一樣的K8S 集羣（那時候 K8S 真的成爲集羣操做系統了）。實際上，當前這種角色每每由公有云本身的雲管平臺實現，而後在若干臺虛擬機或物理機上爲每一個用戶搭建完整的Kubernetes集羣，每一個集羣利用傳統的Linux 容器來運行客戶的應用。由於傳統Linux容器的隔離性不足，每一個用戶的容器必須容許在獨佔的環境中。架構

可是，若是把運行環境從 Linux 傳統容器換成微虛機（好比 kata container）的話，由於微虛機自己具備的強隔離能力，則能夠在一個宿主機上建立不一樣用戶的這種運行環境，此時這些環境在集羣中是混部的。less

2.容器在AWS 上的落地方式（以Lambda爲例）

AWS 上多個服務都利用到容器，好比 Lambda 利用了傳統Linux 容器，而 ECS 和 EKS 則利用了 Docker 容器。以 Lambda 爲例，咱們來看看過去和如今容器在AWS上的落地方式。

2.1 過去容器在Lambda 中的落地方式 - 用戶函數運行在獨佔的EC2虛擬機中的Linux容器中

下圖是 Lambda 的技術架構：

從名字上基本上就能夠看出來每一個組件是幹什麼的。其中，一個 Worker 就是實際運行用戶函數的一個安全環境。以前，一個 worker 是一個 EC2 實例，其操做系統爲 Amazon Linux。

下圖是 Worker 被建立以及函數被調度到 worker 中的基本流程：

其中，Worker manage 負責 worker 的建立和管理，Placement 服務負責將用戶的函數調度到某個或某些worker 上運行。

此時Lambda的強隔離模式的實現方式以下圖所示：

這個圖仍是簡單明瞭的，具體就不解釋了。

引用 AWS Lambda 團隊工程師所說的，基於CPU的硬件虛擬化技術是AWS上用戶之間隔離的最低要求。所以，和 AWS 上不少利用容器的服務同樣，Lambda 也利用了 EC2 虛機來實現用戶之間的強隔離。

可是，其侷限也是顯而易見的，好比：

資源浪費：用戶的一個簡單的測試函數也會佔用一個虛機）
管理複雜：須要管理複雜的資源和安全模式
啓動速度不夠快：EC2虛機的建立時間確定沒有容器快

2.2 如今容器在Lambda 中的落地方式 - 用戶函數運行在Firecracker微虛擬機中

亞馬遜在2018 年 re:invent 大會上宣佈了一個新的開源項目 Firecracker，並已經用在Lambda 和 Fargate 服務之中了。 Firecracker 是一種採用基於 Linux 內核的虛擬機 (KVM) 技術的開源虛擬機監控程序(VMM)。 Firecracker 負責建立和管理微虛機（microVM）。 Firecracker 微虛機提升了效率和利用率，內存開銷極低，使得在一臺物理服務器上能夠建立數千個微虛機。後文下面再介紹。

使用Firecracker後的 Lambda 隔離模型：

其好處也是不言自明的，好比：

確保安全，經過利用CPU硬件虛擬化實現了用戶之間的強隔離。
節省成本，經過提升了的物理硬件資源利用率。
提升效率，經過縮短了的計算環境啓動時間。
簡化管理，經過簡化了的安全模型。
方便用戶，經過簡化了的 Lambda 編程模型。

3. Firecracker 是什麼

Firecracker 的中文意思是『鞭炮』。顧名猜意，不知道AWS是否是認爲在公有云上運行容器就像放鞭炮同樣，看起來絢麗多彩，可是弄很差就會引發火災。

簡單地能夠將 Firecracker 看作被大大簡化了的 QEMU。它和 QEMU 同樣，利用 KVM，負責建立和管理虛機。由於這種虛機面向 Serverless 這種場景，適合於運行暫時性（ transient and short-lived）進程，所以被稱爲微虛機，即microVM。

由於公有云對微虛機的要求是具備象常規虛擬機同樣的隔離能力，同時還有象Linux 容器那樣的輕量特性（硬件開銷小，啓動快）。所以，Firecracker 的設計思路是：

內置安全性：提供了支持多租戶工做負載而且不會被客戶錯誤禁用的計算安全性屏障。客戶工做負載被認爲既神聖（不可侵犯）又邪惡（應當拒之門外）。
輕量虛擬化：重視瞬時性或無狀態的工做負載，而非長時間運行或持續性的工做負載。Firecracker 的硬件資源開銷是明確且又保障的。
功能極簡主義：不會構建非AWS任務所明確要求的功能。每一個功能僅實施一項。
計算超分：Firecracker 向來賓開放的全部硬件計算資源均可以安全地超分。

Firecracker 堅持精簡主義的設計原則，它僅包含運行安全、輕量的虛擬機所需的組件。在設計過程的各個環節，都依據安全性、速度和效率要求來優化 Firecracker。例如，僅啓動相對較新的 Linux 內核，而且僅啓動使用特定配置選項集編譯的內核（內核編譯配置選項超過 1000 種）。此外，不支持任何類型的圖形卡或加速器，不支持硬件透傳，不支持（大多數）老舊設備。只支持四種設備虛擬化（virtio-net, virtio-block, serial console, 和只有一個按鈕的鍵盤控制器）。

這麼作的結果也是很是明顯的，好比：

每一個微虛機的內存開銷小於 5MiB。
一臺物理機上能啓動的微虛機數目的限制只是硬件限制，數目能夠是數千臺。
在AWS 一次啓動4000個微虛機的演示中，最長的微虛機耗時只有219毫秒，最短的只須要125毫秒。

項目的開源地址是 https://firecracker-microvm.github.io/。更多信息，可查閱更多文章，甚至閱讀源碼。

4. 展望將來

AWS 宣佈開源 Firecracker在業界引發了很大的關注。加上以前已有的 Kata container（由Intel，Hyper.sh 和 OpenStack主導）和 gVisor（由Google開源），微虛機愈來愈引發人們的重視。基於我的理解，對將來作一點不負責任的預測：

公有云利用微虛機來落地容器會成爲通用作法。以阿里雲的秉性，相信他們很快會跟進，推出和AWS相似的技術實現。極可能也會開源一個項目。
AWS 會將 Firecracker 做爲其統一的容器落地模式。

微虛機生態（Kata container、gVisor 和 Firecracker）會發生不少有趣的變化。當前，每一個項目都有各自的面向場景。從非技術層面看，由於AWS 對開源的態度應該是『以我爲主』，所以 Firecracker 仍是會繼續由AWS主導，以被AWS上的服務使用爲主；gVisor 由於來自Google，Google 也有公有云，加上 Kubernetes 也源自Google，不知道它是否會演進爲事實上的微虛機標準；而 Kata container 也許未來會以面向私有云場景爲主（設想一下OpenStack支持 Kata 微虛機，而 K8S 支持支持 gVisor 微虛機，二者之間的PK是否是就成了編排能力的PK？）。

參考連接：

感謝您的閱讀，歡迎關注個人微信公衆號：