嘉宾 | 晋晨 整理 | 张润泽
出品 | CSDN云原生
2022年4月28日，在CSDN云原生系列在线峰会第3期“WebAssembly峰会”上，OpenYurt Member晋晨结合自己的使用经验，分享了如何使用OpenYurt管理WebAssembly。
戳观看晋晨分享视频
云原生探索新边界，OpenYurt 实现“云边端一体化”！
OpenYurt 诞生背景
OpenYurt 社区的口号是“Extending your Native Kubernetes to Edge”。但从更高维度来看，“Kubernetes”和 “Edge”其实就是云原生和边缘计算。那么云原生的定义是什么？
根据CNCF官网上的定义，云原生是有利于各组织在公有云、私有云和混合云等新型动态环境中构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术，工程师能够轻松地对系统做出频繁和可预测性的重大变更。
而边缘计算，是一种分布式计算架构，将应用、数据与服务的运算，由网络中心节点，移往网络逻辑上的边缘节点来处理。
至于Kubernetes在整个云原生系统中的定位，正如Linux、Windows在单机上的架构一样，Kubernetes其实是云原生体系下的一种操作系统。根据CNCF Cloud NativeSurvey在2020年的调查显示，有55%的受访者已经在生产中使用容器来运行他们的应用程序。
上面这张图展示的是Kubernetes的架构。Kubernetes向下是对资源的调度和编排，从而屏蔽了底层的基础设施和差异。同时，向上可以实现工作负载的自动化。
云原生和边缘计算融合有哪些困难？可以简单总结为四个方面：
-
边缘计算规模和业务复杂。原生的Kubernetes很难适应边缘计算的场景。
-
云边网络连接不可靠。边缘节点和云中心通过公网进行连接，而由于公网的不稳定性，导致了对于业务的不稳定性
-
云边端运维协同难度较大。kubectl logs和kubectl exec无法在边缘场景下正常使用。
-
异构资源支持困难。系统可能是 Linux、Windows，架构也可能是 AMD64、ARM、ARM64 等等，从而给边缘标准化支持带来巨大挑战。
总的来说，OpenYurt 诞生在云原生探索新边界的时代，提出了“云边端一体化”的概念，主要分为三个层次：
-
云上。云端提供标准化的接口、管控能力，或者是标准的云服务和云资源的接入能力，在其中也能够看到 Kubernetes 的身影。
-
边缘侧。能够高效地管理处在整个边缘端的众多资源，其中包括在边缘端应用的效率问题，比如CDN、ENS。
-
端设备。典型的场景是IoT产品，例如智慧楼宇智能停车设备、蓝牙设备、人脸识别设备等。
那么，OpenYurt是如何解决云原生和边缘计算融合困难问题的呢？
先了解一下OpenYurt 的云边架构。从上图可以看到，云上由各个组件组成，有 YurtHub、YurtControllerManger、YurtAppManager、YurtEdgeXManger、YurtTunnel Sever。云下的Edge端由YurtHub、YurtTunnel Agent等组件组成。针对上面四个难点，OpenYurt提出了不同的解决方案。
首先是单元化管理，实现了资源、应用、服务在本单元内闭环。
-
在资源角度上，它根据地域将边缘站点资源进行划分，提出了节点池的概念。比如在杭州有一些边缘节点，可以将其一起纳管到同一个边缘节点池。同时，北京也有一些边缘节点，同样可以在北京建立一个节点池。
-
在应用层面上，它设计了一整套应用部署模型，比如单元化部署、单元化DaemonSet、边缘Ingress等。
-
在流量服务上，可以实现流量在本节点池内闭环访问。
其次是边缘节点、节点池的自愈。关于节点自愈，首先来看下YurtHub组件。它是边缘节点自愈能力的基础，其功能主要是缓存云端的数据，并提供给边缘节点。每当网络断开时，YurtHub就会发挥作用。通过边缘节点、节点池的自愈，OpenYurt可以轻松解决节点离线和节点重启对业务的影响，保证边缘业务持续、可靠地运行。当边缘网络恢复后，边缘业务的状态将与云端控制同步，并保持数据的一致性。
第三点是云边协同能力。它实现了在云端统一管理海量边缘资源及业务，主要提供能力的组件是YurtTunnel Sever和YurtTunnel Agent。从云上来看，OpenYurt 无缝融合了云上已有的能力，包括智能运维、日志、DevOps等，可以保证边缘资源和业务的少运维、高可用。同时，它借助云边端一体化的通道Yurttunnel Server/Agent，将大量云上的能力，包括中间件、安全、AI、存储及网络管理等能力下沉到边缘，减少常见云服务在边缘侧的自建成本，同时支持原生的Kubernetes运维能力。简单地说，其实就是kubectl logs以及kubectl exec。
第四点是无缝转化能力。可以简单理解为，Kubernetes和OpenYurt集群一键转换。目前，社区主要提供了三种方法：
-
YurtCluster Operator。它提供了一个声明式API，用户可以快速地通过设置配置文件，达到从Kubernetes到OpenYurt的集群转换。
-
Yurtctl init/join。init的功能是从零开始搭建一个Operator的集群。join是把边缘节点加入到OpenYurt集群中来。
-
Yurtctl convert/revert。它的功能与YurtClusterOperator类似，convert是把Kubernetes集群转化为OpenYurt的集群。而revert则恰好相反。下图所展示的即为convert的过程。
WebAssembly和WasmEdge
前面讲述了OpenYurt的基本情况，下面讲一讲WebAssembly以及WasmEdge。
众所周知，在云原生领域中，Kubernetes是容器编排和调度系统的事实标准。而作为容器技术风潮的引领者——Docker，一直是云原生领域的热门方向之一。下图中展示了Kubernetes如何一步步调用runC的过程。
目前，对于WebAssembly能否取代Docker一直争论不休。比如有争论，“云原生的下一步或从WebAssembly在边缘取代Docker开始”。根据WebAssembly官网的定义，WebAssembly简称WASM，是基于对量式虚拟级的一个二进制指令集，它被设计为编程语言的一个可执行编译目标，从而可以部署于客户端和服务端的Web应用程序。目前主流的浏览器都内嵌了WebAssembly的1.0版本。2019年3月，Docker联合创始人Solomon Hykes发了一条很有争议性的推特，主要内容是如果2008年WASM和 WASI已经存在了的话，他们就没有必要创立 Docker了。
之后他对此又进行了回复，主要内容是说 WASM真的会取代 Docker吗？当然是不可以，他畅想的愿景是在Linux容器、 Windows容器、Wasm容器以密切合作的形式运行在Docker中。但从目前的情况来看，把 Docker换成Kubernetes可能更合适一些。
那么他所说的 WASM 和 WASI是什么？WASM是一个二进制的文件。WASI全称是WebAssambly System Interface，其实就是一个系统接口，它实现了可移植性和安全性。可移植性指的是，在不同的系统中，同样的WASM二进制文件，能够支持将它转化为不同的系统调用。安全性指的是，在系统调用过程中对用户访问权限的控制，不能直接让第三方包直接访问系统资源。WASI作为一层软操作系统接口层，在系统调用前，实现了被WASM二进制文件所调用。
到2021年底，云原生基金会CNCF已经接受了至少三个WebAssembly sandbox 项目，包括WasmCloud、WasmEdge以及Krustlet。其共同的目标是统一跨云中心、边缘计算、物联网和移动设备的广泛分布式应用程序的管理。
下面结合Second State（WasmEdge所在的公司）给出的基准测试，对比展示一下，与Docker相比而言，WebAssembly所具有的优势。
第一个是在启动上，WebAssembly比Docker要快100倍。第二个是在执行时间上，WebAssembly比Docker要快10%~50%。第三个是在占用的空间上，WebAssembly相对于Docker来说更少。Docker镜像一般少则几十M，多则几个G。而WebAssembly可以做到它的1%。当然，具体大小跟业务联系紧密。
在没有用户互动的产品中，如果使用Docker是什么样的情况呢？这时候的Docker只是作为一个执行的环境，把已经写好的程序在Docker中执行，执行完后，再把Docker关掉。这时候我们可能会思考：如果程序直接去运行，那也是可以的。其实，WebAssembly就是提供了这样的一种可能性，把WebAssembly应用到边缘场景，能够在边缘计算场景下跨平台、轻量、快速地用云原生理念和云原生工具去部署应用程序，具有很大的优势。
上图是基于WasmEdge构建的WebAssembly的生态圈。可以看到纵向的最底层是软件层，向上是OS操作系统层，再就是WasmEdge，然后基于WasmEdge又会有一些其他的技术产生。
OpenYurt如何管理WebAssembly
下面以WasmEdge为例，介绍OpenYurt如何管理WebAssembly。
首先，为什么OpenYurt可以很好地将WasmEdge作为一个边缘节点的运行时？
-
第一点是OpenYurt对Kubernetes的无侵入设计。可以理解为Kubernetes能做的事情，在OpenYurt都是可以做的。
-
第二点是WasmEdge是符合OCI runtime设计标准。不管是对crun还是runc等等，都是非常友好的。
下面通过视频展示如何使用OpenYurt来管理WasmEdge。
点击视频观看实践演示
使用OpenYurt管理WebAssembly演示demo
相信通过视频的演示，基本已经了解了如何使用OpenYurt来管理WasmEdge。更多关于OpenYurt和WasmEdge的情况，可以去github详细了解。
聚焦云原生新技术、新实践，帮助开发者群体赢在开发范式转移的新时代。欢迎关注CSDN云原生微信公众号～
扫这里↓↓↓加入CSDN云原生交流群
