现在1.55了那我们就准备开始了首先大家好我是今天主长人我叫张浩灵我来自于ArmChina然后主要做的是容器安全容器以及虚拟化相关的云开源项目今天我们讲的题目就是QBvert这个项目在Arm上面的一些状况今天上午我做了一个QBvert Maintenance Talk主要讲了一下QBvert这个项目它的一个成长历程以及QBvert具体内容实现的是什么东西今天下午主要就是针对Arm平台上面QBvert整体情况向大家做一个介绍首先第一部分我会先还是简单介绍一下QBvert这个项目是什么具体它是干哪些事情还有哪些组件第二个部分我会向大家介绍一下QBvert在Arm上面的一些现在的状况以及我们做出的那些贡献最后我会有一个demo这个demo比较有意思我们是一个用Docker in docker的环境去创建一个QBvert的开发或者测试环境首先第一部分就是什么是QBvertQBvert它扩展了Kubernetes的一些API接口并且添加了一些自定义的资源就CDR它这样子之后我们可以原生的在Kubernetes集群上面去启动虚拟机并且实现虚拟机的迁移管理这个项目是由Red Hat所主导的现在有一些平台已经集成了QBvert这个项目包括了Red Hat OpenShift Virtualization和Sussy Harvester他们这部分虚拟化都是居于QBvert去做的在2022年4月份的时候QBvert变成了一个CNCF的副画项目我们Arm在2020年5月份的时候就提交了第一个PR所以我们也是很早的时候就进入了这个项目并且为这个项目做贡献接下来简单介绍一下QBvert它主要的一些组件首先是Vote APIAPI就是标准的输入接口它主要做两件事情一个是当我们把一个虚拟机的Instance的配置文件发送给它之后它会去做Validation就验证你这个配置文件是不是可用第二个事情它会做一些Mutating的工作也就是说会把一些default的一些配置加入到我这个VMI的配置文件里面去接着它会把这个配置文件发送给QBvert的第二个组件叫做Vote Controller那这Vote Controller它是一个Cluster Level的Component它是负责管理和控制整个集群上面虚拟机的生命周期以及监控虚拟机生命虚拟机的状态的一个组件当它接受到Vote API发给它创建VMI Virtual Machine Instance的请求之后它会把我们虚拟机的配置进一步转化转换成一个Port的一个配置文件那它这里面会做一些比如像添加一些Qmult Overload的一些配置就是因为我们配置虚拟机的时候肯定是主要是比较配置内存是配置虚拟机内部的内存那我们在Port里面启动这个虚拟机的时候实际是需要一些额外的开销的就包括我们的Qmult或者一些额外的Banary那这些的开销我们会在通过Vote Controller添加到这个Port的配置文件里面去然后再把这个Port的配置文件交给Kubernetes由Kubernetes去创建这么一个Port那当这个Port被Schedule并且创建出来之后我们的Vote Controller可以观测到这个Port已经被创建出来了这时候它会和下一个组件Vote Handler做一个沟通那Vote Handler是一个House Level或者是Node Level的一个Component它会在每一个Walker Node上面启动一个Demo Set它负责三件事情第一件事情它会去收集当前这个Node上面虚拟化的一些信息比方CPU对哪些Future就支持等等的第二件事情它会负责当前这个节点上面虚拟机启动第三个事情它是会如果虚拟机启动的时候要配置一些网络就是CSI就是存储相关的东西可能也由它去帮助配合去把这些插件或者这些配置给做好那我们刚刚Vote Controller把这个虚拟机配置文件交给Vote Handler之后Vote Handler会和我们刚刚Community是启动的Port的里面的Vote Launcher这个组件做沟通把虚拟机的配置文件交给这个Vote Launcher那Vote Launcher是每一个真正启动虚拟机Port的里面都会运行一个Vote Launcher那Vote Launcher拿到这个虚拟机的配置文件之后它会去把这个配置文件从压谋的格式或者是我们接正的这种格式进一步转换成XML的格式然后交由下面的LiberVort去真正的把整个虚拟机启动起来这就是它主要的一个启动流程还有它主要包含的组件那接下来就讲一下我们ARM现在QBVote这个项目在我们ARM上面的状况以及我们做的哪些贡献那首先要讨论的就是Cross-compelling交叉编译那我们为ARM就是在很多开源社区上面去使能ARM平台的这种功能或者是让这些开源项目能在ARM上面落地的时候我们遇到一个很大问题就是很多开源社区实际是没有ARM64的服务器的或者缺少这么一个编译的环境的所以交叉编译对我们来说是很重要的那一般来说交叉编译我们做的就是会交叉编译它的二进制文件交叉编译它的一些容器进向然后还有用所以我们自己也会写一些tours或者一些scriptshare script去帮助我们去做这个交叉编译那QBWet这个项目和别的项目有点不太一样就是它整个编译过程全部是用barrel去做的并且它的这个文件里面不单止包含go long的文件还有C的文件那所以呢我们花了非常多的时间去让这个barrel就是我们能够让QBWet能够实现这种交叉编译那第一件事情就是为了让barrel能够去close compel这个C的文件那我们把这个arm64的这种交叉叉编译tour chain给加入到这个barrel的library里面去并且写了一整套的就是将它和panform相关联使它能够实现要用这个交叉编译工区去编译这些C的文件然后呢第二个就是它的整个容器镜像它不是通过docker build去build的而也是通过barrel去build的那么这时候就牵扯到我们通过barrel去拉取一些rpm包和banner read的时候我们怎么去做那我们也是去写了一套完整的解决方案让barrel能够基于这种panform就当我们指定它是crossbuild的时候下载好对应的对应CPU架构的rpm包和banner read并且把它给安装到对应的容器内部去这是我们在crosscompelling上面做的工作然后第二个就是对虚拟化一些设备的支持那可以看到左边就我的左边你们的右边这时候照相图我们写了一个非常详细的文档去记录ARM上面对哪些设备做了一些支持那我这里列出来了一些可能主要和X86平台上不一样的地方那第一个我们的default boot method是使用的Uvable boot然后暂时呢我们还没有enable那个directly boot from kernel的这个功能然后第二个呢就是我们的有一些设备对于设备的支持可能还是比较有限的那比如像我们的这种显卡的设备我们暂时只支持vote.io GPUvga设备是不支持的包括我们disk的话也只支持vote.io的buzz那导致这个的原因呢是因为我们之前讲的真正去运行虚拟机的那个主键vote launcher里面安装的qmillKVM的这个banner read它不支持很多的device那这个banner read是来自于Sintel's官网streamline的rpm cool那官方就read hat出于可能安全的考虑他们基本上把很多的device都给剪切掉了所以暂时它对于device的支持是比较有限的当然如果大家比如像用quibbert的时候需要启动这种使用更多的一些device或者需要更多的丰富的支持那直接通过quibbert内部配置我们也可以去安装一些别的rpm包那这样子当底层qmillKVM这个banner read支持这些设备之后我们这个quibbert项目本身对于这些设备支持也可以实现的就在arm平台上然后最后说一下我们是怎么实现这种不同架构它的这种不一样的配置的那我们主要还是在virtuapi的这一个接口上面去做的就是通过multating webhook和validating webhook去实现的那当检测到我们host或者说我们要启动的这个虚拟机它的对应的cpu架构之后在multating webhook的时候会自动的把跟这个架构相关的一些代码写入到我们默认的这个虚拟机配置文件里面去这样子就实现x86和arm上面有一些配置不同但是同时能支持这两个平台那下面呢是我们对quibbert一些future的支持情况那其实大部分的future我们是支持的包括cpu manager这个就是做cpu绑定的包括动态迁移setcarsnapshot还有visoc等等等等这个地方也可以看到我们写了一个比较完整的document去记录我们支持了哪一些future并且对于不支持的future我们也详细标明了为什么我们不支持那下面我列了主要三个原因我们暂时没有支持这些future的原因第一个就是可能我们暂时没有这个硬件环境去验证future gate到底在我们按平台上运行什么完整稳定那我们暂时会写上去unverified比如像cpu gate那第二个呢就是有一些future gate对别的一些项目有依赖举个例子就是这个hotplugnetwork interface gate那这个依赖的这个项目可能对于arm的架构上面支持还有一些欠缺比如像有一些MatiArc的镜像就没有arm的这种架构的MatiArc镜像那其实这种大部分就我测试下来只要那个这种dependency的这种社区支持MatiArc镜像大部分future也是可以被使用起来的当然我们也在一直稳步推进让这些额外dependency的社区也能够去编译这种arm的MatiArc镜像就支持arm的MatiArc镜像然后最后一类就是我们可能就是CPU没有这个特性这里举一个例子就是workload encryptionSEV这种内存加密的这个技术现在是主要是AMD的CPU上面去做那arm暂时市面上CPU还没有这个功能当然如果未来我们的armCPU也有类似的功能实现这种功能的话我们也会去做一个替代方案下面就是一个这个hibrary的这个意购指的是底层CPU的这种意购简单来说就是我们支持X86和arm这种混合的集群的一个管理比如像你的控制节点在X86上再添加一个arm的这个walker节点是完全没有问题的只需要我们把一个future gateMatiArcMatiArtitecture的future gate打开然后并且选择我们想部署的这个节点然后并且在我们的Virtual Machine Instance的配置文件里面指定我们这个节点上面要部署哪种架构的虚拟机那么正常情况下它就会会针对这个我们配置基于我们的配置去生成对应的虚拟机那下面是一个配置文件的一个例子就是我们通过Node Selector去选择想要部署的这个节点然后在Artitecture上面指定我们这个部署的虚拟机是M64的架构的然后还有一个我们做很多工作的就是把M64的测试集成到QubiVirt社区的CICDPipeline里面去那我们这个大概有几步第一个我们因为这个QubiVirt是和Qubinetic使用了相同的测试架构也就是PRO的这一套测试首先我们得验证这个在M64上面PRO整体的运行状况再确定PRO这套架构在M上面运行没有问题之后那我们又面临到了第二个问题就是现在QubiVirt因为QubiVirt是启动虚拟机要用到虚拟化那在M他们在X86上面的测试框架是使用虚拟机先创建一个Cubinetic Cluster然后在这个Cubinetic Cluster里面去把QubiVirt部署好然后再用嵌套虚拟化的方式让E2E测试在这个创建出来的机群里面运行起来但是现有的Arm的市面上服务器是不支持嵌套虚拟化的那为了使得我们这种并发测试可以实现那我们这里使用了container in container的这种环境去做E2E测试当然中间也踩了很多坑解决了很多问题所以这个测试在在整个平台上顺利跑起来了那现在呢我们在这个开源社区里面运行测试的情况就是在每个Presubmit里面我们会跑三个跟Arm相关的测试第一个是在X8664的服务器上面跑一个交叉编译的一个测试第二个是在我们Arm平台上面去跑一个单元测试以及一个E2E的测试这个E2E是一个核心测试集不是它的所有的测试然后这里我想和大家分享一下就是我们去通过这种嵌到容器化去实现一个并发测试或者是并发开发的一个这种环境就是如果大家在Arm上面对虚拟机做开发或者是对Qubiverse这个项目开发可能会有一些启发首先第一个我们可以看到右边这个图我们会有个Bootstrap的Port这个实际是启动一个Docker in docker的环境就是Bootstrap本身它是一个容器在内部我们还可以再启动新的容器当它有这个环境之后我们通过Kind去在里面启动一个Kubernetes的CasterKind是使用容器来模拟来创建一个虚拟的Kubernetes节点它通过多个容器可以创建出一个多节点的Kubernetes的集群在后面的一个Demo里面可能大家可以有更清楚的认识第三个我们会在容器里面启动一个本地的Image Registry用来去存放我编译好的Kubernetes相关的镜像以及我测试要用到的镜像然后最后我们还会启动一个Buzzill Builder这个Builder里面会把我们所有编译要用到的工具还有环境全部配置好然后它会所有的编译工作会在这个Buzzill Builder里面去进行并且这个Builder当你即便把比如像我们这个Caster除掉或者重启它Builder也存在那这样的好处就是我们Buzzill Builder的一些Cache它会一直存放在这个我们的容器里面这样子你再次编译的时候你的速度会非常快那这个通过Container in Container的这种方式去做测试它有哪些好处呢那第一个就是它非常快那首先它用的是Native Builder第二个它使用了本地的一个Registry去存储镜像那第三个因为我们没有用圈套去你化去跑一些EQE测试那你肯定Bell Mantle上面去你化它创建虚拟机虚拟机里面运行程序速度也会快很多那第二个它的好处就是它可以把我的这个实现让我们实现这种频发测试也就可以在一台服务器上创建多个Kubernetes Cluster并且在并且在每个Kubernetes里面运行去跑一些虚拟化的这种EQE测试那最后就是使得我们这种Parallel EQE Testing is Possible下面是一个Demo去展示我们怎么在一个服务器上创建这个创建这个Container in Container的这种开发环境首先大家可以看到这是一个Arm的服务器那这里我没有直接使用Kubernetes去做我直接用Docker模拟了启动了一个我们刚刚讲的Bootstrap的一个镜像然后现在我们登入到这个Bootstrap镜像里面去好 可以看到这个Bootstrap镜像里面其实把这个Docker和Container in Container的这种进程启动起来了所以在里面是支持再启动我们这个容器的然后下一步我是直接拉取最新的一个Kubernetes的代码然后代码拉取好之后我们进入到这个代码库然后这里的话我们Kubernetes提供了非常多的一种快速部署的方式就在本地快速部署的方式这个地方可能绑不住了这个地方是输出两个环境辩量上面被挡住的环境辩量叫做Kubernetes Provider我稍微暂停一下这个Provider的意思就是我们用什么样的方式去启动本地的集群这里我指定的是Hind-1.27你用Hind-1.27的方式去启动本地集群这样子方式启动出来的就是一个我们讲的用Kind去创建集群然后再把Kubernetes部署在Kubernetes的环境上面的它还支持通过虚拟机拉取对应的虚拟机然后把虚拟机启动起来然后再虚拟机里面去创建这种KubernetesKubernetes本地环境的一种方式它提供非常丰富的Provider第二个就是环境辩量就是这个Kubernetes number node是指定了我们之后集群里面包含了几个节点这里我写了3就代表我会启动一个Controller的节点和两个Walker的节点那我们接下来就会把集群给启动起来可以看到那在启动的时候我们实际写了一些脚本让它能够对看营的集群做一些配置让它能够比较好的去支持Kubernetes的启动包括对网络等等的会做一些配置可以看到我们这时候Kind的集群已经启动起来了这里可以看到它启动了几个容器第一个是Controller Panel代表Controller节点的一个容器还有两个Walker节点容器以及我们刚刚讲的本地的一个Image Registry就是进向存储的一个库并且Kubernetes对应的这些服务也都完全启动起来了然后可以看到它有三个Node每个Node也是Ready的状态接下来我们就要把Qubivirt在这个节点上面去运行起来这里用直接Make Cluster Sync就是把我们当前这个代码同步到我们部署好的这个节点上面这里一段是它做Basell编译Basell会去网上去拉取很多的一些RPM包包括我们测试要用的虚拟机并且对我们本地的一些Code做一些编译然后最后它生成进向并且把它部署到我们的之前创建好的Kubernetes集群上面去可以看到Qubivirt相关的这些节点API Controller Handler Operator等等都已经被创建好了现在我们就尝试在这个节点里面去去创建一个虚拟机这个地方我直接使用了它的ExampleCode里面的一个配置文件它会创建一个Fedora的虚拟机当我们引入这个配置文件之后我们可以看到一个叫做Verture VMI Fedora的Port已经在被创建了并且一个VMI的Virtual Machine Instance也是在Scheduling当中好 这个Port已经在出手化了然后这时候我们可以用它Qubivirt自带的Verture CTL去访问我们创建好的虚拟机可以看到它现在还在启动阶段然后这已经启动完成了输入用户名密码之后我们登录进去可以看到它的网络是已经配置好了的然后我们外网连接也是配置好的这个都是Default它就已经会做好了这就是Demo然后接下来讲一下我们下一步想做的一些事情第一个就是我们想把它的CDI组建在ARM上面给完整的部署起来现在我们一个Cross Compile的Patch已经被Merged了但是我们还需要添加额外的CDI测试来确保这个项目在ARM上面运行稳定然后第二个就是我们希望能添加一些Performance Monitor的这种工具比如Purve帮助我们去监控在容器内部运行虚拟机的整体的状态以及它的性能等等好了 这就是我今天整体的演讲内容谢谢大家 有什么问题吗老师 你好我想问一下就是这个Couple Vert它是在Couple List里面run在Pold里面再把VM就run起来就是这种场景是什么什么情况下会有这种架构去实现好的上午的Presentation专门针对这个场景讲了一下讲了一下它的主要的几个场景第一个就是对于传统虚拟化的一种迁移那如果我们传统虚拟化的话一般来说我们要管理容器的我Cloud和VM我Cloud我们需要两套平台去做这件事情对吧可能通过OpenStack这边容器的通过Couple Nettys资源管理我们也是要同时监控两个平台那么其实这个是对我们的运为也好还有整体成本也好都是额外的一个开销那如果我们通过Couple Nettys这一套环境对我们的这个VM我Cloud和Containerized的我Cloud去进行统一管理那么管理成本也好还有就是我们运为成本也好都会降低很多那这是第一个那第二个的话就是我们把这种这种虚拟化的这种能力带到这种Couple Nettys里面之后那比如像有一些使用Couple Nettys的SACV Pipeline也可以有能力去创造创建虚拟机那么我们这种SACV Pipeline既可以创建容器又可以创建虚拟机那我们的边界持续会扩大非常多比如像你要去购建Windows相关的一些东西那我通过Couple Nettys一套的SACV Pipeline就会完成了我需要在不同的内核里面去验证我的整体的这种产品的稳定性我也可以通过QBWirt启动不同内核的这种虚拟机在里面进行一些测试对吧然后第三个就是我们这种因为它是在完全沿用了Couple Nettys的一些包括我们的CNI和CSI那Couple Nettys一些优势也可以附用到我们的虚拟化里面去比如像SACV Smash和我们是可以无缝衔接的包括我们存储PromiseOS等等也可以用来监控我们虚拟机的整体状况对 这就是我回答谢谢老师你好我有一个问题就是如果是用QBWirt的虚拟机的话它既有虚拟机的网络然后外面又有Dock的网络然后不知道这方面你们有没有做过测试性能方面有没有什么损伤是的 其实因为就是这个项目就把虚拟化引入到容器化包括引入到Couple Nettys这个环境的时候其实面临着很多的抉择就是你要选择性能还是更好的兼容性那在这一点上面我们QBWirt这个项目还是选择更好的兼容性因为它想成为一个通过Couple Nettys去管理我们虚拟机的一个工具那像刚刚您讲的是的就是我们会先创建POD的因为这个POD的网络创建应该是通过CNI去实现的做的 对吧那我们还是希望所有CNI的这些功能能在我们被QBWirt使用起来那我们在内部可能通过Bridge的方式再把POD的网络和我们的虚拟机做一些连接现在我们现在网络解决方式是这样子当然后面我们可能还是会提出一些比方在POD的内部我们怎么更快的去把POD的网卡和我们的这种虚拟机的网卡做一些更快的连接或者让这些包更快的能进入到我们的虚拟化层面去做这是第一个第二个就是我们可以引入第二张网卡比方通过SRIOV的这种方式直连到我虚拟机内部那么在这种情况下其实和普通的那种虚拟化解决方案我觉得这种网络的损耗估计也不会特别大我们通过Motors可以去为我们的虚拟机添加第二张网卡那第二张网卡可以是通过SRIOV就是这种方式连接到我虚拟机内部你好我有过深度使用我想问一下通过Motors来建第二个网卡你们现在有一种新的方式叫网络直通对吗Network password对这种方案你们是有什么跟Motors对比有什么优势我想了解一下这个我不是做网络这一块的所以我也没有做性能测试对所以我可能没办法特别好的回答你这个网型但是您可以把您的信息留下网络方面我可以帮您去问一下QubiWart负责这方面的Mantender可以谢谢还有问题吗没有的话我最后再给我们打个广告我那两个台词不好意思这个演讲机会在这里打个广告ARM年度技术大会是ARM公司在亚太举办的全年最盛大的活动中国厂围棋一周将于11月底12月初橫跨深圳北京上海3个城市到时候会有来自工厂芯片设计厂OEMODM软件服务艘出创公司等数千名数千名硬件工程师和软件开发人员齐聚一堂然后共同讨论ARM上面的一些技术展望和技术实现然后欢迎大家关注我们的公众号包括在楼下也有我们的展区可以拧取一些很不错的小礼品关注公众号以后谢谢大家