![1.png](https://ucc.alicdn.com/pic/developer-ecology/47cb8942dc874e30b885f05661e1d952.png)

作者 | 易立  阿里巴巴資深技術專家

**導讀**：WebAssembly 技術已經走出瀏覽器，讓計算無處不在。本文利用 containerd 的擴充套件機制，可以為 WebAssembly 應用提供與其他容器應用一致的、抽象的、應用分發、交付和運維模型，可以在 Kubernetes 叢集中進行統一排程和管理。

# 無處不在的 WebAssembly
如果評選 2019 年程式設計技術的“網紅”，無論是前端圈還是後端圈，WebAssembly (WASM) 都絕對能夠高票入選。然而，如果評選最被“低估”的技術，我覺得 WebAssembly 也可以輕鬆入圍。

借用伏爾泰曾評價神聖羅馬帝國的句式 “既不神聖，也不羅馬，更非帝國”，我們也可以說WebAssembly “既不限於 Web，更不是 Assembly（組合語言）”。

在 2019 年 12 月，全球資訊網聯盟 (World Wide Web Consortium  - W3C) 宣佈[ WebAssembly 核心規範正式成為 Web 標準](https://yq.aliyun.com/go/articleRenderRedirect),  這使得 WebAssembly 成為網際網路上與 HTML, CSS, and JavaScript 並列的第四種官方語言，可以原生的執行在瀏覽器上。而更加重要的是，WebAssembly 作為一個安全的、可移植、高效率的虛擬機器沙箱，可以在 Internet 的任何地方、任何平臺（不同作業系統，不同 CPU 體系架構下）安全執行應用。WebAssembly 已得到了所有主流瀏覽器廠商的廣泛支援（Google Chrome, Microsoft Edge, Apple Safari, Mozilla Firefox 等），然而它的影響已經遠超 Web。

WebAssembly 的設計初衷之一是為了解決 JavaScript 的效能問題，使得 Web 網頁應用有接近本機原生應用的效能。作為一個通用、開放、高效的底層虛擬機器抽象，眾多程式語言（如 C/C++, Rust 等）可以將現有應用編譯成為 WASM 的目的碼，執行在瀏覽器中 。這讓應用開發技術與執行時技術解耦，極大促進了程式碼複用。

Mozilla 在 2019 年 3 月推出了 WebAssembly System Interface（WASI），來標準化 WebAssembly 應用與系統資源的互動抽象，比如檔案系統訪問，記憶體管理，網路連線等，類似 POSIX 這樣的標準 API。WASI 規範大大擴充了 WASM 應用的場景，可以讓其可以超越瀏覽器環境，作為一個獨立的虛擬機器執行各種型別的應用。同時，平臺開發商可以針對具體的作業系統和執行環境提供 WASI 介面不同的實現，可以在不同裝置和作業系統上執行跨平臺的 WebAssembly 應用。這可以讓應用執行與具體平臺環境實現解耦。這一切使得“Build Once, Run Anywhere”的理想逐漸形成現實。WASI 的示意圖如下所示。2019 年 11 月，為了進一步推動模組化 WebAssembly 生態系統，Mozilla、Fastly、英特爾和紅帽公司攜手成立了位元組碼聯盟（[Bytecode Alliance](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fbytecodealliance.org%2F)），共同領導 WASI 標準、 WebAssembly 執行時、語言工具等工作。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/d519f083dcc24282bb85a6b74d9c9646.png)

圖片來源：[https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fhacks.mozilla.org%2F2019%2F03%2Fstandardizing-wasi-a-webassembly-system-interface%2F)

# WASM 與容器相愛相殺

## WebAssembly 是否會取代容器？
正因為 WebAssembly 所具備的的安全、可移植、高效率，輕量化的特點，非常適於應用安全沙箱場景。WASM 得到了容器、函式計算、IoT / 邊緣計算等社群的廣泛關注。Docker 創始人 Solomon Hykes 在 WASI 釋出之際的一句 Twitter，更是成為了去年容器和 WebAssembly 社群引用頻率最高的一句話之一。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/2e3f1059dd174683bcecd71241e3845a.png)

Fastly, Cloudflare 等 CDN 廠商基於 WebAssembly 技術實現了更加輕量化的應用安全沙箱，可以在一個程式內部執行多個獨立的使用者應用。阿里雲 CDN 團隊 EdgeRoutine 也實現了類似技術。與容器技術相比，WASM 可以實現毫秒級冷啟動時間和極低的資源消耗。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/c2c9d231f8c6492b8afeff6e279a92b2.png)

原圖：[https://blog.cloudflare.com/cloud-computing-without-containers/](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fblog.cloudflare.com%2Fcloud-computing-without-containers%2F)

當然，世界上沒有完美的技術。任何沙箱技術不可能同時滿足執行效率、安全隔離性和通用性這三個維度的要求。WASM 在安全隔離和通用性等方面與 Docker Container 等存在差距。雖然如此，我們還是看到了 WebAssembly 技術巨大的潛力。

## WebAssembly 容器
我的理解是 WebAssmebly 可以成為一種容器型別，類似 Linux Container 或者 Windows Container 一樣。成為一個跨平臺的標準應用分發方式和執行時環境。

### 應用分發
Docker 容器的一個重要貢獻是其標準化了容器化應用打包規範 Docker Image，而且它已經成為開放容器計劃 (Open Container Initiative - OCI) 的映象格式標準。Docker 映象提供了自包含、自描述的映象格式。它可以將應用以及其依賴的環境資訊打包在一起，從而實現應用與執行環境解耦，讓容器應用可以輕鬆執行在從本地開發環境到雲端生產環境的不同場景中。並且社群圍繞 Docker 映象構建了繁榮的工具鏈生態，如 Docker Hub 可以進行應用分發和 CI / CD 協同，Nortary / TUF 專案可以保障應用可信地分發、交付。

對與 WebAssembly，目前社群提供了類似 NPM 的包管理實現 [WAPM](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fwapm.io%2F)，可以較好地支援應用的分發。 為 WebAssembly 應用構建 Docker 映象，可以實現雙贏的局面。

- WebAssembly 開發者可以完全複用 Docker/OCI 映象規範和工具鏈，進一步簡化應用分發和交付。比如，我們可以將 Nginx 的 WASM 映象作為基礎映象，基於這個映象可以構建包含不同 Web 內容的應用映象；我們可以利用 tag 對應用版本進行追蹤；利用 Docker Registry 進行應用分發；在這個過程我們還可以進一步利用數字簽名來保障安全的軟體供應鏈；
- Docker 映象規範支援 [Multi-Arch](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fdocs.docker.com%2Fdocker-for-mac%2Fmulti-arch%2F) 映象，可以簡化不同 CPU 體系架構（如 x86, ARM, RISC-V 等）的應用映象的構建與分發。而 WebAssembly 天生具備可移植性，大大簡化了跨平臺 Docker 應用映象的構建和分發。參考：[利用 Docker 加速 ARM 容器應用開發和測試流程](https://yq.aliyun.com/articles/712584)。

我提供了一個技術原型[示例專案](https://github.com/denverdino/wasm-container-samples)，大家可以參考其中的例子來構建 WASM 容器映象。由於 WebAssembly 應用採用緊湊的二進位制格式，而且沒有任何作業系統依賴，WASM 應用可以構建出非常小的容器映象。大家可以自行感受一下：

```
$ sudo ctr image ls
REF                                                           TYPE                                                 DIGEST                                                                  SIZE      PLATFORMS   LABELS
docker.io/denverdino/c-http-server-wasm:latest                application/vnd.docker.distribution.manifest.v2+json sha256:2efa759f46f901cda2e6a9b4228c423b17a960c06e957964e72c21dc5b42408f 29.2 KiB  linux/amd64 -
docker.io/denverdino/hellowasm:latest                         application/vnd.docker.distribution.manifest.v2+json sha256:cadcc8b07eb82b18db2c8f500fa2b11e5ebf2e9054cfa687e4ffe44861860132 8.2 KiB   linux/amd64 -
docker.io/denverdino/nginxwasm:latest                         application/vnd.docker.distribution.manifest.v2+json sha256:8735c82524a463b842b7c79f2c1be8094ee1c57cfd34154f68752fbe79c25998 582.7 KiB linux/amd64 -
```

### 安全隔離
WebAssembly 的最初設計目標是讓應用可以安全執行在瀏覽器中。WASM 虛擬機器提供的[沙箱和記憶體隔離機制](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fwebassembly.org%2Fdocs%2Fsecurity%2F)，可以有效減少安全攻擊面。而當 WebAssembly 走出瀏覽器，面向更加通用的場景。WASM 也面對更加複雜的安全挑戰。

WASI 提供了[基於能力的安全模型](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCapability-based_security)。WASI 應用遵循最小許可權原則，應用只能訪問其執行所需的確切資源。傳統上，如果應用需要開啟檔案，它會帶路徑名字串呼叫系統操作 open。然後系統呼叫會檢查應用是否具有訪問該檔案的相關許可權，比如 Linux 實現了基於使用者/組的許可權模型。這樣隱式的安全模型，依賴於正確的安全管理配置，比如一旦特權使用者執行了一個惡意應用，它就可以訪問系統中任意的資源。而對於 WASI 應用而言，如果它需要需要訪問指定檔案等系統資源，需要從外部顯式傳入加有許可權的檔案描述符引用，而不能訪問任何其他未授權資源。這中依賴注入的方式可以避免傳統安全模型的潛在風險。

一個示意圖如下：

![5.png](https://ucc.alicdn.com/pic/developer-ecology/40d139bdf3ce4694916360a7ba9d6b61.png)

原圖：[https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fhacks.mozilla.org%2F2019%2F03%2Fstandardizing-wasi-a-webassembly-system-interface%2F)

我們可以看到 WASI 的安全模型與傳統作業系統安全模型非常不同，而且還在持續演進中。比如位元組碼聯盟提出了 [nanoprocess](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fhacks.mozilla.org%2F2019%2F11%2Fannouncing-the-bytecode-alliance%2F) 來解決應用模組間的安全協同和信任傳遞。

WebAssembly/WASI 的安全模型依然存在不足，比如：

- 資源隔離

對於記憶體資源，WebAssembly 實現了線性記憶體模型。WebAssembly 應用只能利用索引訪問傳入的一段邏輯線性記憶體。而 WASM 虛擬機器負責確定記憶體的實際實體地址，WASM 應用無法獲知記憶體的真實地址，也無法透過越界訪問等方式發動攻擊。所以理論上，可以對 WASM 應用進行資源容量限制。但是目前部分 WASM 虛擬機器還無法對記憶體進行精確的隔離限制。

對於 CPU 資源，部分的 WASM 虛擬機器實現可以對應用使用的 CPU 資源進行計量，但是大多無法實現精確的配額限制、優先順序和搶佔式排程。

I/O 資源，比如 IOPS 等，WASM 目前完全沒有相關的隔離能力。

- 網路安全

WASI 的 Capability 模型對於檔案系統訪問相對比較容易保護。但是這個靜態的安全模型無法適用於動態的網路應用場景。在微服務架構中，應用經常透過 Service Registry 進行服務發現，為服務的呼叫者和提供者實現動態的呼叫繫結。這個語義是無法用靜態的 capability 模型描述和注入的。這也導致了 WASI 的網路部分 API 還處於討論之中。現有的 [WASI 網路安全模型](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fgithub.com%2Fbytecodealliance%2Fwasmtime%2Fblob%2Fmaster%2Fdocs%2FWASI-capabilities.md%23berkeley-socket-rules)，以及相關[討論](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fgithub.com%2Fbytecodealliance%2Fwasmtime%2Fissues%2F70)。

Linux 作業系統和容器技術已經提供了非常完備的資源隔離和安全隔離實現。與 WebAssembly 結合在一起可以應對不同場景對不同隔離級別的需求。

- 共享程式資源 - 多個 WASM 應用模組執行在一個 WASM 虛擬機器程式內部，依賴 WASM 執行時進行隔離。隔離級別低，控制粒度比較粗，資源開銷極小。可以以較小代價保障系統安全。適合受限問題域的應用安全隔離；

- 獨立程式資源 - 不同 WASM 應用模組執行在不同的 WASM 虛擬機器程式中，可以複用作業系統的程式級隔離能力，比如 CGroup。此外，還可以利用類似 Kubernetes 中的 Network Policy (網路策略)，或者服務網格（如Istio）等技術，對程式的網路訪問進行細粒度的控制，甚至實現零信任網路。隔離級別比較高，控制粒度比較細，資源開銷適中。可以應用於更加通用的場景。

注：當然利用安全沙箱如虛擬化等技術，結合 WebAssembly，可以進一步最小化安全攻擊面，但是 ROI 不高。

### 排程與編排
在雲時代，Kubernetes 已經成為分散式環境下資源排程和應用編排的事實標準。Kubernetes 可以遮蔽底層設施的差異性。可以在同一個 K8s 叢集中包含 x86、ARM 等不同體系架構的節點，可以支援 Linux，Windows 等不同的作業系統。Kubernetes 和 WebAssembly 相結合可以進一步提升應用的可移植性。

微軟的 Deis Labs 年初發布了一個[實驗專案](https://github.com/deislabs/krustlet)，來利用 Virtual Kubelet 類似的架構排程 WebAssembly 應用。但是這個方式有很多侷限，無法藉助容器方式進行應用分發，也無法利用 K8s 的語義進行資源編排。

難得有一個春節假期可以宅在家裡，在此期間我基於 Derek McGowan 去年的一個[實驗性專案](https://github.com/dmcgowan/containerd-wasm)，完善了 containerd 的 WASM shim 實現。可以讓 containerd 支援 WASM container，並且可以利用 Kubernetes 叢集管理和排程 WASM container。

專案的程式碼實現: [https://github.com/denverdino/containerd-wasm](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fgithub.com%2Fdenverdino%2Fcontainerd-wasm)

注：這個專案更多是概念驗證，程式管理、資源限制，效能最佳化等的細節並沒未完整實現。

整個系統的架構設計如下，“container-shim-wasm-v1”作為 Containerd 的擴充套件，利用 [wasmer](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fwasmer.io%2F) 作為 WASM 應用執行時環境，可以實現與 runc 容器一致的使用者體驗。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/01ad656dba3b45a79bbc9bca9a26eae0.png)

我們還會將其註冊為 K8s 的一個 [RuntimeClass](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fkubernetes.io%2Fdocs%2Fconcepts%2Fcontainers%2Fruntime-class%2F) ，允許使用者利用 K8s 來交付和運維 WASM 應用。

注：RuntimeClass 是 Kubernetes v1.12 引入的新概念，可以讓 Kubernetes 支援多種不同的容器執行時，比如 runc 容器、或者 Kata Containers，gVisor 等安全沙箱容器。更多細節可以參考：[containerd 與安全沙箱的 Kubernetes 初體驗](https://yq.aliyun.com/articles/723205)。

# Talk is Cheap, 放碼過來
首先，我們將利用 Minikube 建立一個 K8s 測試環境，並將 Containerd 作為 Kubernetes 叢集的容器執行時。

## 建立虛擬機器測試環境
建立 Minikube K8s 叢集，並將 Containerd 作為 Kubernetes 叢集容器執行時。

```
minikube start --image-mirror-country cn \
    --iso-url=https://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/iso/minikube-v1.6.0.iso \
    --registry-mirror=https://tgtsuwdg.mirror.aliyuncs.com \
    --container-runtime=containerd
```

進入 Minikube 虛擬機器：

```
$ minikube ssh
                         _             _
            _         _ ( )           ( )
  ___ ___  (_)  ___  (_)| |/')  _   _ | |_      __
/' _ ` _ `\| |/' _ `\| || , <  ( ) ( )| '_`\  /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )(  ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
```

配置環境所需依賴：

- wasmer 0.13；
- minikube 預設安裝了 container 1.2.x，需要升級 containerd 1.3.x；
- 我提供了一個預編譯的 containerd-wasm-shim-v1，也可自己編譯一個版本。

```
cd ~
# Install Wasmer 0.13.1
curl -L -O https://github.com/wasmerio/wasmer/releases/download/0.13.1/wasmer-linux-amd64.tar.gz
gunzip wasmer-linux-amd64.tar.gz
tar xvf wasmer-linux-amd64.tar
sudo cp bin/* /usr/bin/
# Upgrade containerd to v1.3.2
curl -L -O https://github.com/containerd/containerd/releases/download/v1.3.2/containerd-1.3.2.linux-amd64.tar.gz
gunzip containerd-1.3.2.linux-amd64.tar.gz
tar xvf containerd-1.3.2.linux-amd64.tar
sudo systemctl stop containerd
sudo cp bin/* /usr/bin/
sudo systemctl restart containerd
# Install containerd-wasm-shim
wget http://kubernetes.oss-cn-hangzhou.aliyuncs.com/containerd-wasm/containerd-shim-wasm-v1
chmod +x containerd-shim-wasm-v1
sudo mv containerd-shim-wasm-v1 /usr/bin/
```

## 配置 containerd 支援 WASM shim
在 containerd 配置檔案中新增 wasm shim 相關配置，並重啟 containerd。

```
$ cat <<eof sudo="" tee="" disabled_plugins="["restart"]" runtime_type="io.containerd.wasm.v1" eof="" systemctl="" restart="" containerd="" hello="" world="" wasm="" ctr="" image="" pull="" docker.io="" resolved="" manifest-sha256:cadcc8b07eb82b18db2c8f500fa2b11e5ebf2e9054cfa687e4ffe44861860132:="" done="" layer-sha256:ecda28441283ecf01d35bca0361f2c1ef26a203454a06789ee5ce71ba1e32ca3:="" config-sha256:57974480d640c8d60d254a8b0fa4606b2c7107fe169bc3ddd455091277c3a5e4:="" elapsed:="" s="" total:="" b="" unpacking="" linux="" sha256:cadcc8b07eb82b18db2c8f500fa2b11e5ebf2e9054cfa687e4ffe44861860132...="" run="" io.containerd.wasm.v1="" test1="" nginx="" manifest-sha256:8735c82524a463b842b7c79f2c1be8094ee1c57cfd34154f68752fbe79c25998:="" exists="" layer-sha256:27f4d8ad067fbb709d18ea5acd7a5ddfb85851e5d9f030636e9da3d16cc4bd07:="" config-sha256:a55bd3bdb9d00fdac5ee2f64bfc1856e58e8bb90587943969ad3d8115f4ced70:="" sha256:8735c82524a463b842b7c79f2c1be8094ee1c57cfd34154f68752fbe79c25998...="" test2="" using="" the="" event="" method="" built="" by="" clang="" :="" os:="" getrlimit="" minikube="" echo="" http:="" ip="" runtimeclass="" crd="" kubernetes="" git="" clone="" https:="" cd="" wasm-container-samples="" cat="" wasm-runtimeclass.yaml="" apiversion:="" node.k8s.io="" kind:="" metadata:="" name:="" handler:="" kubectl="" apply="" runtimeclass.node.k8s.io="" created="" get="" name="" at="" k8s="" yaml="" manifest="" pod="" spec="" runtimeclassname="" nginx-wasm.yaml="" v1="" nginx-wasm="" spec:="" runtimeclassname:="" containers:="" image:="" denverdino="" ports:="" containerport:="" ready="" status="" restarts="" age="" running="" web="" webassembly="" serverless="" iot="" ibm="" jiaxu.ljx=""> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”</eof>

“網紅” WebAssembly 與 K8s 如何實現雙劍合璧？

相關文章