在 Kubernetes 上使用 WebAssembly: 从容器到 Wasm

我是阳明

发布于 2024-03-20 21:50:53

5930

发布于 2024-03-20 21:50:53

文章被收录于专栏：k8s技术圈

WebAssembly（Wasm）最初是为浏览器创建的，现在在服务器端也越来越受欢迎。在我看来，WebAssembly 在云原生生态系统中变得流行的原因是它相对于容器的优势，包括体积更小、速度更快、安全性更强和可移植性更高。

本文我将简要介绍 WebAssembly 并解释其优势。然后我们将在后面的文章中讨论如何使用容器工具（包括低级容器运行时、高级容器运行时和 Kubernetes）执行 Wasm 模块。

什么是 WebAssembly？

WebAssembly 是一种通用的字节码技术，允许用各种语言编写的程序（如 Go、Rust 和 C/C++）被编译成字节码，可以直接在网络浏览器和服务器内部执行。

WebAssembly 是从头开始设计的，用来解决 JavaScript 的性能问题。使用 WebAssembly，开发人员可以将代码编译为低级二进制格式，以接近本机速度在现代网页浏览器中执行。

2019年3月，Mozilla 发布了 WebAssembly 系统接口（WASI），这是一个 API 规范，定义了 WebAssembly 模块与宿主环境之间的标准接口。WASI 允许 Wasm 模块安全地访问系统资源，包括网络、文件系统等。这极大地扩展了 WebAssembly 的潜力，使其不仅能够在浏览器中运行，还能在服务器上运行。

WebAssembly 的优势

WebAssembly 具有几个显着优势，超越了传统容器：

快速：Wasm 模块通常在毫秒内启动，比传统容器快得多，这对需要快速启动的工作负载（如无服务器函数）至关重要。
轻量级：与容器镜像相比，Wasm 模块通常占用更少的空间，并且需要更少的 CPU 和内存资源。
安全：Wasm 模块在严格的沙箱环境中运行，与底层主机操作系统隔离，减少潜在的安全漏洞。
可移植：Wasm 模块可以在各种平台和 CPU 架构上无缝运行，消除了为不同操作系统和 CPU 组合定制的多个容器镜像的需要。

你可以查看此表格，详细比较了 WebAssembly 和容器之间的差异：WebAssembly vs Linux Container：https://wasmedge.org/wasm_linux_container/。

在 Linux 容器中运行 Wasm 模块

在容器生态系统中执行 Wasm 模块的一种简单方法是将 Wasm 字节码合并到 Linux 容器镜像中。具体而言，容器内部的 Linux 操作系统可以被精简为仅包含支持 Wasm 运行时所需的组件。由于 Wasm 模块存储在标准容器中，它们可以与任何现有的容器生态系统无缝集成。

瘦身的 Linux 操作系统相比于常规 Linux 操作系统具有更小的攻击面。然而，这种方法仍然需要启动一个 Linux 容器。尽管 Linux 操作系统被裁剪了，但它仍然占据了容器镜像大小的 80%。

在支持 Wasm 的容器运行时中运行 Wasm 模块

将 Wasm 模块嵌入到 Linux 容器中的优势在于允许与现有环境无缝集成，同时也可以从 Wasm 带来的性能改进中受益。然而，与直接在支持 Wasm 的容器运行时中运行 Wasm 模块相比，这种方法效率和安全性较低。

一般来说，容器运行时可以分为两个级别：高级运行时和低级运行时。

低级容器运行时：指的是符合 OCI 标准的实现，可以接收一个可运行的文件系统（rootfs）和一个配置文件（config.json）来执行隔离的进程。低级容器运行时直接管理和运行容器，比如 runc、crun、youki、gvisor 和 kata。
高级容器运行时：这个组件负责传输和管理容器镜像，解压镜像，并将其传递给低级运行时来运行容器。高级容器运行时通过抽象低级运行时的复杂性简化了容器管理，使用户能够通过相同的高级运行时管理各种低级运行时。Containerd 和 CRI-O 是两个流行的高级容器运行时。

我们可以在低级和高级容器运行时中启用 Wasm 支持。

通过低级容器运行时直接运行 Wasm 模块时，有几种可用的选项，如 crun 和 youki，这些选项内置支持 Wasm。

通过高级容器运行时运行 Wasm 模块时，CRI-O 和 containerd 都是不错的选择。有两种可能的方法：

一种是高级运行时仍依赖于低级运行时，调用低级运行时执行 Wasm 模块。
另一种方法是 containerd 有一个名为 runwasi 的子项目，可以开发一个 containerd-wasm-shim，直接与 Wasm 运行时（如 WasmEdge 和 Wasmtime）进行交互。这样 containerd 可以在不依赖低级运行时的情况下运行 Wasm 模块，而是直接调用 Wasm 运行时。这不仅缩短了调用路径，还提高了效率。

在 Kubernetes 上运行 Wasm 模块

WebAssembly 正推动云计算的第三波浪潮。作为容器编排领域的事实标准，Kubernetes 不断演进以利用 WebAssembly 带来的优势。

要在 Kubernetes 上运行 Wasm 工作负载，需要两个关键组件：

使用 Wasm 运行时引导的工作节点。可以通过集成高级容器运行时（如 containerd 和 CRI-O）与支持 Wasm 的低级运行时（如 crun 和 youki）来实现此设置。
映射到具有 WebAssembly 运行时的节点的 RuntimeClass 对象。RuntimeClass 处理 Kubernetes 集群中存在多个容器运行时的问题，某些节点可能支持 Wasm 运行时，而其他节点可能支持常规容器运行时。您可以使用 RuntimeClass 将 Wasm 工作负载专门调度到具有 Wasm 运行时的节点。

要在 Kubernetes 节点上启用 Wasm 支持，可以使用 Kwasm Operator 自动化过程，而不是手动安装具有 Wasm 运行时库的容器运行时。Kwasm(https://kwasm.sh/) 是一个 Kubernetes Operator，它会自动为您的 Kubernetes 节点添加 WebAssembly 支持。Operator 使用 kwasm-node-installer(https://github.com/KWasm/kwasm-node-installer) 项目来修改底层 Kubernetes 节点。

总结

WebAssembly 提供了一种快速、高效和安全的代码执行方式，而 Kubernetes 则是一个强大的容器编排平台。Cloud Native WebAssembly 在服务器和云中使用 Wasm，利用 Kubernetes 等编排工具来部署和管理 Wasm 应用程序。通过结合这些技术，我们可以创建灵活、高性能、可扩展和安全的云原生应用。这种融合提供了创新的可能性，可以开发先进的无服务器架构、边缘计算解决方案，同时确保在不同环境中的兼容性和可移植性。