Kubernetes(“k8s”)承诺提供一个软件虚拟化基础，可以让您同时解决许多问题：
- 与在裸机上运行服务相比，k8s可以让您更有效地使用硬件。K8s 允许您在一台硬件服务器上运行多个容器，并允许您根据需要向集群中添加更多服务器。
- “容器云”架构有效地划分了构建服务器端应用程序的工作。您的数据库团队可以发布数据库容器，您的后端团队可以发布 Java 容器，您的产品经理使用网络作为通用中间层将它们连接在一起。它符合康威定律：软件看起来像组织结构图。
- 容器抽象足够通用，可以支持许多不同类型的服务。Go、Java、C++ 等等——它不是特定于语言的。您的开发团队可以使用他们喜欢的东西。
- 负责运行容器的 k8s 服务器的运维团队不必信任他们运行的容器。内置了一些沙盒和安全性。
K8s 本身是对先前架构OpenStack的演变。OpenStack 让每个容器都是一个完整的虚拟机，具有完整的内核和操作系统以及一切。相反，K8s 通常使用容器，容器中通常不需要内核。结果是它们的重量更轻——想想 Docker 与 VirtualBox。
在 Kubernetes 部署中，内核仍然位于软件架构的中心位置。容器化的基本机制是具有私有命名空间的 Linux 内核进程。然后这些容器通过 TCP 和 UDP 套接字粘合在一起。然而，虽然每个容器有一个或多个内核进程确实比完整的虚拟机扩展得更好，但它通常不会扩展到数百万个容器。并且进程确实有一些启动时间——你不能为每个对高性能 Web 服务的请求启动一个容器。这些技术限制导致了某些类型的系统架构，通常具有保持某种状态的长期组件。
k8s <=? w9y
服务器端 WebAssembly 与 Kubernetes 处于类似的空间——或者更确切地说，WebAssembly 类似于进程和私有命名空间。
WebAssembly 为您提供了良好的抽象屏障和（可以提供）高度安全隔离。在某些方面它甚至更好，因为 WebAssembly 提供了“允许列表”安全性——它没有一开始的功能，要求运行 WebAssembly 的“主机”将自己的一些功能显式委托给来宾 WebAssembly 模块。与默认情况下从每个功能开始然后必须受到限制的进程进行比较。
与 Kubernetes 一样，WebAssembly 也为您提供 Conway’s-law-affine系统。您无需运送容器，而是运送 WebAssembly 模块——以及一些关于他们需要从环境中获得哪些类型的东西的元数据（“导入”）。WebAssembly 是通用的——它是一个低级的虚拟机，任何东西都可以编译其中运行。
但是，在 WebAssembly 中你会得到更多的东西。
- 一是快速启动。因为内存就是数据，所以您可以安排创建一个WebAssembly 模块，该模块的状态从内存中预初始化的状态开始。这样的模块可以在几微秒内启动——速度足够快，可以在每个请求上创建一个，在某些情况下，只是在之后丢弃状态。您可以在 WebAssembly 上运行比在容器上更有效地函数即服务FaaS架构。
- 另一个是虚拟化完全在用户空间中提供。一个进程可以在许多不同的 WebAssembly 模块之间多路复用。这让一台服务器可以做更多事情。而且，你不需要使用网络来连接WebAssembly 组件；他们可以在内存中传输数据，有时甚至无需复制。
我将 WebAssembly 与 K8s 进行比较，但实际上它更像是进程和私有命名空间。
所以对最初提出的问题的一个答案是：不，WebAssembly 不是下一个 Kubernetes；
WebAssembly 将处于新事物的底部，因此 WebAssembly 的近期轨迹很可能会跟随 Kubernetes 的轨迹，这意味着…
- 分析师开始了评论时间！
- Gartner 魔力预测再次开始
- IBM 推出了一个新的 WebAssembly 部门
- 埃森哲开始向公司询问他们的 WebAssembly 迁移计划
- Linux 基金会尝鲜
Kubernetes 本质上不是一个技术软件，而是一个泡沫商业竞争的纽带，当然：我们还有 5 年左右的时间。
2021 年 12 月的 WebAssembly 让我想起了 2014 年容器/kubernetes 的情况——业界已经意识到当前的技术状态并不能解决当今所有的问题。跨边缘/服务器/浏览器的可移植性、可移植的安全模型以及业务逻辑和库之间的紧密耦合意味着企业构建/管理/操作应用程序的多个版本。像 wasmCloud 这样的技术是未来，在我看来，未来几年将是一个更好的故事。