Helm 4 中的 WebAssembly (Wasm) 插件显著增强了 Kubernetes 的可扩展性、安全性和可移植性。Wasm 不仅提供了强大的隔离性，还能带来更快的性能，从而有效降低了开发人员的操作开销。它的核心价值在于提供了一套高效的“一次编写，随处运行”解决方案，旨在改进和增强现有的 Kubernetes 工具生态，而非取代 Kubernetes 本身。
译自：How WebAssembly plugins simplify Kubernetes extensibility
作者：B. Cameron Gain
将 WebAssembly (Wasm) 集成到 Helm 生态系统中，极大地简化了跨不同环境（包括 OCI 容器和虚拟化基础设施）对 WASI 兼容二进制文件的编排。通过利用 Helm 成熟的模板引擎，开发人员可以标准化沙盒模块的生命周期管理，同时保持其高度的可移植性。
尽管 Wasm 本身通过基于能力的安全模型就提供了故障隔离的执行环境，但结合 Helm 在 Kubernetes 原生环境下的部署，进一步强化了这种隔离。这种双重保障确保了应用程序既能受益于指令级的沙盒安全，又能获得集群范围的管理隔离，从而在微服务架构中有效提升了整体安全性。
在性能方面，也有明显的提升空间。根据 ReveCom 的数据，在比较传统的 Helm 3 插件与 Helm 4 Wasm 插件时，延迟等关键指标可能出现高达 40% 的波动（可能提升也可能降低）。此外，Wasm 引以为傲的“一次编写，随处运行”特性再次得到体现，允许同一模块在 x86、ARM 等多种 CPU 架构上无缝安装和运行。
对于 ArgoCD 这类工具，虽然我们尚未进行针对性测试，但理论上通过 Argo 运行 Wasm 插件可能会获得略微的性能优势。更重要的是，Wasm 模块增加了一层额外的隔离和安全性。这并非指 ArgoCD 不安全，而是 Wasm 为 Helm 插件体系增添了一道防护。对大多数应用场景而言，这细微的性能差异或许可以忽略，但安全增益却是实实在在的。
对比 Kubernetes
可能有人会问：WebAssembly，尤其是在其组件模型完善后，是否有一天会取代 Kubernetes？从长远来看，或许存在这种可能性，但显然不会是完全替代。然而，Helm 对 WebAssembly 的支持并不会加速这一进程。如果那一天真的到来，Helm 本身也可能变得不再必要。
Couchbase 的高级开发人员体验工程师 Shivay Lamba 基本认同这一观点：“Helm 采用 WebAssembly 插件实际上是增强了 Kubernetes，而不是削弱它。其主要动机是帮助提高可扩展性、安全性和可维护性。虽然 WebAssembly 引入了一种引人注目的执行和隔离模型，但 Helm 使用 Wasm 仍然将 Kubernetes 作为控制平面、调度器和生命周期管理器。如果 WebAssembly 要真正取代 Kubernetes，它将需要一个原生的、Wasm 优先的编排模型，完全消除以容器为中心的抽象需求。这项新变化是一种进化，而非革命。它优化了我们扩展 Kubernetes 工具的方式，而非挑战其核心作用。”
不过，Wasm Helm 插件确实提供了一层优异的额外隔离。实际上，在 Kubernetes 上通过 WebAssembly 运行应用程序已有一段时间。如果你正在使用无服务器应用，无论是在云端还是在诸如 LightXL 的服务器上，你可能已经在不知不觉中使用了 WebAssembly。
此次插件发布的核心价值，尤其对于已经在使用 Helm 的团队而言，在于它大幅减少了在 Kubernetes 和容器化基础设施上运行 WebAssembly 模块所需的工作量。“Helm Wasm 插件系统的真正价值是实用的：它降低了摩擦。通过减少在现有环境中运行 WebAssembly 工作负载所需的操作和认知开销，它使 Wasm 对已标准化使用 Helm 的团队更易访问，” Lamba 解释道，“这与 WebAssembly‘一次编写，随处运行’的承诺高度吻合，不是通过替换基础设施，而是通过巧妙地融入其中。重要的是，Wasm 强大的隔离保证得以保留，同时 Helm 增加了熟悉的打包、分发和生命周期管理。此版本不是重新定义平台堆栈，而是通过满足开发人员的现有需求来加速采用。”
Helm 的创建者之一，Akamai Technologies 产品管理副总裁兼联合创始人 Matt Butcher 表示，早在开发 Helm 3 时，团队就意识到了为用户提供定制 Helm 行为途径的需求。“当时我们考察了 Lua，但始终没有找到满意的模型。如今，WebAssembly 是一个比 Lua 好得多的替代方案，” Butcher 说。
这帮助实现了 WebAssembly 的一个核心承诺：编写一次应用，将其打包为 Wasm 模块，即可在众多支持该指令集的端点上运行，同时保持强大的隔离性。“现在你可以用多种语言编写 Helm 插件，并获得 WebAssembly 运行时的所有优势：速度、可移植性、安全性以及标准合规性。WebAssembly 作为插件载体一直是一个引人注目的用例，Helm 4 证明了这一点，” Butcher 补充道，“但这并非我们在 Kubernetes 生态中看到 Wasm 的唯一应用。CNCF 项目，如 Spin 和 SpinKube，将继续将 WebAssembly 用于其他目的，例如无服务器函数。”
对于关注云原生技术前沿的开发者而言，这类融合了 Wasm、Kubernetes 和 Helm 的实践，正是技术生态持续演进的方向。在 云栈社区 等平台上，经常能看到对此类深度整合方案的探讨与分享。
引用链接
- How WebAssembly plugins simplify Kubernetes extensibility: https://thenewstack.io/how-webassembly-plugins-are-simplifying-kubernetes-extensibility/
- WebAssembly: https://thenewstack.io/webassembly/
- Helm: https://thenewstack.io/helm-4-whats-new-in-the-open-source-kubernetes-package-manager/
- WASI: https://thenewstack.io/wasi-preview-2-what-webassembly-can-and-cant-do-yet/
- Kubernetes: https://thenewstack.io/kubernetes/
- ReveCom: http://www.revecom.io
- CNCF: https://cncf.io/?utm_content=inline+mention
发表于 2 小时前
|
查看: 2|
回复: 0
