VMware 陈铁军：VMware的WebAssembly探索初体验

嘉宾 | 陈铁军   整理 | 夏歌

出品 | CSDN云原生

或许你听说过WebAssembly是W3C认可的第四种编程语言，C++、C、Rust 等所编写的高性能库可以被编译成Wasm（WebAssembly的缩写），FFMPEG可以用来提升浏览器应用性能……但其实如同Java与JavaScript一样，WebAssembly也在经历着由客户端向服务端的迁移，服务端的 WebAssembly正在冉冉升起。WebAssembly用在服务端有什么优势？与现有云原生的生态是什么样的关系？又有哪些应用场景？

2022年4月28日，在CSDN云原生系列在线峰会第3期“WebAssembly 峰会”上，VMware CTO办公室高新技术部资深Tech Lead陈铁军，分享了VMware对WebAssembly的探索与认识。

戳👇观看陈铁军分享视频

WebAssembly入门知识

WebAssembly是一种用于基于堆栈的虚拟机的二进制指令格式。它能够满足Web的新需求，即让各种语言编写的程序运行在浏览器内，并且具有高性能，当前的主流浏览器也均支持WebAssembly。

在WebAssembly发展的过程中，因具有Small size、安全、高性能等特征而受到越来越多人的关注，它被认为能够在更广阔的领域发挥作用。

Docker的创始人曾说，如果在2008年就有WebAssembly，那也就没有必要创建Docker了。注意，这并不是说WebAssembly可以取代Docker，而是在阐述WebAssembly的重要性。通过这种对比，我们可以更直观地明白WebAssembly在技术层面的位置及其潜在应用是可以和Docker相媲美的。

“WebAssembly on the server is the future of computing.”

为什么这么说呢，这里就要提到另一个重要的概念—— WASI。WASI的引入为WebAssembly打开了一扇窗，帮助WebAssembly运行在浏览器之外。

WASI全称是WebAssembly System Interface，主要是定义和Host交互的接口，访问Host上的资源、文件系统或网络。在浏览器之外，要借助 WebAssembly Runtime运行Wasm文件，WebAssembly Runtime会做一些解码、load、实例化的工作。

回到Docker创始人那句话，WebAssembly能否和Docker做一些兼容，比如编排工具的共享——编排也是Wasm本身需要的能力。在这一点上可以想到Kubernetes，比如Containerd的延伸、Runc对Wasm的支持，以及Krustlet。最后则是Wasm对AI的支持，WasmEdge通过对TensorFlow Lite的扩展延伸，支持了AI推理。其次就是WASI-nn规范，也能够让Wasm支持机器学习。

总之，WebAssembly因为其轻量级、高性能、安全等特性被认为在浏览器之外有很大的潜力。同时WASI的出现帮助WASM摆脱了浏览器的限制，社区也出现了很多WebAssembly Runtime，以帮助Wasm应用在浏览器之外的云原生和 AI 应用上。

WebAssembly是面向未来的计算

总体来说，VMware目前主要在四个方向拥抱WebAssembly：

• 把WebAssembly构建到轻量级、高性能的平台

• 和容器与VM肩并肩运行WebAssembly

• 构建基于WebAssembly的以应用为中心的平台

• 在任何地方运行WebAssembly ——Hypervisor

WebAssembly虽然是Small size的、安全的，能够控制访问资源的权限，但运行WebAssembly仍然需要上下文的OS整合。从这一点出发，我们考虑构建一个轻量级的、安全的平台去运行WebAssembly。

首先，我们需要构建Vessel来承载WebAssembly的运行，有以下几个Profile 可以供选择：

• GP Linux：VMware推出的Linux OS

• LinuxKit：Docker的Toolkit，可以构建容器化平台，提供了Minimalkernel和其他必要的组件

• Preempt：一个实时的Linux

• Unikernel：通过使用专门的库操作系统来构建的单地址空间机器镜像

通过上图我们可以了解虚拟化的进程：

• 首先有VM，在VM里运行Guest OS，Guest OS可能是Linux，也可能是Windows

• 然后出现了容器，容器运行在Guest OS里

• Container也可以直接跑到VM里

可以看出，通用的OS对容器或应用来说较重，会影响性能和安全性，所以会有类似CentOS的Tone down的技术进行辅助。而Unikernel在这条路上走得更远一些，只保留Application运行所需要的组件，这相当于将OS 转变成一个内部控制的应用。好处也是显而易见的，镜像比较小，加载、启动都很快，而且攻击面会很小。同时因为类OS都是特定优化的，性能也会更好，尤其是在IO方面。

但也有兼容性的问题。因为Unikernel是类OS，所以通常情况下，开发是要重构的，甚至需要重写调用接口使用Unikernel。虽然现在有能够解决兼容性的方案，但会导致性能丧失。而WebAssembly可以把多种语言编写的程序形成一个统一的Binary发布。因此，把Unikernel和WebAssembly进行结合，可以形成一个双赢的局面。

这里，分享两个平台的试验。

NanoVM

NanoVM是一个企业级的Unikernel。从上图右侧可以看出，与Linux 相比，NanoVM 在代码数量、运行 library的数量、执行文件的数量上，都少得多。

NanoVM通过集成WebAssembly Runtime来支持Wasm应用在Unikernel里运行，如 WasmEdge和Wasmer。 

Unikraft

Unikraft的主要特点是高度定制。从上图右侧可看出，Unikraft能够让应用很容易地指定所需的第三方库或标准库，或是其他代码，最终构建出一个最合适的类OS。Unikraft与NanoVM一样，也是通过集成WebAssembly Runtime来支持Wasm应用在 Unikernel里运行。

vSphere与Tanzu

VMware的vSphere with Tanzu是企业级K8s。通过vSphere with Tanzu ，可以把传统意义上的vSphere Cluster转变成在Hypervisor上运行K8s Workload的平台。

一旦vSphere with Tanzu在VSphere Cluster启用，就会把K8s Control Plane放到Hypervisor中去，这样vSphere with Tanzu就可以在ESXi host直接运行K8s Workload，也可以去创建 Upstream K8s Cluster 给 Dedicated 资源池。其中，配置vSphere with Tanzu的Cluster叫作 Supervisor Cluster。

在我们的软件定义数据中心里，软件定义包括了计算的ESXi、NSX、通用的vSphere Networking，Storage上用的是vSAN。这样我们就可以在vSphere Pod去运行K8s Container 或Tanzu Upstream Cluster。

如上图所示，深蓝色的Hostd是在vSphere里存在的，对ESXi上的Machine进行管理。K8s Control Plane VM是 Supervisor Cluster的一部分，用来构建Host。

Spherelet是把Kubelet移植到ESXi Host，目的是让ESXi host 成为K8s Cluster的一部分。在这上面构建运行vSphere Pod等同于Native K8s Pod，但它是一个Small VM，可以运行一个或多个应用实例，其依赖的核心是CRX（Container Runtime Executive）。CRX从管理角度看待VM，同时包含了一个能够和底层Hypervisor ESXi 搭配工作的Linux Kernel。通过优化技术，当前vSphere Pod拥有与Native K8s Pod同样的性能和速度。

从定义上说，Tanzu K8s Cluster是由VMware打包、签名和支持的开源Kubernetes软件的完整发行版。

我们可以通过VMware Tanzu K8s Grid Service在Supervisor Cluster去做一个Provision和Operator。从上图可以看到，Cluster API、VMware Tanzu K8s Grid Service是运行在 Supervisor Cluster 上，对Tanzu K8s Cluster进行了一个Provision 和Measurement的enable。

VM Operator是帮助部署和运行Standalone的VM或者构成Tanzu K8s Cluster的 VM。从这一点上来看，vSphere with Tanzu提供了一种类似VM Service的方式，也可以去部署VM，但需要注意的是，Container和VM会共享同一个Namespace，也是对Single vSphere Tanzu Interface进行管理。之后就可以用标准的K8s Cluster的工具或方法，在Tanzu K8s Cluster部署Workload或Service。

那怎么去部署Workload呢？

可以通过部署vSphere Pod，在里面运行K8s Container；也可以通过TKG Service创建一个Upstream K8s Cluster，在这些Cluster中运行应用。具体如何选择，取决于你的目标。如果你需要非常强的隔离、安全性或是需要资源隔离，或是如果你不需要一个定制的K8s Cluster想去运行一个 Container，或是想直接运行ESXi Host 之上，均可以使用vSphere Pod。

从上面的介绍可以看出，vSphere with Tanzu已经实现了Container和VM并肩运行，也实现了以应用为中心。

那么接下来的问题就是如何把WebAssembly集成到这个平台来。

这里可以使用TKG Image Builder来实现。TKG具备BYO Image（Bring your own custom image）的能力，可以用来创建Tanzu Workload Cluster。简单来说就是Image里有Kubelet，这个Kubelet可以帮助WebAssembly。

简单总结虚拟化平台的演变过程：起初只支持虚拟化的虚机，随着Tanzu的出现，实现了Container和VM并列运行，之后实现了WebAssembly的集成。

集成WebAssembly的方法有很多：

• 通过TKG Image Builder

• 将WebAssembly放到vSphere Pod里

• 在Unikernel OS里集成WebAssembly

Demo时间

Demo A：使用 Tanzu K8s Grid 来 {Build, Run}  WebAssembly 机器镜像

首先通过Image Builder生成一个Machine Image。Image Builder生成的Package 里面包含基本的OS信息、K8s的信息、Runtime的信息。在这里，我们需要Krustlet的信息。最后就是使用这些信息，创建一个Cluster。

Demo B: WebAssembly inside Unicraft on vSphere

Demo C: 在vSphere Pod集成 WebAssembly，实现机器学习

前面提到了拥抱WebAssembly的第四大方向：在任何地方运行WebAssembly，即 Hypervisor里。首先想做一个说明，ESXi 里的VM Kernel不是 Linux，所以已有的 WebAssembly Runtime都需要做些移植才能在上面运行。

至于为什么要在Hypervisor上运行WebAssembly，原因总结为以下几点：

• 可以把WebAssembly支持多语言编写应用的能力带到Hypervisor里

• 可以借助 WebAssembly ，把机器学习这样的高级功能带到Hypervisor里

• 同一个Wasm文件可以在X86和ARM64上运行，借助WebAssembly的可移植性，EXSi可以运行在不同平台和不同架构上，对于边缘端场景十分有用

此处，通过以下两种方式演示如何在vSphere Pod集成WebAssembly

• 使用TVM实现机器学习

• 使用WasmEdge中的独立文件实现简单的Hello World

戳👇查看完整版Demo演示（24分2秒起）

---

聚焦云原生新技术、新实践，帮助开发者群体赢在开发范式转移的新时代。欢迎关注CSDN云原生微信公众号～  

扫这里↓↓↓加入CSDN云原生交流群