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

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平台直接在浏览器上运行C++代码。这允许用户直接在浏览器上运行Adobe的Photoshop和Acrobat，从而无需在用户的机器上下载这些软件工具即可工作。

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

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

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

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

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

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

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

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

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

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

——数据库和消息队列等长期运行的进程，它们都有很强的I/O和内存管理需求。

——保留应用程序状态并大量使用线程的传统（遗留）代码。

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

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