Serverless Computing，即”無服務器計算”，這一概念在剛剛提出的時候并沒有獲得太多的關注，直到2014年AWS Lambda這一里程碑式的產(chǎn)品出現(xiàn)。通過將無服務器計算的概念嵌入到整個云計算服務的整體產(chǎn)品框架中，無服務器計算正式走進了云計算的舞臺。2017年，AWS發(fā)布了Fargate產(chǎn)品以充實自己的無服務器計算產(chǎn)品線。

今年5月，Google在KubeCon+CloudNative 2018期間開源了gVisor容器沙箱運行時并分享了它的設計理念和原則。隨后，今年7月，Google在舊金山舉辦了2018年度Google Next大會，在這次大會上，Google推出了自己的 Google Serverless Platform。針對App Engine，最重要的更新就是低層的沙箱技術采用了gVisor。當然，我們有足夠的理由相信Google指的是gVisor的內(nèi)部實現(xiàn)版本。

今年的re:Invent 2018上，AWS點（kai）燃（yuan）了Firecracker —— AWS容器安全沙箱的基礎組件，用于函數(shù)計算服務AWS Lambda和托管的容器服務AWS Fargate[1][7]。

圖1 Firecracker microVM

Firecracker利用了Linux KVM來構建專門用于容器的微虛擬機，即Firecracker microVM。并力圖提供一種針對容器的，同時滿足了安全隔離、性能穩(wěn)定、高資源利用率的方案。AWS的首席“傳教士”Jeff Barr稱它：即提供了傳統(tǒng)虛擬機對業(yè)務負載的安全與隔離特性，也帶來了像使用容器一樣高效的資源利用率。

Firecracker派生自Crosvm[2] —— 用Rust編寫的、開源的、用于Chromium OS的Virtual Machine Monitor。基于Crosvm，AWS于2017年10月開始了Firecracker的研發(fā)。但與Crosvm的目標不同，F(xiàn)irecracker聚焦于Serverless，即：專為無服務器計算場景提供安全高效的運行時。近些年，系統(tǒng)安全越發(fā)受到重視，Rust語言也變的越來越流行。Firecracker可能也是Rust語言在生產(chǎn)環(huán)境中部署的，規(guī)模最大的系統(tǒng)軟件。

Firecracker目前還沒有實現(xiàn)與Docker及Kubernetes對接。但是AWS同時開源了一個對接containerd的原型[9]，并表示未來一定會和Kubernetes兼容。

根據(jù)AWS的說法，F(xiàn)irecracker微虛機可以在每個主機上以每秒150個實例的速率，在125ms內(nèi)啟動。并宣稱VMM組件的內(nèi)存開銷小于5MiB（注：不包括客戶內(nèi)存，vCPU線程占用的內(nèi)存，和控制平面上API Server線程占用的內(nèi)存）。因此，可以在一臺服務器上部署成百上千個微虛機。

2. AWS Lambda的演進與Firecracker的誕生

Firecracker目前已經(jīng)用在AWS無服務器計算業(yè)務中，包括AWS Lambda和AWS Fargate。AWS認為，使用無服務器計算服務的用戶負載的典型特點是“生命周期短”，而Firecracker專為這種場景打造。讓我們看一下，F(xiàn)irecracker是如何支撐AWS Lambda的。

Firecracker誕生的內(nèi)因是AWS Lambda的演進，而要了解Lambda的演進，就需要看一下Lambda對用戶請求的執(zhí)行過程和執(zhí)行環(huán)境。如下圖所示，用戶請求通過“ALB”轉(zhuǎn)發(fā)給“Front End”，“Front End”請求“Worker Manager”，“Worker Manager”初始化“Worker”，“Worker”準備函數(shù)沙箱執(zhí)行環(huán)境，完成后，將狀態(tài)原路返回給“Front End”，然后由“Front End”觸發(fā)函數(shù)執(zhí)行。

圖2 AWS Lambda 執(zhí)行過程

用戶函數(shù)運行在“Lambda Runtime”中，在其之下是沙箱。與Linux中跑容器時常用的套路一樣，使用了cgroups，namespaces，seccomp，iptables，和chroot等一些列工具以實現(xiàn)操作系統(tǒng)層級上的虛擬化（也稱為“容器化”）[11]。再往下一層，是實現(xiàn)安全隔離的重點，即虛擬化技術與設備模擬。全棧如下圖所示：

圖3 AWS Lambda 執(zhí)行環(huán)境

當AWS剛開始打造Lambda服務時，它始于在一個EC2實例中構建每一個“Worker”。原因很直接：

很好的安全邊界；

快速構建好整個系統(tǒng)使業(yè)務上線；

這種方式今天依然在使用，并且運行在Nitro平臺上面。

圖4 基于EC2實例的AWS Lambda

通過AWS Lambda長期以來的生產(chǎn)實踐和客戶的需求反饋，AWS意識到，基于EC2實例的Lambda并不適合今天的無服務器計算場景。并總結(jié)出無服務器計算的典型特征應該是：“啟動快，密度高，水平擴展”。但要達到以上這三個點，不能損失一點安全性?；谶@些因素，AWS決定對Lambda進行改進，并在此過程中開發(fā)了Firecracker微虛機。由此，AWS Lambda有了另一種跑在微虛機中的“Worker”。

圖5 基于Firecracker的AWS Lambda

為了進一步加固安全隔離，AWS在微虛機外面又套了一層沙箱（使用運行容器時常用的工具）。由此可見，安全隔離是對外提供服務的基本前提。

當啟動變快，內(nèi)存開銷變低時，實例部署密度也自然有了更大的提升空間。但實際上，實例部署密度不僅與CPU、內(nèi)存相關，還涉及到與業(yè)務相關的一整套資源，比如：ENI網(wǎng)卡，IP地址資源等。隨著部署密度從一百提升到一千甚至更高的時候，相關資源的供給及使用的問題隨之而來。

當Lambda創(chuàng)建和啟動一個函數(shù)服務時，它需要經(jīng)歷在用戶VPC網(wǎng)絡中創(chuàng)建EC2 ENI網(wǎng)卡，并將該網(wǎng)卡添加給“Worker”。這個添加網(wǎng)卡的過程比較費時，并且每個ENI網(wǎng)卡需要在用戶子網(wǎng)中消耗一個IP地址。有些情況下，這種模型還不錯，簡單并且支持VPC的所有特性。但最大的弊端，也是特別被某些用戶所詬病的，就是等待VPC啟動所耗費的時間過長。因此，AWS將ENI從“Worker”中移出，在“Worker”與ENI之間做了NAT，在多個不同的“Worker”間復用同一個ENI。本質(zhì)上，這意味著在多個租戶間復用數(shù)量有限的ENI網(wǎng)卡。這樣改進后，帶來的直接好就是可預期的VPC啟動延時，快速的水平伸縮，低服務延時，和高易用性。

3. Firecracker的設計

3.1 內(nèi)部架構

Firecracker微虛機的創(chuàng)建用到兩個組件，Jailer和Firecracker，前者負責利用Linux提供的seccomp、cgroup、chroot、net/pid/user namespaces來創(chuàng)建沙箱環(huán)境，然后在其創(chuàng)建的沙箱環(huán)境中啟動后者。后者利用Linux KVM創(chuàng)建設備模型極度精簡的微虛擬機。結(jié)構如下：

6 firecracker結(jié)構框圖

一個Firecracker進程就是一個微虛擬機，其內(nèi)部主要有三個組件：

API Server

API Server以Unix domain socket的方式對主機提供了一個API endpoint，接口采用RESTful API格式，詳見接口規(guī)范[10]。

通過這個API Endpoint，可以對微虛機進行管理和控制，包括：

規(guī)格配置：比如vCPU個數(shù)，用戶內(nèi)存大??；

網(wǎng)絡配置：添加一個或多個網(wǎng)卡；

存儲配置：

添加“只讀”或“讀寫”虛擬盤，每個虛擬盤盤是一個基于文件的塊設備；

運行時觸發(fā)“re-scan”；

更換后端文件；

QoS：通過帶寬限制和iops限制進行流控；

日志與遙測配置；

啟動配置：內(nèi)核及其參數(shù)，根文件系統(tǒng)；

關閉微虛機；

Firecracker以一個單獨的線程運行API Server。

Virtual Machine Monitor

VMM負責構建Firecracker定制的虛擬機模型。其中包括：

最小化的老式設備模型；

微虛機元數(shù)據(jù)服務（microVM metadata service/MMDS）；

VirtIO虛擬網(wǎng)絡設備和塊設備；

QoS流控；

串口控制臺和半功能鍵盤；

VMM采用單線程事件驅(qū)動模型，對各種I/O請求進行服務。

vCPU Threads

根據(jù)規(guī)格配置，通過KVM接口創(chuàng)建vCPU結(jié)構，為每個vCPU啟動一個線程，執(zhí)行vCPU事件循環(huán)，并執(zhí)行同步I/O和基于內(nèi)存映射I/O的操作。

3.2 微虛機模型

Firecracker利用了硬件輔助虛擬化，同時使用一個極簡的設備模型。從系統(tǒng)虛擬化角度看，可分解為如下幾個方面：

CPU/Memory: 利用VT-x進行CPU虛擬化和內(nèi)存虛擬化

系統(tǒng)總線：移除PCI系統(tǒng)總線模

設備模擬：

virtio-net

virtio-block

console

keyboard

irqchip

clock source

KVM in kernel devices

in VMM

3.3 社區(qū)及路線圖

在Firecracker代碼庫中的文檔里面公布的路線圖上[8]可以看出，目前它主要部署在Intel的平臺，計劃還會支持AMD、ARM平臺，及存儲加密等特性。

Firecracker的開發(fā)者與社區(qū)的互動還是比較積極的。由此看來，他們希望借助社區(qū)的力量以實現(xiàn)與k8s很好的集成。在它的版本庫上，還提供了一個與containerd對接的原型“firecrack-containerd”。Firecracker的維護者Anthony Liguori（前QEMU社區(qū)維護者）也表示出與Kata Containers社區(qū)合作的意愿。

4. 總結(jié)

注意到許多關于Firecracker的評論中，不少人對“容器運行時”與Firecracker之間的差別存在誤解，在此強調(diào)下：Firecracker是一個virtual machine manager，QEMU也是一個virtual machine manager。Kata Containers使用QEMU。因此，F(xiàn)irecracker是AWS用于構建無服務器計算場景下的“容器運行時(Runtime)”（也叫“容器安全沙箱”）所用到的一個組件，作用是替換掉QEMU。當然，更談不上是新型虛擬化技術，它依然使用Intel VT-x，依然需要機器模型和設備模型，只不過，它做的很精簡（當然，為什么不呢？）。

為什么要替換QEMU？原因有很多，比如：龐大的代碼體積；近年來高發(fā)的漏洞數(shù)量[12]；對基本上用不到的傳統(tǒng)設備、總線、機器模型的模擬。雖然某些情況下，對各種硬件協(xié)議的真實模擬還是不錯的，但是，針對無服務器計算（Serverless）這樣的場景，需要業(yè)務啟動快，密度高，可快速水平擴展，這種方式顯然就不適合了，需要一種更敏捷的容器運行環(huán)境。

除了Firecracker，Kata Containers和gVisor也致力于提供安全可靠的容器運行環(huán)境。它們之間存在哪些差異呢？

Firecracker與Kata Containers

首先，Kata Containers使用QEMU作為VMM，使用Linux作為Guest OS，通過配置QEMU的編譯選項來裁剪掉一些不用的功能，通過配置Linux的編譯選項裁剪掉不用的設備驅(qū)動、子系統(tǒng)和一些功能。但是，QEMU中的傳統(tǒng)機器模型始終存在，還有一些“設備模擬”的功能沒有編譯選項，因此無法被裁剪掉；而Linux的子系統(tǒng)，如SMP，調(diào)度，內(nèi)存管理，ACPI，PCI總線等也都依然假定活在真實物理機上。對于無服務器計算場景，這些都是沒有意義的，因為在這種場景下，Guest OS完全由我們來提供。不需要考慮其他情況，如Windows或其他老的Linux版本。但凡對業(yè)務運行沒有用的設備都不需要，甚至是設備模型和機器模型。Firecracker走的方向與我們正在走的設計方向很相似，即：極簡的機器模型，拿掉PCI總線，替換掉QEMU。我們也曾考慮用Rust語言構建容器沙箱，但AWS動手更早，并已經(jīng)大規(guī)模部署了?；仡^來考慮我們的容器實例場景，Aliyun ECI，試想下我們用Firecracker替換了QEMU，并且對Guest OS做進一步的優(yōu)化，比如頁表預分配，vCPU直接64bit分頁模式啟動等，沙箱的啟動可以更快。

Firecracker與gVisor

對比Firecracker與gVisor的設計，不難發(fā)現(xiàn)一個很有意思的話題：“虛擬化的界面”，即：對Guest而言，它與Hypvervisor之間的接口是什么？_與“虛擬機”模型不同，gVisor采用了與Dune[13]類似的“進程虛擬化”模型，將虛擬化的界面畫在了“系統(tǒng)調(diào)用/syscall”這個邊界上。因此，徹底去掉了機器模型和設備模型。這不僅意味著減輕了虛擬化的“開銷”，還意味著可以更加靈活高效的利用主機上的系統(tǒng)資源。gVisor就通過host-guest（vmx-root/nonroot）鏡像內(nèi)核地址空間的內(nèi)存布局設計，使得它可以既作為host上的hypervisor，又作為guest中的supervisor，因此可以在vCPU調(diào)度上內(nèi)外打通，使得vCPU“協(xié)程”可以按需增減。此外，gVisor自然的享受了Go Runtime中的concurrent garbage collector帶來的好處，比如當執(zhí)行完“用戶負載/函數(shù)”時，或當Guest中的“工作集”縮小時，Go的GC的會立即把多余的內(nèi)存回收并還給主機系統(tǒng)。這就使得gVisor在vCPU和內(nèi)存資源的使用上都很有“彈性”。

但是，在系統(tǒng)調(diào)用這個邊界上提供虛擬化意味著：為Guest提供大量的POSIX接口支持。從安全隔離的角度，這開出了很大的口子，因此，出于安全和性能的考慮，gVisor不得不將一些系統(tǒng)調(diào)用的實現(xiàn)放在它的內(nèi)核里面，并在整個進程外面套一層沙箱環(huán)境（cgroups，namespaces，seccomp）。一直以來，我們也在討論這個話題，這個“界面”越往上，虛擬化的開銷越低，但同時，接口數(shù)量也變得越大，含義越豐富，嚴謹性越弱，即：“攻擊面”越大。_那么，將“界面”畫在哪里才是合理的呢？_可能沒有一種完美的設計可以滿足所有用戶場景。但在針對無服務器計算這個場景，AWS給出的選擇是接口數(shù)量小、含義確定的“虛擬機”模型，不同的是采用極簡的機器模型和設備模型來降低開銷。當然，這也就是說，無論在vCPU還是內(nèi)存方面，firecracker都跟普通虛擬機一樣，沒有gVisor那樣的“彈性”。這也說明，當在安全隔離和其他因素之間做取舍時，AWS首選前者。

此外，Go runtime并不是“免稅”的，它帶來“彈性”的同時也引入了一些不利的影響，Cody Cutler[14]在他paper中對用Go語言編寫的內(nèi)核進行了詳細分析，在此不展開了。最后，我們也看到，自Google開源gVisor以來，已經(jīng)存在幾個漏洞，如[15][16]?？梢婇_發(fā)一個穩(wěn)定的內(nèi)核很不容易，需要嚴謹?shù)脑O計和長時間的打磨。

Firecracker的核心設計準則

無服務計算（Serverless）到底需要什么樣的平臺呢？根據(jù)前面的分析，其實不難看出，AWS已經(jīng)給出了它的答案。

一、對外服務的前提是安全隔離，而硬件輔助虛擬化是在多租戶間進行安全隔離的最低標準。在安全和性能面前， 安全第一。

二、無服務器計算場景下，典型的業(yè)務特征是生命周期短，因此需要它的平臺提供：

啟動快：極簡設備模型，沒有BIOS，沒有PCI，甚至不需要設備直通；

密度高：內(nèi)存開銷低；

水平擴展：因為容器的生命周期短；甚至不需要熱遷移；

三、在提高服務器資源利用率方面，AWS也給出了答案，即：基于統(tǒng)計數(shù)據(jù)搞混部。例如AWS Lambda，它將不同用戶、不同函數(shù)運行在同一組硬件資源上，利用用戶負載的波峰波谷互補（與我們搞混部的思路也是一致的）。