分享

WebAssembly 真能取代 Kubernetes吗



1.jpeg

我认为,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 被攻击的可能性更高。



1.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 超越,开发人员和维护者需要迅速采取行动。”


2.潜在的威胁
Wasm 威胁到了 Docker 以及容器的生存。Wasm 在简单性、可移植性和安全性方面的优势使其成为弥补 Docker 缺点的备选之一,尤其是对于边缘和分布式应用程序而言。但是,Docker 擅长为两种不同类型的应用程序提供环境:

  • 长时间运行的进程,如数据库和消息队列,它们对 I/O 和内存管理都有着强烈的需求。
  • 应用程序内部残留的许多旧代码不仅保存了状态,而且还大量使用线程。


Butcher表示:“我认为,Docker 在市场上拥有强大而稳固的地位,不太可能被 Wasm 取代。但是,对于微服务和 Web 应用程序的后端,我认为 WebAssembly 完全可以取代 Docker。”

因此,在某些情况下,Wasm 确实可以取代 Docker 和容器,但 Wasm 不可能代替 Kubernetes 在分布式云环境中编排容器和微服务。

————————————————


最新经典文章,欢迎关注公众号



原文链接:https://blog.csdn.net/csdnnews/article/details/128526963


已有(1)人评论

跳转到指定楼层
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

推荐上一条 /2 下一条