作为一种小型、快速、安全、跨平台的字节码，WebAssembly是云原生模式的理想选择。Docker创始人Solomon Hykes说，WASM和WASI（安全访问系统API的WebAssembly系统接口）将不再需要容器技术。
但是，由于WASM提供的是二进制环境而不是整个环境，除非将整个环境移动到WebAssembly模块中，否则它不能替代容器。换句话说，不要说“WASM是容器的终结”，正确的说法是“WASM+容器”。
Kubernetes帮助WebAssembly
如果你认为云原生流程是在需要时从API创建的，需要更大的容量时可以进行扩展，不需要时可以删除它们，WASM是运行这些流程的一种极好的方式。但你仍然需要一个运行它们的环境。Cosmonic首席执行官Liam Randall将WebAssembly比作一个虚拟的、可能是通用的CPU，因为它作为一个通用编译目标，但他指出“其中没有虚拟操作系统。”
除非它们嵌入到另一个工作负载（如Envoy过滤器）中，或者在Cloudflare Workers等环境中用作无服务器功能，否则你需要一个编排器来编排它们。“对于服务器端WASM来说，调度和编排仍然是一个开放的领域。”风险投资公司Amplify Partners的负责人Renee Shah指出。
目前还没有特定于WASM的调度和编排系统，从零开始开发这些系统而不是与现有选择集成可能没有意义。Kubernetes不是编排云流程的唯一选择，但它如此广为人知和广泛采用，考虑将其与WebAssembly一起使用是合乎逻辑的。
使用KrutStLe（它现在是CNCF的沙盒项目），Kubernetes可以原生编排WebBaseSun运行时。Krustlet是用Rust写的。当Kubernetes API将pod调度到Krustlet上时，Krustlet在WASM运行时运行它们；在同一集群中运行的WebAssembly和容器工作负载可以相互通信，并使用机密、卷挂载和init容器等功能与集群的其余部分交互。
Matt Butcher是Microsoft team building container和WebAssembly技术（如Helm、Draft和Krustlet）的负责人。他表示，Kubernetes是WebAssembly的“宝藏”，因为它不仅带来了调度，还带来了其他关键服务。
Kubernetes“还带来了存储层，这是一个非常大的问题。你希望能够移动工作负载，希望确保它可以连接到正确的存储，这将是一个需要自己编写的庞大项目。Kubernetes在这方面很成熟。秘密管理，网络层。这是使Krustlet获得如此出色启动体验的原因之一，我们只需连接到Kubernetes，而不必自己编写。”
WebAssembly也可以利用其他容器构造；使用WAGI（WebAssembly Gateway Interface）作为构建编译为WASM的HTTP处理程序的变通方法，你可以从OCI注册表中引用和提取模块(Kubewarden和Krustlet还利用OCI工件通过OCI注册中心分发WASM模块）。
Shah指出：“WebAssembly和容器的优点在于，它们都在打破单体的趋势上发挥作用。如果一家公司已经使用了微服务，那么添加由WebAssembly支持的新服务就相对简单了。有了Krustlet，它们可以在Kubernetes中并排运行。
更好、更快、更小：WASM帮助Kubernetes
WASM在很多Kubernetes不相干的领域都是有用的。但也有一些WASM将显著改进的Kubernetes场景，WebAssembly可能成为Kubernetes的常见工作负载，不需要替换容器。
Kubernetes中的WASM将特别适用于需要高密度、快速可用性和可扩展性的场景，或者需要在有限资源下运行的场景。要正确保护Kubernetes和容器的默认运行时配置，还需要做大量工作。容器不是安全边界。WebAssembly在防止代码转义方面做得更多。WASM沙盒的安全性和WASM模块要求对任何功能具有明确权限的“默认拒绝”方式在这里具有明显的优势。
WebAssembly运行时的启动时间在10毫秒范围内，而容器的启动时间为几秒钟（虚拟机的启动时间为几分钟），这使得它非常适合无服务器环境，也适合扩展。
人们非常重视使容器尺寸更小，但对于内存和存储受限或处理能力最低的边缘环境来说，容器尺寸往往太大。运行2MB WebAssembly模块而不是25MB Docker容器意味着Kubernetes可以在更多环境中管理工作负载。
Butcher指出，这可以显著提高工作负载密度。
边缘（更为异构的计算环境）可能是WASM和Kubernetes结合的最大机会，这可能意味着“云”将超越超规模数据中心。
“Krustlet为我们解决了Kubernetes和容器无法解决的问题，那就是我们需要能够将Kubernetes集群扩展到数据中心之外，并扩展到越来越新奇的设备上。”
支持Arm硅是其中的一个重要部分，物联网设备中使用的微控制器、许多硬件AI加速选项以及Intel正在生产的异构CPU也是如此。“这是一个跨平台、跨架构、跨操作系统的故事。”
Cosmonic的Randall赞同这一观点。“CPU的多样性使得容器给生态系统带来的限制更加明显在CI/CD世界中。如果你必须针对几十个或数百个不同的CPU，你需要几十个或数百个特定的CPU镜像。”此外，他指出，“许多小型设备永远不会运行Linux。”
WASM+Kubernetes的可能性
Butcher希望WASM可以让开发者体验Kubernetes，就像Docker和containers一样简单：“我想要一个很好的快速工作流程，在这里我可以编写一个应用程序，在后台的某个地方，它可以部署到运行Krustlet的Kubernetes集群。”
构建容器可能很容易，但部署、测试和与同事共享测试环境令人担忧，WebAssembly有望改进这些。
Cosmonic的wasmCloud现在是一个CNCF沙盒项目，旨在提高开发人员体验，在某些场景中也依赖Krustlet（尽管它有自己的运行时，而不是Wasmtime运行时）。
Randall说：“Kubernetes和WebAssembly的结合使你能够将wasmCloud放入多个云中的一组Kubernetes服务器中，并让它们相互通信。”
微服务中还有一些基本的模式，WebAssembly中的未来功能可能会加以改进。
Butcher指出：“典型的微服务包括每个开发人员建立自己的HTTP服务器，并将JSON写入对象序列化。”在每一个需要编写、测试、保护和更新的微服务中，总共有大约1000行样板代码。WebAssembly nanoprocess模型将HTTP层和序列化/反序列化放在WASM运行时中。
“当两个模块碰巧在同一个运行时相邻时，它们只是直接通信。但是，当它们分布在网络上时，主机运行时会处理两者之间的通信，开发人员不必维护它们。安全模式非常好，因为你不必每次OpenSSL出现错误时都更新每一段代码。”
另一个异构、资源受限的领域是机器学习，Kubernetes在这一领域越来越重要，特别是在Kubeflow等工具的帮助下，WebAssembly可以带来显著的收益。
WASI不仅仅提供存储和网络等低级操作系统接口，它还可以为神经网络之类的东西提供高级接口。经过训练的机器学习模型必须在各种具有特定平台运行时的设备上运行，并使用不同的专业硬件加速器。由于WASM与平台无关，它将简化部署，WASI nn接口将允许WebAssembly与多个机器学习运行时进行对话，如ONNX、OpenVINO、PyTorch和TensorFlow。
Butcher建议：“机器学习是WebAssembly可能足够安全的另一个领域，但它在堆栈上的位置足够低，因此它比容器更容易与硬件集成。”
“我们将WebAssembly视为一些难以使用容器的小部件的粘合层，我们可以更轻松地使用WebAssembly，然后将容器生态系统与硬件管理或部署机器学习算法等更难的部分结合起来。”
这就是你开始真正了解容器和WebAssembly如何相辅相成的地方。
原文链接：
https://thenewstack.io/how-webassembly-could-streamline-cloud-native-computing/
