作者丨B. Cameron Gain

编译丨诺亚

出品 | 51CTO技术栈（微信号：blog51cto）

虽然WebAssembly (Wasm)已被证明在浏览器和某些有针对性的服务器部署中可以很好地工作，但允许开发人员“一次部署，随处部署”的标准化组件模型尚未实现。

当开发人员可以将代码加载到 Wasm 模块中，并将其同时部署在能够运行 CPU 指令集的各种环境和设备类型中时，这一愿景就会实现。更具体地说，开源社区在努力开发 Wasi，致力于在许多方面将Wasm模块连接到组件的标准接口或API。但是，我们还没有到那一步。

然后是 Kubernetes。

容器和 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/