WebAssembly 和 Kubernetes 实际上没有直接的可比性，但 WASM 解决了安全性和易用性等方面的问题，这些问题长期困扰着使用 Kubernetes 的开发人员。

WebAssembly 或 Wasm 被证明是在 web 浏览器上运行原生代码的一种非常实用的方法，可以作为编译器，万维网联盟（W3C）在 2019 年将其命名为网络标准，从而成为继 HTML、CSS 和 JavaScript 之后的第四个网络标准。

由于其在网络浏览器上编写代码和创建应用程序的迅速发展，主要的网络浏览器，包括 Mozilla、Chrome、Internet Explorer 等，都已经与 Wasm 兼容。除了 JavaScript 之外，Wasm 还可以使用的其他语言包括 Rust、Go、.NET、C++、Python、Java 和 PHP。

一个有趣的示例就是 Adobe 如何依赖 Wasm/WASI^[1] 平台直接在浏览器上运行 C++代码，允许用户直接在浏览器上运行 Adobe 的 Photoshop 和 Acrobat^[2] ，从而无需在用户的机器上下载安装这些软件就可以工作。

后来开发人员意识到 Wasm 也可以在服务器操作系统上运行，而且其使用范围现在已经扩展到了硬件平台。它已经证明在许多不同的硬件环境中也是非常有效的，从服务器端到边缘和物联网设备，或者任何代码可以直接在 CPU 上运行的地方。该代码绑定在打包的 Wasm 可执行文件中运行，与容器或甚至小型操作系统相比较，后者可以以代码和目标所需的配置显著减少方式运行。本质上，无论在哪里部署代码，应用程序都远不止局限于 web 浏览器环境。

在许多方面，Wasm 的能力可以与多语言编译器相比，因为它可以容纳多种不同的语言。这在很大程度上是因为与编译器相比，Wasm 的相同二进制可执行文件可以针对多个平台并在多个平台上运行，而无需在 Wasm 和目标设备上配置代码。

通过这种方式，Wasm 无疑是对编译器进行改进，在编译器中，可执行文件和目标环境主机上的代码必须重新配置。跨多个目标的单个二进制可执行文件，无需重新配置：这就是 Wasm 的优点。

Enterprise Management Associates（EMA）^[3] 分析师 Torsten Volk 表示：“Wasm 终让我们能够在服务器、云和边缘设备之间移动代码，而不需要开发人员改动。这将终结束开发人员不得不花费大量时间来为不同的目标平台调整代码，然后支持这些代码的时代。Wasm 的工作是在所有这些平台上提供一个一致的运行时。”

出于这些原因，在某些情况下，Wasm 可以为 Kubernetes 提供一个非常好的替代方案。与 Kubernetes 相比，主要优势有：

简单，在部署应用程序时，甚至在将应用程序分发到不同的终目标时，需要的步骤很少，Cosmonic 的 PaaS 版本可用于在极少数命令行中部署应用程序，大多使用图形界面。使用 Fermyon 和 Fastly 的 Compute@Edge 时也是如此。

正如开发人员和 DevOps 人员所知，作为一名开发人员学习如何使用 Kubernetes 是非常困难的。它需要一个陡峭的学习曲线，通常包括配置 YAML 文件，并确保代码在到达部署和管理操作之前经过许多步骤和过程。

安装 Kubernetes 并部署个应用程序通常需要几个小时，Bindle 维护人员和 Fermyon Technologies^[4] 首席执行官兼联合创始人 Matt Butcher 表示，在大约七分钟内将 Fermyon 平台安装到 DigitalOcean、AWS 或 Azure 上，然后部署 WebAssembly 应用程序“而无需编写一行 YAML”。

安全，在 Kubernetes 这个高度分布式的环境中，安全性现在是，将来也是一个真正的问题，这里要提到的点太多了。微服务的互联性意味着攻击者可以访问一个 pod 中数百个入口中的一个，这可能会对组织的整个基础设施造成破坏。秘密管理^[5] 是另一个问题，在指定容器中谁可以访问它们时会遇到困难。

Wasm 的可移植性和一致性可以使安全性和合规性更易于管理（同样，它在 CPU 级别上以二进制格式运行）。此外，Wasm 结构简单的一部分意味着代码在封闭的 Sandbox 环境中发布，几乎直接发布到端点。并不是说 Wasm 从来没有漏洞可利用。只是 Kubernetes 有更多的可能性和可妥协的接入点。

它们不是一回事

Wasm 提供了巨大的机会，并可能成为一种大规模部署应用程序的方式，我们将在未来几个月和几年看到，随着供应商在用户如何利用它方面变得更有创造力。相比之下，那些预测 Wasm 终会完全取代 Kubernetes 的人，可以说是错过了这一点。目前还无法确定会发生什么，在云环境中部署和管理高度分布式应用程序的其他技术终会取代 Kubernetes。但这极不可能是 Wasm。

这是因为 Kubernetes 永远都有它的用途。当然，它总是用来编排微服务以及容器。事实上也可以认为，Wasm 将在 Kubernetes 中运行，而且它的支持者已经表示，Wasm 非常适合在 Kubernet 环境中运行。

Volk 说：“Wasm 是一个无服务器运行时，开发人员可以将代码部署到其中，而无需同时编写和维护大量的基础设施 YAML。Wasm 为应用程序代码提供了一组标准 API，用于一致访问关键的运行时服务，如 SQL 或 NoSQL、Kafka 消息传递或代码调试。但 Wasm 依赖于一个资源编排层，Kubernetes 或任何其他调度器都可以提供该层，以提供这些服务运行所需的基础设施资源。然后，这些资源可以以容器、虚拟机、裸金属或一些尚未想到的未来技术的形式交付。”

当然并不是所有人都认为 Kubernetes 的容器编排功能将永远是事实标准。Butcher 说，Wasm 领域的许多人都被 HashiCorp 的 Nomad^[6] 调度器所吸引。事实上，Fermyon 已经放弃了 Krustlet（Kubernetes 上的 Wasm），转而选择 HashiCorp Nomad 作为其调度器。Butcher 说：“Nomad 在调度容器和 WebAssembly 方面做得非常出色，我们认为这是云编排者的未来。我们可以想象一个 Kubernetes 衰落，Nomad 取而代之的世界。”

正如 Kubernetes 一样，Nomad 提供了编排容器的能力，但它有一个关键的附加功能：它可以调度非容器工作负载，Butcher 说。“在 Fermyon，我们能够让 Nomad 安排和执行 WebAssembly 应用程序，而无需编写一行自定义代码。”

Butcher 表示，与此同时，Kubernetes 开发人员有责任在较低的级别上接受 WebAssembly，并改变内置的、特定于容器的假设。Butcher 说，微软是家真正接受这一概念的公司，其 runwasi 项目是 WebAssembly 如何在 Kubernetes 内部执行的一个例子。

“不过，runwasi 项目只是 Kubernetes 要想在微服务/容器领域保持霸主地位，需要经历一系列变革的步。Kubernetes 可能落败，如果他们不想被 Nomad 和 Wasm 超越，（其开发人员和维护人员）需要迅速行动。”

生存威胁

Wasm 对 Docker 和容器都构成了生存威胁^[7] ，与 Kubernetes 相比，Wasm 在简单性、可移植性和安全性方面的优势类似，它至少是弥补 Docker 缺点的一个好选择，尤其是对于边缘和分布式应用程序。Butcher 提到 Docker 如何擅长为两种不同的应用程序提供环境：

• 数据库和消息队列等长期运行的进程，它们都有很强的 I/O 和内存管理需求。
• 保留应用程序状态并大量使用线程的传统（遗留）代码。

Butcher 表示：“我对 Docker 的看法是，它在市场上拥有强大的防御能力，Wasm 不太可能取代它。但当涉及到微服务和 web 应用后端时，我认为 WebAssembly 已经准备好蚕食 Docker 的使用。”

因此，Wasm 可以作为某些场景中的 Docker 和容器替代品，但要使用 Wasm 来编排容器和微服务，以达到 Kubernetes 可以用于高度分布式云环境和内部环境的程度，不是这样的。

原文链接：https://thenewstack.io/yes-webassembly-can-replace-kubernetes/

参考资料