一位资深 Kubernetes 工程师眼中的 WebAssembly 未来

在 Kubernetes 社区日的帕萨迪纳站（与 SCaLE 20x 同场），我有机会与 100 名左右的Kubernetes爱好者交谈，通过 Kubernetes 资深人士的视角阐述了我对 WebAssembly 的看法。

我应该通过说我在这个特定游戏中有皮肤来证明这一点。我从一开始就在 Kubernetes 中工作——早期使用Docker （0.6-ish）并从 1.2 开始使用 Kubernetes——在 Kubernetes 平台成为现实之前构建它们。 4 年来，我一直是 Helm 的核心维护者，也是 Bindle 和 Krustlet 的共同创建者——这是让 WebAssembly 与 Kubernetes 更好地配合的早期努力。长篇大论说我完全明白，我理解容器和 Kubernetes 的优势和痛点。

我也来自 WebAssembly 领域，在过去 3 年左右的时间里深入参与其中。两个阵营都有脚，以下是我对这两个开放计划的好处以及交叉点可以 - 并且应该 - 的样子的看法。

Kubernetes 和 Docker 是游戏规则的改变者，因为它们允许平台工程师和开发人员将整体分解为微服务和应用程序，与基础架构的其余部分隔离开来进行管理。 WebAssembly 更深入，允许我们将单个应用程序拆分为可组合的组件，这些组件可以热交换、管理和配置到它们的环境。从本质上讲，Wasm 是我们在服务器端代码中想要的一切：默认安全、可移植、多语言（特别是在浏览器中）、快速、高效和高度可扩展。

那么，Kubernetes 和 Wasm 是如何交叉的呢？首先，让我们解决社交媒体谣言工厂并打破一些神话。

误解 #1：Wasm 会杀死容器。

没有。当然不。当 Redis 在容器中运行良好时，没有人会重写Redis以在浏览器中运行。在很多情况下，Kubernetes 都是正确的解决方案。有许多大型企业应用程序（Drupal、Redis、nginx）已经存在了很长时间，但不会很快迁移到 Wasm。

误区 #2：我应该继续在我的容器中运行 Wasm，对吗？

我们并不是说你不应该这样做，但这可能不是正确的起点，你可能只是增加了额外的复杂层。您有启动 Docker 容器（不是跨平台的）的开销，加上启动 WebAssembly 的开销。这可能不值得性能开销，尤其是对于我稍后将提到的所有可用工具]

误解 3：Wasm 与 Kubernetes 不兼容。

是的！这是一个“Better Together”的故事。一切都随着计算机的发展而进化。仅仅因为我们想出了 VM 并不意味着我们不需要物理硬件。仅仅因为 Wasm 的出现，并不意味着我们不需要容器。要了解实际情况，请阅读我们在 Adob​​e 的朋友如何使用 Wasm 转变他们的 Kubernetes 架构。

就像 Kubernetes 的早期阶段一样，我们正处于事物快速发展的阶段。在原始 Wasm 级别的服务器端联网仍然很困难。我们很快就会获得套接字支持，而且进展很快。语言工具链和低级高性能代码也很重要，但目前还没有。不过，这是一个激动人心的时刻。 WASI（非浏览器 Wasm）标准已经取得了长足的进步，即使在过去的几周内也是如此——稍后会详细介绍。

为什么是 Wasm ？

事实上， Kubernetes 有其局限性，尤其是在边缘。尽管已经取得了很多进展（对 K3s 等项目的大力支持），但事情只能到此为止。 Kubernetes 旨在运行在通常属于同一地理区域的集群中。当某些东西在手机信号塔、发电站或实体店中运行时，Kubernetes 无法很好地扩展。我们在与社区成员交谈时已经看到了这一点。 Wasm 是真正的跨平台架构，运行起来非常小，使其成为边缘的更好候选者。

成本和利用率也是主要因素。我们已经与多家财富 100 强公司进行了交谈，他们的 Kubernetes 服务器利用率约为总容量的 25-35%，少数高达 50-60%。许多人已经解散了他们的内部 Kubernetes 团队，因为它太贵了。 Wasm 允许我们在更小的空间中打包更多东西，并更好地利用它。

安全性也是 Wasm 的一大优势。容器相当安全，但有很多细微差别会造成复杂性，尤其是对开发人员而言。默认情况下，除非您授予 WebAssembly 模块这样做的权限，否则它什么也做不了。

我们现在可以用 Kubernetes 和 Wasm 做什么？

尽管如此，现在使用 Wasm 和 Kubernetes 实际上可以做什么？让我们回顾一下您可以立即利用 Wasm 的三个最大场景。

CNCF containerd中的runwasi

使用 Wasm 的一种非常酷的方法是查看精彩的runwasi项目，它是 CNCF 的 containerd 生态系统的一部分。本质上， runwasi允许您通过 Kubernetes 内部的 containerd shim 运行 WebAssembly 运行时。与尝试在容器内运行 Wasm 相比，这是一个更好的选择，因为它直接运行 WebAssembly，就像在 pod 中启动容器一样。

服务网格，有人吗？

Envoy 和其他网格已经具备使用 WebAssembly 编写插件的能力。有了这些，您可以使用任何编译为 WebAssembly 的语言编写自定义过滤和其他插件模型。

wasmCloud

我们知道公司已经看到在许多不同的用例中将 Kubernetes 与 Wasm 结合在一起的价值。但wasmCloud将其提升到一个新的水平，因为它能够在平面网络拓扑中连接不同的计算。我的第二个演示展示了在三个不同的节点上移动相同的代码是多么容易，每个节点都在不同的位置。在这种情况下，我在帕萨迪纳的 Mac、纽约的 Digital Ocean K8s 集群和 wasmCloud。无需重构，相同代码，任何位置。接下来，Cosmonic 平台（建立在 wasmCloud 上）将为 Wasm 带来企业在转向生产时需要的那种全方位服务方法。

想在托管平台上试用 wasmCloud 吗？

立即免费开始使用 Cosmonic。立即启动！

组件模型

最后，也是最令人兴奋的是，这个领域的发展速度很快。查看 Bailey Hayes 和 Dan Chiarlone 的WASM I/O演讲，其中展示了我们在定义 WASI 标准和组件模型方面取得的进展——这是我们真正希望未来是什么样子的第一个视图。您可以在此处关注进展并加入字节码联盟以了解最新消息。

- Cosmonic 工程主管Taylor Thomas

如果您有兴趣了解更多信息、有疑问或想聊天，请在Discord或Slack上与我们联系。