作者丨B. Cameron GAIn
編譯丨諾亞
出品 | 51CTO技術棧（微信號：blog51cto）
雖然WebAssembly (Wasm)已被證明在瀏覽器和某些有針對性的服務器部署中可以很好地工作，但允許開發人員“一次部署，隨處部署”的標準化組件模型尚未實現。
當開發人員可以將代碼加載到 Wasm 模塊中，并將其同時部署在能夠運行 CPU 指令集的各種環境和設備類型中時，這一愿景就會實現。更具體地說，開源社區在努力開發 Wasi，致力于在許多方面將Wasm模塊連接到組件的標準接口或API。但是，我們還沒有到那一步。
然后是 Kube.NETes。
容器和 Kubernetes 環境已基本準備好進行 Wasm 模塊部署，而 Wasm 模塊也已基本準備好在 Kubernetes 上部署。盡管有傳言說 Wasm 有朝一日可能會取代容器——甚至是 Kubernetes——但一個非常好的結合WebAssembly和Kubernetes的契機正在出現。
1、將 Wasm 與 Kubernetes 結合使用的優勢
將 Wasm 與 Kubernetes 一起使用具有一些內在優勢。例如：安全性。由于 Wasm 二進制文件的冷啟動時間以毫秒為單位，而某些虛擬機的冷啟動時間可能以分鐘為單位，因此 Wasm 的安全模型實際上比容器和 Kubernetes 的安全模型要強一些。這是因為無法立即訪問 linux 內核。
所有代碼都是通過 Wasm 主機運行時中介的，這意味著你可以攔截所有的系統調用——至少在理論上是這樣。換句話說，Wasm 可以在容器和 Kubernetes 集群中提供額外的安全層。
目前還不能做到：點擊一個簡單的按鈕就在 Kubernetes 上部署 Wasm 模塊。但一些供應商，如 Fermyon，已經提供了在容器和 Kubernetes 上部署 Wasm 的無服務器服務。
這一進步很大程度上歸功于對 Wasm 的容器支持，以及 Docker 在 2022 年引入了對 Wasm 的 beta 支持。從那時起，它就成為 Kubernetes 支持高度分布式部署的主要推動者，并允許用戶隨意啟動和關閉由 Wasm 模塊組成的應用程序。
Containerd的使用也起著重要作用，container shim是有助于將容器與運行時代碼集成的進程。
Fermyon聯合創始人兼首席執行官Matt Butcher提到：“微軟和許多其他公司將Wasm shim(就像Spin shim)添加到containerd項目中所做的工作是在Docker桌面版和許多Kubernetes發行版上解鎖Wasm的原因。”
Butcher說，Docker Desktop和Microsoft Azure AKS都率先展示了如何做到這一點。最近，他指出，Civo 在其 Kubernetes 產品中引入了支持，“這表明大大小小的云提供商正在促進向 WebAssembly 的轉變”。
2、Wasm 和 OpenShift
其他軟件制造商和服務提供商也正在登上契合Wasm 的 Kubernetes 列車。其中包括紅帽，它已經在調整 OpenShift 以適應 Wasm 模塊并支持 Ferymon 的 Spin。紅帽將 Wasm 視為一種有趣的跨平臺開發方法，并為相關的上游社區做出了貢獻。
紅帽首席軟件工程師 Ivan Font介紹，截至今天，Kubernetes 提供了運行基于 Wasm 的工作負載所需的編排和基礎設施，這為現有的 Kubernetes 投資提供了額外的靈活性。
截至目前，紅帽的平臺中還沒有 Wasm 的產品化。但該公司表示，它將繼續與其他供應商和社區合作，根據用戶組織的需求開發其潛力。
紅帽正在開發 Spin 以在 OpenShift 上運行，并為 Wasi（Wasm 和組件接口）和 WasmEdge 的開發做出貢獻，WasmEdge 是為云原生（當然是 Kubernetes）、邊緣和去中心化應用程序創建的可擴展 Wasm 運行時。根據 WasmEdge 文檔，WasmEdge 還為無服務器應用程序、嵌入式功能、微服務、智能合約和物聯網設備提供支持。
就目前而言，紅帽的 OpenShift 默認使用 WasmEdge，因為 Fedora Linux 發行版已經支持了一個紅帽包管理器（RPM），并且紅帽為 Wasm 提供了額外的支持。
“但是，你可以使用任何一個，因為兩個 WebAssembly 運行時都在朝著類似的方向發展，”Font 說。“它們都專注于邊緣，并具有人工智能功能等。”
要將特定工作負載作為基于 Wasm 的工作負載運行以在 OpenShift 上執行，你目前需要指定一個注解，指示你要執行的操作。此執行是在容器內完成的，但它具有獨特的特征。
當 Wasm 應用程序被打包時，它只是鏡像中的一個模塊。這意味著開放容器計劃 （OCI） 容器映像不包含任何外部依賴項或完整的操作系統文件系統。因此，圖像大小非常小，因為它們只包含你的 Wasm 模塊。Font 說，這通常適用于容器，而 OCI 是這方面的標準。
Butcher 說，Fermyon 一直在與 KWasm 的創建者 Liquid Reply 以及紅帽合作，以在 OpenShift 的 Wasm 功能和基于容器的 Kubernetes 發行版之間實現一定程度的對等。他說，這種合作“從企業級AKS延伸到微型K3”。
3、更多適用于 Wasm 和 Kubernetes 的工具即將到來
開發人員將有更多的工具可用于在 Kubernetes 集群上構建和部署應用程序，Civo 的現場首席技術官兼云原生計算基金會大使 Saiyam Pathak如是認為。
“如果你有一個 Kubernetes 集群，你可以簡單地再添加一個負載，使它為WebAssembly做好準備。”Pathak 說。
Pathak 說，這個過程很簡單：它包括確保一切都配置正確，包括重新啟動 containerd、編輯 containerd .normal 文件以及在該特定節點上使用 Wasm 運行時。然后它就可以運行你的 Wasm 工作負載了。
Pathak說：“這太棒了，因為你現在可以使用過去10年一直使用的相同工具和部署過程，將最新的WebAssembly技術用于你的下一組應用程序。無論你是構建 API 還是擴展你的應用程序，你都可以在同一個基礎設施和 Kubernetes 集群中使用 WebAssembly，以及 Docker。”
Kasten 提供 Kubernetes 數據管理平臺和災難恢復支持，它著眼于 Wasm 在其 Kasten K10 平臺的技術能力和支持客戶方面的實用性。Wasm 不是數據移動支持的綜合解決方案，但它是 Kasten 正在為 Kubernetes 尋找的東西，因為 Kasten 正在探索如何在 K10 中使用 Wasm。
“作為一個 Kubernetes 原生應用，我們正在研究如何利用 WebAssembly 來簡化和使事情更快、更高效、更安全：你從 Wasm 本身獲得的所有好處，”Veeam 全球現場首席技術官、Kasten 的所有者 Michael Cade還提到：“但 WebAssembly 是一切的答案嗎？也不是。”
相比之下，虛擬機也不是萬能的，Cade說：“如果我有一張物理硬件卡，在一臺物理機器上，在我最重要的應用服務器上，我可能會虛擬化它，也可能不會。如果沒有，我永遠無法將其容器化。”
WebAssembly 蓬勃發展的地方，尤其是對于 Kubernetes 來說，是圍繞著三個“S”（speed, security，support）：速度、安全性以及大多數 Web 前端服務器或 Web 模塊已經支持。
4、RunWasi：進步的催化劑
開源 RunWasi 項目的進展可能會成為 Wasm-on-Kubernetes 部署的催化劑。RunWasi 的創建是為了通過 containerd 在 Wasm 模塊中支持 Wasm 運行時。
運行時的部署過程是使用 containerd shim完成的，RunWasi 提供必要的代碼。這些shim將 Wasm 模塊從 containerd 編排到部署代碼的低級運行時。
以下列表顯示了流行的 Wasm containerd shim，由 Microsoft 的 Deis Labs 提供：
- Lunatic，一個受 Earlang 啟發的運行時，用于快速、健壯和可擴展的服務器端 Wasm 應用程序。
- Spin，一個用于構建和運行無服務器 Wasm 應用程序的開發者工具。
- Slight，一個基于Wasmtime 的運行時，用于運行使用 SpiderLightning （WASI-Cloud-Core） 功能的 Wasm 應用程序。
- Wasm Workers Server，一個在 Wasm 之上開發和運行無服務器應用程序的工具。
在 10 月初的 Docker 年度用戶大會上，軟件培訓師 Nigel Poulton 展示并描述了他如何使用 Spin 作為 Wasm 框架，在Wasm模塊中為應用程序創建Wasm工件，然后將其打包到 Docker 容器中。他還描述了如何設置一個多節點 Kubernetes 集群，其中包含一個控制平面節點和兩個工作線程。
至關重要的是，Poulton 描述了他如何擁有“運行這些 Wasm 工作負載所需的軟件，而且都是簡單的容器化的東西”。
參考鏈接：
https://thenewstack.io/can-kubernetes-solve-webassemblys-component-challenges/
