我认为，WebAssembly 可以解决 Kubernetes 的一些问题。
WebAssembly（简称Wasm）是一种在 Web 浏览器上运行代码的方式，可以充当各种编译器。它作为一种语言也广受好评，2019 年万维网联盟（World Wide Web Consortium，W3C）将其命名为网络标准，成为继 HTML、CSS 和 JavaScript 之后的第四个网络标准。
现如今的主流 Web 浏览器，包括 Mozilla、Chrome、IE 等，都可以兼容 Wasm，因为它已成为在 Web 浏览器上编写代码以及创建应用程序的新兴渠道。除了 JavaScript 之外，Wasm 还可以兼容包括 Rust、Go、.NET、C++、Python、Java 以及 PHP 在内的许多其他语言。
举一个有趣的例子，Adobe 依赖 Wasm/WASI 平台直接在浏览器上运行 C++ 代码。这样，用户就可以直接在浏览器上运行 Adobe 的 Photoshop 和 Acrobat，不必将这些工具下载到自己的设备上了。
最后，开发人员意识到 Wasm 也可以在服务器操作系统上运行，并且可以扩展到硬件平台。事实证明，Wasm 可以在许多不同的硬件环境中正常运行，包括从服务器端到边缘部署和物联网设备，或者任何可以直接在 CPU 上运行代码的设备。代码将被整齐地打包到 Wasm 可执行文件中，有点类似于容器甚至是迷你操作系统，而且 Wasm 运行代码所需的配置非常少。代码可以随意部署到任何地方，应用程序将不再局限于 Web 浏览器的环境。
从许多方面来看，Wasm 就相当于多语言编译器，因为它可以容纳多种不同的语言。然而，与编译器相比，Wasm 的二进制可执行文件可以在多个平台上运行，无需在 Wasm和目标设备上配置代码。
从这个角度来说，Wasm 甚至超越了编译器，因为在编译器时代，可执行文件和目标环境主机上的代码必须经过重新配置。Wasm 的优势就在于，它能创建一个跨平台的二进制可执行文件，无需重新配置。
Enterprise Management Associates 的分析师 Torsten Volk 表示：“有了 Wasm，我们终于无需开发人员参与，便可以在服务器、云和边缘设备之间移动代码。以前，开发人员不得不花费大量时间调整代码，并支持不同目标平台上的代码，这样的时代终将结束。Wasm 统一提供了一个可服务于所有平台的运行时。”
综合上述原因，我们认为在某些情况下，Wasm 可以成为一个很好的 Kubernetes 替代方案。与 Kubernetes 相比，Wasm 的主要优势包括：
简单性。在部署应用程序时，Wasm 可以省却一些步骤，即便应用程序需要分发到不同的目标设备上也没有问题。Cosmonic 的 PaaS 版本提供了图形界面，因此部署应用程序时需要运行的命令非常少。此外，还可以使用 Fermyon 和 Fastly 的 Compute@Edge。
相对而言，开发人员学习使用 Kubernetes 是非常困难的。学习曲线很陡峭，需要配置大量 YAML 文件，而且需要经过许多步骤和过程才能将代码部署到集群中。
安装 Kubernetes 和部署第一个应用程序通常需要几个小时，但将 Fermyon 平台安装到 DigitalOcean、AWS 或 Azure 上只需七分钟，然后你就可以部署 WebAssembly 应用程序了，不需要编写任何 YAML。
安全性。在 Kubernetes 这类的分布式环境中，安全性仍然是一个很重要的问题。微服务之间的相互连接意味着，攻击者一旦获得 Pod 中上百个入口点中的一个的访问权，就有可能对组织的整个基础设施造成严重破坏。另一方面，机密的管理也是一个问题，我们很难指定谁有权访问容器中的机密数据。
而 Wasm 的可移植性和一致性可以降低管理安全性和合规性的难度。此外，Wasm 的结构十分简单，这意味着代码在封闭的沙盒环境中发布，几乎可以直接发布到端点——我们并不是说 Wasm 没有任何可以利用的漏洞，只不过 Kubernetes 被攻击的可能性更高。
Wasm 与 Kubernetes 的目标不同
Wasm 提供了巨大的机会，并且可能成为一种大规模部署应用程序的方式，在未来几个月和几年内，我们将看到，供应商会想方设法为用户创造更多机会利用 Wasm。但我们不能简单地认为 Wasm 终将取代 Kubernetes，也许将来可能会出现某种技术，在云环境中部署和管理分布式应用程序，并最终取代 Kubernetes，但不太可能是 Wasm。
Kubernetes 有其独到的用途，比如编排微服务和容器等。我们可以认为，Wasm 将在 Kubernetes 中运行，也已有人认为 Wasm 非常适合在 Kubernetes 环境中运行。
“Wasm 是一个无服务器运行时，开发人员可以将代码部署到其中，同时无需同时编写和维护大量基础设施的 YAML。Wasm 为应用程序提供了一组标准的 API，供我们统一访问核心的运行时服务，例如 SQL 或 NoSQL、Kafka 消息传递或代码调试。” Volk 表示：“而 Wasm 需要依赖的资源编排可以由 Kubernetes 或其他调度程序提供。”
然而，并非所有人都认为 Kubernetes 的容器编排能力永远都是无可替代的。Butcher 说，Wasm 领域的许多人都被 HashiCorp 的 Nomad 调度程序所吸引。ermyon 已经放弃了 Krustlet（Wasm-on-Kubernetes），转而使用 HashiCorp Nomad 作为调度器。
Butcher 表示：“Nomad 的容器调度和 WebAssembly非常出色，我们认为这是云协调器的未来。我认为也许未来 Kubernetes 将逐渐消失，由 Nomad 取而代之。”
Nomad 也提供编排容器的功能，就像 Kubernetes 一样，但前者还有一个重要的附加功能：编排非容器工作负载。Butcher 说：“在 Fermyon，我们通过 Nomad 调度应用程序，然后再通过 WebAssembly 执行，整个过程无需编写任何代码。”
与此同时，Kubernetes 开发人员需要接受 WebAssembly，并改变内置的、特定于容器的功能。微软是第一家真正接受这一概念的公司，他们的 runwasi 项目就是在 Kubernetes 内部运行 WebAssembly 的一个例子。
Butcher 表示：“只不过，runwasi 项目只是第一步，Kubernetes 要想守住微服务与容器领域的霸主地位，就需要进行一系列的转型。在这场比赛中，目前 Kubernetes 处于不利地位，如果不想被 Nomad 和 Wasm 超越，开发人员和维护者需要迅速采取行动。”
潜在的威胁
Wasm 威胁到了 Docker 以及容器的生存。Wasm 在简单性、可移植性和安全性方面的优势使其成为弥补 Docker 缺点的备选之一，尤其是对于边缘和分布式应用程序而言。但是，Docker 擅长为两种不同类型的应用程序提供环境：
长时间运行的进程，如数据库和消息队列，它们对 I/O 和内存管理都有着强烈的需求。
应用程序内部残留的许多旧代码不仅保存了状态，而且还大量使用线程。
Butcher表示：“我认为，Docker 在市场上拥有强大而稳固的地位，不太可能被 Wasm 取代。但是，对于微服务和 Web 应用程序的后端，我认为 WebAssembly 完全可以取代 Docker。”
因此，在某些情况下，Wasm 确实可以取代 Docker 和容器，但 Wasm 不可能代替 Kubernetes 在分布式云环境中编排容器和微服务。
