嗨,大家好,我叫江峰菲我来自华为2012实验室今天我给大家带来演讲的题目是Coopers Age Powered Age DevicesWaste-Nest Generation Coordinated Frontend简单描述一下就是Coopers Age和下一代云原生已经是共同驱动无处不在的边缘设备将K8s的能力赋予到更多形态的设备上例如智能摄像头AIOP智能中端设备工业控制智能设备的下面是有关我自己的一个个人介绍我现在在华为2012实验室的OLA OS团队我们团队主要专注于服务器操作系统领域为华为内部的ICT场景提供可靠、可信的OS底座在2019年我们对外开源了我们的服务器操作系统Opongla当前Opongla已经拥有47000家开发者就三个四个兴趣小组是国内作为活跃的开源项目之一也欢迎大家有空可以去我们的社区上看一看然后我个人也是最早一批参与Cara Continence安全容器项目的贡献者我当前在团队内主要负责余渊生容器全帐方案在华为内部ICT场景的探索和落地今天我的演讲主要从下面四个方面展开第一个就是介绍一下有关项目的背景和动机第二就是介绍一下外办三百里相关的一些内容第三就是介绍一下我们项目的一些架构设计功能最后就是有关我们未来一些工作的一些展望首先我们来看一下我们做这个项目的一个背景前期我们深入动查了在边缘场景下面应用的开发构建分发部署升级整个端道端的流程的现状总结出了下面几个核心的一些痛点问题第一个就是当前边缘设备的硬件架构越来越多样化有X86架构的CDN火起ARM架构的智能摄像头设备REST5和ARM架构的微控制器设备的面对越来越多样化的硬件架构开发者如何才能做到开发构建议室实现到处部署到处运行的越来越接近现场的边缘设备例如工业互联网 自动架式场景对实际性的要求非常高传统容器的冷气动速度通常都在百毫秒级别无法满足该场景下面的一些诉求第三用户对于影子问题的担忧推动了数据分析能力不断下层到中端设备上迎合数据实施处理的趋势从而进一步强化数据的影子性减少网络带宽缩转实验第四点通常边缘设备中端的资源非常有限有非常多的设备的可用资源都小于100Mbps而启动一个刀口容器已经可能就需要上100Mbps以上的内存第五点边缘当前运行的应用类型主要是AIT里渲染转码这一类的应用这些应用的容器进行通常封装了整个推理框架硬件设备等SDK库体积庞大基本上进行的大小都大于1GB不仅占用了为数不多的设备支援还导致了分发效率非常低下第六我们希望可以用K8s的源源分身的方式在现场边缘充端设备上也可以去管理和部署我们的应用第七像边缘CDN场景通常面上是不同的租户在大流量请求的场景下面可能需要更轻量开销更小的隔离环境来执行用户自定义的一些数据处理行为根据上面边缘支算场景总结出来的挑战和痛点问题我们归纳出了我们在边缘场景我们运源生的一些运行时的设计目标第一要具有轻量级的沙山隔离能力每个沙山的内存开销要在KB级别能启动时间要在毫秒级别并且支持跨架构运行真正做到编译一次到处运行第二就是要完全建议K8s的API支持通过K8s原则的方式去部署和运行我们的运源生的运行时应用第三支持在单接点上面同时部署运行万级用户杀箱实力满足CDN场景开放边缘计算服务的需求第四支持传统农场形态和新型杀箱形态的在同一个节点上的火盒部署适应不同业务内应用类型的需求在边缘场景我们前期已经做了一些工作和项目下面我们就首先介绍一下我们的Cobra Edge项目Cobra Edge项目是华为开源的业界首个运源生边缘计算平台项目项目于2019年贡献给CNCF基金会当前处于风化阶段我们Cobra Edge项目的核心理念主要有以下五点首先第一点是Cobra Edge首先基于原生的K8s的构建百分百金龙K8s的API第二云边协同支持双向多录服用的消息通道支持边缘接点位于私有网络支持落网场景下面的消息可靠传输第三边缘制置节点原数据持久化实现节点的离线制止节点互装无需ListWatch降低网络压力快速Ready第四极致清晓化我们重新组织了Cooplate的功能模块实现了极致的清晓化组建的内润开销紧需要70早途第五边缘设备的管理支持DefenseMapper设置用户可以制定揭露多种边缘设备协议下面另外一个项目就是我们团队开源的一款适合在端边缘场景下面运行的EsuraD浓气引擎EsuraD作为清晓化的浓气底座可以为多种数据中心边缘等场景提供最灵活最稳定最安全的底层支撑与紫带蚂蚁的小个头大能量不谋而合这也是我们EsuraDLogo的一个含义轻快一灵壳这几个词可以非常简洁的概括我们EsuraD的特点尤其是在边缘场景下面EsuraD非常适合和CooperAge一起运行在支援收线的设备当中我们EsuraD项目主要有以下几个重要的一个特性第一100%GNOSCI OCI XM2标准可以无缝的浓露到K8S为中心的源源生生态当中第二EsuraD浓气引擎采用C更C接加语言编写相比于刀块浓气引擎把浓气的内存开销减少了68%启动时间减少了91%EsuraD面向不同的场景提供普通浓气安全浓气系统浓气等多种浓气形态下面我们接着接来介绍一下我们有关WebAssembly的一些内容我们通过广份的调研分析业界最新的WebAssemblyUnicornal的隔离杀箱技术我们发现WebAssembly杀箱级的安全隔离型跨平台可一致的特性以及接近Lative的运行速度非常适合我们的目标我简单介绍一下WebAssembly的背景WebAssembly是一项W3C的开放标准从它的名字就可以看出它最早诞生于WebLing目的是解决GS语言的性能不足现在WebAssembly凭借安全可一致高效的字节码格式成为各界关注的乐点WebAssembly的核心是虚拟指令级它支持将多种高级的编程语言同一编语成WebAssembly字节码格式并在WebAssembly虚拟集中执行而另一个将WebAssembly的使用场景拓宽到其他服务器令人领域的技术就是WebAssembly全身是WebAssembly InterfaceMassila在2019年3月推出了WebAssembly接口标准用于标准化WebAssembly应用于系统资源的交通抽象比如文件系统访问内存管理 网络连接类似Poskets这样的APIWebAssembly的出现使得Wasm训训集中运行应用程序可以与SuluC上OS的资源进行交互和访问这里有两张引用值WebAssembly container runtimefor serverless age computing的论文从论文中该天论文主要是讲解了WebAssembly技术应用于边缘场景serverless计算服务的应用它里面有这样的一个测试结果从结果中我们可以明显的看出不同WebAssemblyRuntime杀相的冷启动的速度相比于Docker来说有10倍以上的一个降低这是一个非常明显的一个性能的一个提升内存资源也有相当也有将近5-10倍的一个降低优势课件WebAssembly在边缘serverless计算场景下面有着非常优秀的性能那么WebAssembly会取代Docker吗原来原Docker公司的CTO索罗蒙·汉克斯在2019年发过这样一条非常有趣的推特他说如果Walsum加Walsy技术单身于2008年的话那么我们公司就不会再去开发Docker了Walsum加Walsy在服务区领域有了非常光明的前未来这话一说感觉就是一个画饼高手这个推特已经发出之后社区上也引起了大家激烈的一个讨论但是很多人可能只看过他的这前半句话而其实他还有一个后半句那么Walsum那么Walsum会取代Docker吗其实不难可能在未来Docker可以支持运行Links的容器Windows的容器以及Walsum的类型的容器Walsum的容器可能会变成一种非常流行的容器形态这次这位大哥就没有把话说那么满了其实Docker最成功的地方并不在于说是NamespaceJasgo或这套歌里和支援限制的东西而是他定义了容器的进向格式支持通过编写Dockfile编译出 构建出可以到处方法的容器进向从而使容器的可以在到处运行而Walsum当前只是一个齐焱码的二进制文件它闪耀和Docker容器那样流行其实还有很多事情需要去做当然我们看到社区上现在已经有很多人努力往这个方向做出自己的一些贡献下面这个表格是我们从应用开发的整个端道端的流程上梳理了Walsum沙箱和Docker容器之间的一个对比从应用代码的一个开发流程来看Walsum只需要开发核心的一些代码逻辑而Docker中运行的应用通常则是依赖了许多第三方库或者是一些代码框架而从编译的角度来看Walsum沙箱Walsum应用只需要一件编译就可以编出应用一个Walsum二进制而Docker容器需要你自己去选择技术进向然后编写Dockfile最后通过Docker或标达等工具标编译出Docker进向从分发的角度来看Walsum的二进制模块非常小所以说它的分发速度可能相比Docker容器箱要快得多从部署的角度来说当前Walsum接触于K-Rustlite也可以在K8机群上部署运行起来容器当然就更不用说了从可扩展性来说Walsum沙箱毫秒极的人气重视度使得它能够在短时间内时间快速的扩缩龙从部署密度上来看因为Walsum沙箱内存要开销小得多所以说它的部署密度肯定要比Docker高很多然后从安全性角度来看Walsum沙箱安全模型主要是基于规则的卡巴比特的最小权权需要放模型并且Walsum基于SFI内存隔离机制也保证了内存的隔离性的安全更小的二进制也减少了攻击面Docker则采用的是基于NameSpace的隔离方式再叠加上Sigcomp这样的系统调用过滤的机制来实现安全隔离并且像包括进量中包含了完整的OS环境中的二进制文件和库文件因此攻击面也比Walsum沙箱来得更大下面这个表格中整理的是社区主流几款外败森比的Rontem对于外败森比的标准支持Proposal提案以及支持编译运行的模式的对比大家可以暂停看一下我这里就不一一过了既然开源社区中已经有非常多的外败森比的Rontem的时间那我们是否需要再造一个更牛逼的轮子吗回顾我们龙气生态的发展社区最早出现的是最早是Docker一家大后来出现了CallOS推出了RKT运行室为了避免龙气生态中出现大量的冲突和重复工作以及为了推动龙气生态更好的发展Docker,CallOS几家龙气公司就一起共同成立了OCI组织致力于围绕龙气的格式和运行室建立开放标准Docker也将自己的运行室逐渐单独剥离出来叫做Ronce开源定捐献给了OCI组织此后Ronvay,Kata各种龙气运行室就印裕而生了现在看看外败森比的社区现在也好像在走类似的路各个公司都开源了自己的外败森比的Ronetime你看这里有非常社区已经有非常多的外败森比的Ronetime这里还没有列全但是却没有一个全局可以全局管理不同外败森比的Ronetime的一个引擎那我们有谁可以去管理这些外败森比的Ronetime呢有没有什么类似于OCI标准一样的方式接口去对接不同的外败森比的Ronetime呢首先微软在这个方面做出了一些尝试并在2020年初开源了KROS的类似组件他们开发KROS的项目主要动机有两个第一就是他们希望能够用K8S原生的方式部署KBOSM的工作复杂第二就是为了反映Ros的语言的生态想尝试用Ros语言去重写CubaLate的组件当然这是一个非常有趣的尝试我个人也非常喜欢这个KROS的项目我们也对KROS类的项目做了一些分析我们发现KROS的项目当前还可能存在一些约束比如KROS类的不支持高可容器负载和Warsome类型工作负载同时部署运行在同一个节点上将KROS类和不同外败森比强偶合在同一个组件中无法实现不同模块的单独乐升级接下来我们就介绍一下我们项目的一些架构设计和功能前面铺垫了这么多终于到了介绍我们带来的变相云和边缘场景的云缘生运是实际引进Warsome Engine这是我们Warsome Engine架构的一个全景图它主要有以下几个重要的一个特性功能第一个就是在镜像仓库设的Warsome Tour ALT它支持在远端镜像仓库提供在线的ALT便宜服务它将WebAssembly字节码编一层架构相关的机器码真正的做到开发者一次开发一次开发一次编译然后到处在跨架构的跨架构的硬件上面实现以Lative的速度运行第二就是APS适配层这是我们面向不同北向生态而提出的适配层它不仅可以支持对接我们一有的Fast函数的一些现有的一些生态比如华为内部的元龙Surface框架社区上面的OpenFastOpenWask这样的开源Fast框架我们同时也支持对接以K8S为核心互相关的云元生的生态第三就是我们的进向进向仓库管理服务它支持本地从远端进向仓库拉取以及推送Wassam进向然后管理已经在本地的Wassam模块减少模块之间的一个垄鱼第四就是我们的一个资源限制能力像CGroup提供了龙期进程资源隔离使用的一个能力那么我们Wassam Engine也需要有相似的能力来限制不同Wassam应用的一个对资源的一个使用还有一个就是我们的一个任务调度的一个模块当有万几的Wassam实力运行在同一个节点上面如何高下的协调各个任务之中各个任务执行就需要有一个良好的设计优良的调度系统来控制第六就是我们的一个Wassam runtime API前面我们提到当前WebAssembly的运行时百花极放但是就是缺少一个统一的接口来促进接口的促进生态的一个良好发展我们在实现对接不同WebAssembly的Runtime的同时也希望能够不断的总结抽象出一套标准的对接WebAssemblyRuntime的一个接口下面我们就简单展开介绍一下我们Wassam Engine调度系统设计的一些理念以前在学习购义员的时候我就很好奇说为什么别人都说购义员擅长高并发可以轻松的做到万几以上的并发起求能力深究之后我发现Goloutine协成是购义员之时高并发的一个核心我们做过一个简单的测试一个Goloutine协成的上下文开销只需要100到200纳秒而一个OS线纯的上下文迁换时间却需要3到5微秒Goloutine的切换开销值能比OS线能快了20到30倍这是一个非常大的一个性能的提升因此受Goloutine的一个调度机制的启发我们就在想为什么不可以把Wassam实力当做一个Goloutine在用户台进行调度和管理实际上单节点上Wassam实力的高并发处理能力同时为了实现更快的能启动时间我们还实现了SnapShot的一个功能我们将热点的Wassam应用识别出来然后打快造然后这样以便在下次任务请求来的时候我们就可以从SnapStore里面快速恢复实力进行执行既然是调度系统我们也有肯定有不同的调度算法的一个设计比如说最简单的FIL、FI、FIFO的设计EDF最早截止时间算法的我们也将支持不同的调度算法来满足不同场景的一个需求来实现最优的选择来提高整个系统的一个吞吐量最后我们展望一下我们未来的工作当前我们的Wassam Engine项目正在开发过程当中我们预计我们会在明年的2020年上半年的时候在Opama社区上开源我们的项目也进行大家进行做以后到时多多关注关于Wassam实力之间如何实现高效的网络互通我们也将继续在这个方向上做更多的探索在开发Wassam Engine的过程中我们也将抽象出我们与Huberlater组建之间的对接的接口以及Wassam Engine与不同Wassamble runtime交互的接口希望可以将这些API接口推送到社区和大家一起来讨论完善这些接口共同促进Wassamble生态的繁荣发展最后我们也将与社区保持同步不断完善我们的Wassam Engine项目OK 我今天的演长到此结束感谢大家的联听谢谢