WASM和Kubernetes云原生应用部署的新纪元

Wasm and Kubernetes: A New Era of Cloud-Native Application Deployment | by Seifeddine Rajhi | Medium

需知

如今，WASM和Kubernetes是俩个最有变隔离的技术在云计算领域。wasm是轻量级的，它使用轻量级的字节码去部署，能使开发人员在网络上去运行任何语言编写的代码。Kubernetes是一个容器编排平台，它总动画部署和管理容器化应用程序所设计的许多任务。

如今，WASM和k8s有潜在的改变云原生应用部署。WASM可以创建，轻便，可伸缩，安全的应用，它可以跑在任何一个平台上，包括Kubernetes集群。K8可用于大规模管理和部署Wasm应用程序。使构建维护复杂的云原生应用变得容易。

这篇文章，我们将考察WASM和K8s和的连接，同时讨论他们潜力以开创云原生应用开发的新时代。我们将同时讨论一些挑战和机会，为这一新技术栈做好准备。

WASM基础

wasm是一个革命性的新技术，它改变了web应用程序的开放方式。它是一个低级二进制格式它可以编译各种语言c，c++，rust。他通过开发者创建web应用，它比起js单独编写的，非常的快也更有效率。

wasm 有三个主要的优点，速度安全和支持

速度：wasm程序以接近原生的速度，这意味着他可以和桌面程序一样快。
安全：wasm程序是内存安全的沙盒，这使得它比js更安全。
支持：wasm支持全部主要的浏览器，因此开发人员可以确信他们的应用程序将适用于所有的用户。

wasm已经被用来创建各种各样的web程序。包括游戏，视频编辑软件，甚至机器学习上。随着技术的不断成熟，它可能会对web开发环境产生更大的影响。

docker 对比wasm

docker将程序和它的依赖打包在一个镜像中，并在容器中运行他们。docker容器的运行时，完整的文件系统运行（实用程序，二进制文件等），似乎是应用程序的完整操作系统。此外需要根据正确的系统架构创建镜像，例如intel ，amd，arm等。如果某人有树莓派系统运行docker镜像，然后您需要为基于Linux映像的C/C++应用程序创建映像，并为ARM进程系统架构进行编译。如果没有完成，那么容器将不会按预期运行。

另一面，wasm模块是预编译的c/c++应用可以在wasm运行时中快速运行。它不依赖主机系统或者系统架构它不包含预编译的文件系统，类似于docker的低级操作系统原语。每一个目录、系统资源都在运行时通过WASI连接到WASM模块。

Docker vs WASM 平台

wasm提供了接近原生的速度和性能，快速启动时间，还有高度的安全，通过c/c++/rust 代码去运行在浏览器中甚至可以在浏览器外运行。另一方面，Docker提供了运行时隔离和更好的可移植性。

关键在于wasm不依赖主机系统和处理器架构就像docker容器应用。相反，由运行时通过WASI标准提供给Wasm模块。这意味着wasm模块不需要绑定系统或者底层的计算机。这是一种用于高度可移植的基于web的应用程序开发的理想机制。

wasm在Kubernetes上

Kubernetes需要两件事才能运行WebAssembly工作负载：

工作节点的启动使用wasm运行时进行的
RuntimeClass 对象映射到具有wasm运行时的节点

容器和runwasi

大部分Kubernetes集群使用容器高级运行时。它运行在每个节点上管理容器生命周期事件，比如创建，运行，结束，删除。然而，容器只是管理了这些事件。它实际上使用一个名为runc的低级容器运行时来执行实际工作。填充进程位于容器和低级运行时之间，执行重要的任务比如抽象低级运行时。

它的架构如下

runwasi 是一个容器项目，它让你转换容器运行时和wasm运行时。它操作了适配层在容器和顶级wasm运行时之间。启动了wasm工作负载在使可以无风运行在Kubernetes集群中。它的架构如图

从容器以及一下的所有内容对于Kubernetes来说都是不透明的，Kubernetes将工作任务调度到节点，不关心传统的OCI容器或者wasm工作负载。

使用Wasm运行时引导Kubernetes工作节点

为了Kubernetes工作节点能执行wasm工作负载，需要使用wasm运行时进行引导。有俩步需要处理。

安装wasm运行时
在容器中注册wasm运行时

在大多数情况下，你的k8s发行版将会提供CLI和UI它们自动化了这些。然而我们将解释幕后发生的事情。

wasm运行时是二进制的可执行程序，它必须安装到容器可见的路径中。它必须根据容器二进制运行时约定进行命名。以下列表显示了适当命名并安装到/bin目录中的wasmtime和spin运行时二进制文件：

– wasmtime: /bin/containerd-shim-wasmtime-v1
– spin: /bin/containerd-shim-spin-v1

一旦安装wasm运行时需要注册在容器中。这是通过将它们添加到容器配置文件来完成的，该文件通常位于/etc/containerd/config.toml。

以下摘录显示了如何在containerdconfig.toml文件中注册wasmtime和spin运行时。

[plugins.cri.containerd.runtimes.wasmtime]
  runtime_type = "io.containerd.wasmtime.v1"
[plugins.cri.containerd.runtimes.spin]
  runtime_type = "io.containerd.spin.v1"

一旦wasm下载和注册，最后一个节点配置步骤是标记节点。

对工作负载使用标签

Kubernetes 的 RuntimeClass 是一个根据容器运行时选择和配置容器的功能。它允许您在同一个 Kubernetes 集群中使用不同的容器运行时,并为每个容器使用最合适的运行时。

如果你的集群节点都有相同的运行时，你不需要标记他们。但是，如果你有节点自己在wasm运行时，你需要标记他们，以便RuntimeClass 对象可以针对他们。

下图展示了6个集群，俩个包含runc，4个包含wasm运行时，还有俩个spin

看看标签是如何使哪些节点具有哪些运行时变得明显的。

确保使用有意义的标签和避免默认的命名空间，我比如kubernetes.io和k8s.io

以下命令使用wasmtime=yes标签调用wrkr3RuntimeClasses可以使用这个标签，去发送wasm工作负载到节点

$ kubectl label nodes wrkr3 wasmtime-enabled=yes

下一个命令的输出显示标签已正确应用。

$ kubectl get nodes --show-labels
NAME     STATUS    ROLES    AGE     VERSION        LABELS
wrkr1    Ready     <none>   5d      v1.25.1
wrkr2    Ready     <none>   5d      v1.25.1
wrkr3    Ready     <none>   2m      v1.25.1        wasmtime-enabled=yes

安装了Wasm运行时，向containerd注册，并应用了标签，节点就可以执行Wasm任务了。

下一步是创建一个RuntimeClass，将Wasm工作负载发送到节点。