报告是相当不容易的我们终于找到一家它从171819年连续的三年统计了从企业的角度来看容器在企业的普及率然后左边这个不好意思左边这个图的话是说企业里面是否应用了容器技术呢我们可以明确地看到市场代理是主念上升的右边这个图是说在左边这个87%这个部分里面真正把容器技术已经用到自己企业的生产的系统上面来的这个比例大概70% 90%这是一个非常可观的数字也就意味着大家来做容器技术并不是做着玩而是真正地把这个东西奔着做生产来支持我们的业务这个诉求去了但这个可能跟大家的体感有一点差别觉得这个普及率没这么高这个是因为是这样的还有一个深头率的因素单里面考虑进来就是说一个公司的你利用多少业务线真正上的容器所以说作为一个公司来说或者一个公司把这个容器用到技术用到自己生产线上来说这个普及率已经很高了但是你整个容器技术在公司内部的覆盖率其实还是蛮低的所以这个东西角度来看其实容器还有很大的发展空间在整个容器的发展过自从2015年到现在差不多4年时间整个容器生态意志会逼不了的一个话题就是说大家觉得容器这个系统一提到说我们用容器就先考虑你的安全性到底怎么样是不是安全是不是能保护我的数据能不能做到相应的安全防护那从这个角度的话我们也从技术也是从不同的角度来正是业务的诉求然后提出了不同的技术方案那就是说我们作为一个容器所谓一个生产系统使用的这个基础技术容器来说的话它的安全其实是一个系统或者一个体系的安全它需要从你的容器进一项的生产链就是说你怎么制作进一项你进一项下面用的卑似的移密剂以及进一项里面本身包含的数据和执行的程序是不是安全的然后从这个包括整个制作好的进一项怎么上传整个上传是怎么下载到你的这个真正的服务上去执行这个整个供应链是需要安全的就是说你的容器进一项生产这个是必须安全的这个是说特别是现在容器既有在企业内部的私有运同时也有在外供应运上面的一些应用的场景那在整个基础设施就是说你下面这个运这个基础设施里面的网络 数据 用户 授权这些是不是做得了足够的安全在这个安全的基础上我们才是在真正容器运行的时候我们要保证容器运行的过程的安全那所以整个容器的安全我们不只是说只是说只要运行这个容器这一瞬间是安全的我整个容器生态就安全了所以我们需要构建一个生态链来保证整个端到端的安全那今天我们就不展开讲主要关注一下容器运行式的安全其实说容器的话整个逻辑是比较简单的其实按照现在主流的应用容器的方式都是前端你用K8S来作为业务编排最后你要把K8S的一个Port跑到某一个你的支撑平台上去整个事情其实很简单就是我需要从K8S那边编排好业务把它真正地调到某个资源上去执行那整个容器这个生态特别是安全容器这个生态大家会觉得这个技术方案还有技术提罚还有各种项目层出不穷那我们大概以一个相互演义的角度来看看这个事情是怎么发展的这个里面出现的并不代表时间先后只是说从它要解决什么问题来看这个第一步它就是最简单的用K8S直接对上Docker对上ConnerD对上Ronsee对Port的这件事情大家都不用说因为最开始容器都是这么构建出来的但是在这个基础之上那个红毛就说这个ConnerD这个系统太复杂了我K8S要去运行一个Port其实我不需要ConnerD那么里面丰富的东西不太好维护的东西就做了一个Creole它简单来说你就可以看成一个简化版或者定制版的一个ConnerD这个方案在这个字上Kata就觉得我直接在刚才训绍里面觉得提到这个问题Ronsee这样的运行机制它是利用一个共享内核的而这个共享内核的这件事情对安全来说是一个很大的弱项那我们就基于Kata这样的东西来提升运行式的安全那在这个另外一个是说这个用Kata是很好了你把我用虚拟机的方式把我的运行环境给保护起来了相当于修了一套防护墙把我的运行环境保护起来但是你在里面用的Ninux内核这个东西也太过复杂了里面Ninux内核几百万上千万行的代码那我的漏洞也是有的CV也是经常出现的那我是不是做一个更简化跟定制化的内核我只有实现Ninux的ABI实现Ninux相应的功能但是我整个实现简化很多那这个就是GViser整个数据像那个博士模拟一个Ninux行为然后让这个本身模拟实现又简单又安全可控这是整个GViser的一个思路那这个在GViser出来之后然后UnicusUnicus的这个社区又搞了一个叫做Nablacker的方案其实我最直白的检读就是说你可以从头写一个GViser这样的模拟Ninux内核我可不可以拿一个NetBSD的内核来直接模拟Ninux而且NetBSD本身就有这个NinuxABI兼容性了所以Nablacker本质上也是模拟Ninux内核的一个思路但是它用了Unicus相当于体量小然后可以和应用深度整合然后整个安全边界相对来说是比较小的一个特点那总之这个这一圈里面容器Runtime里面核心都在解一个问题怎么不要用hostOS来运行我们的容器其实大家都在解决这一个问题那最近这个19年那个Vimler这个虚拟化技术老大推出了这个碳阻或者碳阻相当于包含的一个叫做太平洋项目的东西其实太平洋项目的核心思路是非常优秀的第一个以前我的Vimler是用管虚拟机的方式来管我的资源的我管的是资源现在这一套出来的时候我管的是业务我管的是K8S的业务我用K8S的方式来调度我的资源第二个它的实现方案是用轻量化的虚拟机的来实现的所以整个这条路径也是相当不错的也是19年但是这个大家能查到的资料非常之少只能通过大家技术反解读它是怎么实现的但是你要看Vimler这家技术公司基于MicroVim的做安全插相的一条技术路线他们至少做了五年以上从13.14年其实已经开始在这个路线上做有不同的方案做一个方案放弃做一个方案放弃那是到最近为止推出一个比较称职的技术方案在这次运气大会上阿里巴巴也宣布了阿里巴巴卡拉桑德柏克斯的这样一个安全插相的这样一个技术其实它就是鉴于太平洋项目和卡拉卡德尼尔之间的这样一个解决方案它本身是基于轻量级虚拟化它不但用虚拟基因来隔离了容器的运行边界同时也会对进一项对整个网络这块安全上有受增强这个我们在后面会展开讲那基本上比较直观的理解的话阿里巴巴卡拉桑德柏克斯可以是看成太平洋项和卡塔东西之间这种形态它兼具两个形态的一些优势还有一个大的问题就是说在企业里面真正去落地这个东西的时候其实你不只是破的因为整个软件开发的生态这个周期包括整个生态环境其实是从原来从物理级到虚拟级到破的那我们既有这一套东西来支持破的那我其实还有一个问题就是我原有的虚拟级怎么管理它整个在收集里面两个比较典型的像我一个就是QBWT一个是WATCHNET本质上它的逻辑就是一点我用K8S来管理我原有的虚拟级的生产系统这是它一个核心诉求只是说我到底是解口是直接解开K8S还是解口点不一样但本上解决问题就是这样那今天接下来我们中还有一个Firecracker因为这个AW是这个电大所以Firecracker一出来大家默认就是Firecracker就是安全容器或者是暗杀箱的这样一个解决方案但事实上从技术上来解读Firecracker其实并不是安全杀箱或者暗容器它只是一个轻量级的VMM就是虚拟化管理器虚拟级管理器本质上Firecracker现在从它的整个实验上来说也是作为CATA的一个和Commune Binet的这样一个VMM来使用的所以大家对Firecracker不要有误解它只是一个轻量级的VMM并不是一个安全容器它要和CATA的其他生态结合起来才能实现一个安全容器的一些整体的需求今天我们接下来讲的主要讲这一块其他的生态的我就不细谈了主要讲讲我们这个安全容器的会怎么发展那就是这个共享内核这件事情是整个容器快速就是说基于Ninix内核来购建容器生态是整个容器蓬勃发展的根基没有这一条其实容器可能也发展不起来但是随着容器这个生态的进展然后基于共享内核这件事情它的代价也组建也组建暴露出来了就是这种隔离性不够包括你的安全隔离 性能隔离 故障隔离这几个东西可能都不太满足生产系统的需求作为原来一个研发系统基于共享内核是没有任何问题的大家快解方面的就能用起来但是真正的当你想把这个共享内核的东西推到线上去作为一个生产系统就会发现面临很多问题而作为一个生产系统其实它更需要的是一些高效 安全 稳定离开下生态兼容的容器引擎那我们怎么做到这件事情了它其实很简单大声简单给我们说了计算机所有问题都可以加一层抽象来解决那我们其实也就是要加一层抽象来解这个问题其实加一层抽象本质上也就是说把原来共享内核的一个解决方案做成一个独立内核的我下面的物理机上面的内核只是作为一个系统资源调度和一个系统运萎的一个内核使用而我真正运行业务的内核都是我独立的我每一个自己的容器有自己的内核这个里面的做法大概有四条路线最开始最简单的办法就是我直接买一个虚拟机在里面装一个装一个装一套容器的一套环境我就可以运行起来我这个安全边界也是足够清晰的但这一条问题就是说你整个系统太重因为你要自己从虚拟机到容器生态整个资源调度规划得要你完全自己去做在这个智商的话其实MicroM的思路就很简单这条安全模型大家是经过生产验证而且是得到整个业界规大家认可的一条路线但是它的资源太重所以我们本质上MicroM的一个核心数据是说我可以三反究解哪些是我真正地在运行容器需要做的功能需要做的这种技术我才真正地做出来对于那些不需要的东西我就把裁剪掉通过这条方式来减轻这个容器的资源诉求其实MicroM本质上就在做一件事情还有第二个事情针对场景的定制化因为有很多事情你知道你运行的场景是什么你可以做定制化刚才提到的GYS的话其实就是第三条路基于进程训练化本质上来说是说它里面也用了虚拟化来做一个隔离边界但是它自己实现的那个内阁模拟的内阁的行为第二条和第三条的本质区培就是随兜底第二条整个功能完全要有上面运行容器的内阁完全实现全功能的而基于进程训练化它本质上是这么一个思路我能做的事情我就做做不了的我就让下面的OS来做所以兜底的是下面的OS这也就意味着其实下面这个OS虽然有一部分业务被放到上面模拟的内阁里面去但是在下面这个内阁还是被深度服用的它并没有真正做到我一个业务一个独立的内阁所以它这一条兜底的还是底下的OS然后后面那个Ulicer刚才讲了其实只是一个进程训练化的另一个时间方案但是Ulicer有一个比较严重的问题它是需要和应用深度整合做改动的就是说你必须把你的应用针对Ulicer做一轮改造你才能用Ulicer的技术来支撑你的容器就是因为这一点基本上让Ulicer这条技术路线走下是非常坎坷的因为作为一个生产系统的时候你的应用基本上不会为你下面的一个平台级的一些变动来改动我的应用来重新把我的应用重新适配一遍所以Ulicer这条路线我们不是特别看好那整个夜间的态势的话大概可以看出来虚拟机基本上是有一个虚拟机你就可以装一个谁都能搞所以这个大家就不列举了然后Ulicer这条路线基本上就只有IBM的Nabla Container这一个事情我的感觉它们是玩飘是湿水的就是因为GYSR出来了然后GyUlicer这条技术路线大家赶快玩飘一把做一个类似的概念出来但是我本身我觉得它是没有深度实说怎么来整整落地的然后基于进程训练的话我从夜间来看我们能看到两个意志一个是Google的GYSR第二个是Windows的Windows Subsystem for Linux然后这个是第一代的时候是做自己一起的一个模拟的内核但是第二代的时候其实已经转到GyUlicer这条了就是WSR2就是第二代的Windows Subsystem for Linux其实又切毁了GyUlicer Microwave这条技术路线那在GyUlicer Microwave这条技术路线基本上就是不用说大家也能感觉到这个是整个夜间的主流技术路线大家基本上几大厂家在里面都有自己的解决方案包括阿里的包括蚂蚁的还有包括Virat的还有WMVL的还有AWS基本上都在这一个圈子里面所以从这个上来看大家也可能明确地感觉到就是基于Microwave这条技术路线可能是更符合一个技术主力威胁那我接下来要讲一讲就是说在整个GyUlicer Microwave这条技术路线大家平时接触最多或者整个行业里面最领先的或者应用范围最广的一个解决方案就是Cata Container因为虚众在这我也不就具体展开这个什么Cata Container架构了我们就讲一讲从用户的角度来说我们认为Cata Container哪几件事情是做对了的因为它做对的几件是让我们选择的这个技术方案我觉得这个可能是大家更值得探讨的一个话题我觉得Cata Container做对的第一件事情就是使用了Linux内核因为对于一个面向这个公众服务的一个服务形态如果你的内核服务平面不是标准化的而是一套私有的一个定制方案你要去摸你Linux的行为这件事情基本上是密信铺色博的因为你基本上是做不到的有好多案例已经无数次证明摸你Linux的东西基本上最后是失败的所以对我们来说基于一个标准的Linux内核的Sysm Core的解构来为用户提供服务这是以最大程度上保留了保护了我们的客户的机友投资于商买你的应用基本上不用做改的就可以在这儿落地第二个事情就是一个清单级虚拟化把我们整个容器运行的边界包起来了然后这样让大家有一个非常从资源从你的安全从你的故障上面都有一个清晰的边界这件事情对一个服务商服务供应商非常关键的因为意味着我不会相互影响用户1和用户2的业务之间是完全隔离的这一点我觉得是一个很好的趋势第三点也是很关键的一点就是平时也不太感觉到就是卡塔和生态的融合的结合度我觉得是整个解决方案里面是最优秀的因为从原来的Docker到现在的K8S整个卡塔的融合度都是非常好意味着我们的客户上来从你的管控屏面你可以直接用K8S来做管控从你的应用屏面你可以直接用利利克斯的标准的Sessimon Core来做应用意味着客户在整个应用这套技术方案上你基本上是无感的可以搬上来这个其实是非常重要的一个特征如果没有这些我们让客户从原来的系统里面搬到这样一个沙箱或者安全的一个容器生态里面这是面临很多挑战的接下来讲阿里巴巴的鸡腾内部对安全沙箱以及安全容器的一些应用的一些场景以及采用的一些技术首先其实我们大概归来一下阿里巴巴内部的一个应用场景最左边的那个其实就是我们面向公众提供的容器服务其实也就是一个云的容器的多组服务在这里面它是要求是说不同用户的容器都可以安全跑到我一个共享的基础设施上面来不同的实力之间是有严格的隔离的有严格的安全保障的有严格的性能的QoS的保障的这个可能大家都是比较容易理解的结果它就是像那种类似韩束计算这样的场景虽然基础设施都是你的但是代码是用户传上来的这个代码传上来的有两种场景一种是说用户就是传代码第二种是你从一些不可信任的一些源头下载了一些代码下载了一些库或者下载了一些应用跑到你自己的生产环境里面来在这个时候其实你也是需要把这个东西用一个安全边界把它确定到一定的范围之类来执行的第三个可能是大家平时不太能感受到的这个是要重点提一提的因为这几年随着银基算推进现在不同业务的混合部署其实也是一个很热的话题但是在不同业务的混合部署里面其实它面对的技术挑战很满大的在这个过程当中原来基于这个共享内核做了一轮部署然后大家基本上做到一定变成所以发现这个事情安全容器面对一样的问题在同一个内核上你怎么去隔离两个不同类型的应用这件事情是很挑战的那终合起来我们可以看出来把这个需求背后其实你可以抽象成几个真正的诉求是什么诉求其实就用一个词就能把它开过出来就是隔离性从我们的多州服务里面我们的隔离除了安全隔离以外我们还有支援隔离性能隔离和故障隔离故障隔离意味着我一个用户的业务出问题我不能影响其他用户的业务那从这个执行不可行代码的地方它的诉求相对是比较简单的就是一个安全隔离就可以了在这个混合部署里面它的诉求也大概是支援隔离性能隔离和故障隔离这里面其实是我们有一些大家如果真正做个生产系统就会有特别明确的感觉当你把两个不同的业务和部署在一起的时候每一个业务都是针对自己某一些特定的内核版本做个深度优化的甚至在内核里面有一些集成改造的针对我的业务把内核做了很多精致化当你把这两个业务和在一起成立两个内核融圆和合不到一块这个时候其实冲突是非常之大的在这一种其实安全隔离相对这种方案其实就能很完美地解决这种问题就像你每一个业务可以自带到一些内核有自己的一些精致化的一些功能有自己精致化的一些特性还有一个就是故障隔离因为最害怕的就是现在这个服务器也以前可能20年前做的是一个服务器就4个8个CPU就不得了了现在随便一台机器上来就是200个CPU400个CPU然后可能到1000个CPU这件事情也不是太远而我们现在每个应用真正每个应用需要的CPU的资源其实大家这个程序源的这个质地还是有限的真正的拥好的CPU也大概吃到8个这个样子就超过10到8个以上把这个资源用好其实是很困难的所以说每个应用的规模其实对资源的诉求还是4到8个CPU但是我们本身物理资源这个服务器的资源是在逐渐线性上升那就意味着在我一台物理机器上存载的业务会越来越多而在这个地方如果你底下的核心的后收尾是出了问题那意味着你影响的业务面就会越来越广所以从这个角度从故障的隔离的角度我们尽量把你的这个执行单元和你的应用的诉求等同起来应用诉求是4到8个CPU那我们资源的供应单元也是4到8个然后相互之间是相互安全隔离故障隔离的所以这点其实是平时可能也是真正的和生产系统打个交道和感觉到的一些领悟的点吧那还有一点就是说阿里这个安全刹箱可能是今年在银袭大会上整个对外宣布说阿里有自己的安全刹箱解放案其实在阿里内部整个容器安全刹箱的整个技术节奏和整个业界是精准同步的从2015年开始然后在阿里内部开始基于我们叫Villeneck和现在这条路线的比组就从那个点开始到之后我们逐渐研发去不同的技术方案到今天为止我们推出自己的安全刹箱这个技术方案本质上这条路径其实上和业界的发展基本上是一致的而且非常可喜的是18年到19年基本上是安全容器技术的一个紧喷链17年底Inter和Hyper联合起来组成了卡塔肯尔人一个技术项目然后18年5月份Google的G-Visor开源18年的11月份AWS Firecraft开源然后19年泰平洋项目出来整个你会发现各大公司基本上都是在1819年把前期开发过几年的技术图件再向整个产业圈再推广所以这两年是一个非常明确的一个容器技术的紧喷链在阿尼的安全刹箱其实是最直白的解读就是基于Becorum架构的实现多做安全的高兴的容器运行环境这个地方最后一个关键是容器运行环境不是容器装碳因为本身容器装碳它只解决在欧塞这个解口之下你怎么安全地运行一个容器而我们这个安全刹箱它不但要解决我怎么运行这个容器我们还要解决怎么为这个容器准备相应的安全环境包括你的经向怎么每个客户的经向怎么安全地管理起来我们怎么保证我们去去破一密集的时候是走拥护的网络而不是走我们自己的管理网络这个数据永远拥护的数据不会进入我们的管理网络这两个面是严格分离的这些问题总结上来说就是说我们不能管怎么软怎么运行一个容器我们还要解决怎么为这个容器准备好环境所以最后这个车比较关键是我们本身实现的是一个运行环境而不只是一个装碳这里面它用的核心技术就包括这种底下虚拟化针对这个容器这个场景虚拟化相应的功能的加固和裁解然后我们对整个虚拟机模型的经解还包括经向管理这些具体的点我们可以待会儿下来具体有问题可以大家下来交流一下我们通过这一套组合玩我们大概做到的沙乡启动时间大概能做到500毫秒以下然后在液态机器上我们一秒钟能启动200个以上的实力然后我们的内存开销指看外面这个级别的开销刚才那个虚拟是说成果外面是大概11兆但是当我们真正把实力跑多了以后其实这个资源平均之前还在往下转我们大概是能做到两点几兆但这个东西的话意味着我一台物理机上来我一秒钟就可以拉起来200个实力机基本上把一台物理机的资源就吃光了意味着我的业务的弹性是非常明确的我一秒钟可以把一台物理服务器准备好那最后一个章节是关于容器的发展趋势以及我们对安全容器的一些诉求举几个声风刚才讲了一堆这个容器其实大家很难理解到底各个容器技术路线是什么问题解决了什么场景其实我们拿声风中最简单的例子其实就很容易把这个理解清除了左下角这个图就像那些ROMCROMC是什么就像那是一个群猪房一样大家在这里面拉个帘子房间一隔然后反正隐私也不太好然后各种资源也是公用的反正除了问题你的资产保护也不太好所以大家都忍着点但是它的好处就是资源利用力非常高因为你基本上不需要修什么隔壁的墙这些都不要了一个帘子就解决问题了其实CATA本来就相当于一个合作房就是什么呢可能大家干工作的都住个合作房是吧每人有自己的卧室但是你的客厅你的厨房 卫生间还是公用的这就意味着我在运行的时候我有自己独立的资源但是我的经向管理我的网络这些东西其实还是一个公用的资源所以本上CATA现在1.0的价格相当于一个合作房这样一个场景还有我们做的阿里巴巴拉卡拉桑德波罗斯本质上就是想做的一个像这个有点是公寓一样它给你提供了标准的服务你零包入住里面所有的环境卫生打扫都是用我们来负责你只需要管我在里面住一晚上我走人就可以了你根本就不需要操心整个是什么样子的而且还保证你整个进来是安静安静的 安静的清洁的一个环境你要做虚拟机的话很简单那做虚拟机大家也知道做到虚拟机我总得添加均甚至装修 对吧这些东西你都自己负责这个当然你这什么隐私你的财产都可以得到保护但是你要做到家务就多了因为你每天扫地你的自己干了没人给你扫地了但是如果你还有更高人的像金融机客户你可能就想去买一个裸金属虚拟机这个物理机上面还有多个用户的业务都是部署在同一台物理机上我觉得那个还不够干净我就要求对身后要求品质很高我可以去搞一个别墅这个别墅周围环境也很好我想怎么装修怎么装修周围可能几百米以内就没其他住户 对吧那其实这个就像那样平时在整个云户里面你去买一个裸金属整个物理机器完全归你使用那从我们的角度来说我们觉得可能基于中间这种酒店式工业可能是一个比较合适的一种对外提供云户的一种形态所以我们也很希望踏踏能往这个酒店式工业这个方向走一遍提供更好的服务那其实从用户的这个诉求来说其实用户业务诉求就那么两三条就是以最少的成本以最安全的方式最快地跑完我的业务大概就这么个事情 对吧那除以从我们的角度来说的话我们是希望理想中的一个融洽军环境它首先也有超越虚拟机的安全性因为最后大家听起来很第一反应是不太理解为什么你是基于虚拟机的技术你还能超越虚拟机的安全性这个其实也很容易就能想明白这个个点因为你在用标准虚拟机身你要照顾各种各样的场景而照顾各种各样的场景你出漏洞的机会就大增对于容器这个场景我们只需要解决特定场景我的整个代码让我整个实施方案的复杂度都可以比虚拟化简单很多甚至我的这个保护措施都可以上下联合保护基于这样的一些安全设计出来的安全性是可以超越虚拟机的第二个是视频装饰的性能因为这个这个听起来是很疯狂的一个提法但是事实上从用户的角度我管理什么安全容器装饰我的业务复还搬到你上面跑慢了你给我解释吧对吧 这个就很简单那这个怎么做到这一点大家可以大家可以整个很一起共同地推动往这方向走但是我觉得从用户数据也是很直接的第三点的话就是说无缝对解生态因为用户为了一个底层技术来改制举业务这件事情我认为基本上是不可能的虽然我们自己做底层技术人觉得自己技术很牛但是你真正到业务的而去你就是一个遗坊因为省加业务在这很厉害的时候你就改了什么基本不现实所以我们必定要做好生态兼容让业务在不同的技术平台之间切换基本做到无缝切换做到这一点整个你的这个几层技术的同样性能做好那其实本质上来说我们做安全容器最后的目标是什么呢就是做到这个性能和安全的这个双丰收就是予以凶人而间的我既要有性能同时要有安全如果你只有性能没有安全这件事情不行如果你只有安全没有性能用户也不买账所以用最后的目标其实就是做到一个保护确保护确我们提供的容器服务里面天生内置的就是含了各种安全的能力和解决方案然后让用户可以无感值地应用这种安全插枪而不要让用户在装饰和安全容器先做选择那不是一个很好的境地那我们从从我们做这个容器的角度来看就是说这个到底我们容器这个角度从从希望CataV2因为CataV1.1已经解决了现有的问题让我们再看了这个设计往前发展或者是这个技术领域往前发展我们希望它能在哪些方面做得更好了第一个就是安全安全不只是说我们要去用什么什么技术本质上安全是需要一些高层设计的就是一套你的技术架构你的微信模型是什么哪些主件是可信哪些主件是不可信的可信和不可信的边界在哪儿相互保护随意来控制这一条我们是很希望从Cata整个大的设计以前大家构建一个清晰的安全模型不只是说因为Cata是用了虚拟技术所以它是安全的这话是立不住脚的我们需要有一个比较规范的模型来证明我们Cata真的是安全的第二件事情的话这个K8S或者容器社区它的一等公民是Ransay基于虚拟机的这种技术其实是一个二等公民就是说它有很多的时候它的做法是把自己伪装成一个Ransay的方式来运行所以说整个K8S生态对基于虚拟机这套技术架构的适配度还是有所欠缺的所以我们也希望和整个同行们一起来把这个K8S生态和基于虚拟化的这种就能配合得更好第三个点的话就是要尽量减少组建然后提升全链路的稳定性因为这个地方可能能谈到话题非常多因为作为任何一个技术方向第一步就是先用现有的组建快速地达建起来自己设想中的一个软件模型然后验证明我这个东西是可行可用的我认为现在Kata已经度过了这条阶段了就是说利用现有的各种组建以打击幕的方式达出一条解决方案这件事情已经做完已经证明了Kata这个技术架构的优越性但是下一步我们不能停留在打击幕当你真正证明一条这个技术性可行的时候其实应该是为真正的生产系统三环就结只做自己要的东西实现自己的功能保留自己原来设计的精髓这个里面从我们的切成之痛口给大家聊一聊就是说你看CRI和OCI之间的容器引擎的这一条路径整个大的脉络其实就是要减少组建数量从最开始的三个组建到CRI加肯尔D再看两个组建到现在直接整合进去搞成一个组建那其实你要是看这条路径你就觉得好像挺完美的了一个CRI 肯尔D加上一个OCI的引擎直接跑一步或者好像这个电路已经很短了 对吧但是真正当我们把CATA这个黑盒子打开的时候你会发现其实后面还有一堆路径因为你要是看装C好像路径是很短但是你要把CATA加进来整个全连路的路径你就长了从我们刚开始结束CATA 1.3 1.4的时候还是新闻加Proxy然后还是每一个容器一个新闻然后再到里面的VMM再到Gaest再到里面Agent然后我们自己切成的感受从1.3切到1.51.6之后的新闻V2这个里面其实它做的一个核心改动就是把每一个破的一个每一个容器一个新闻进程切换成了每一个破的一个新闻进程这一个改动对于我们线上的压力测试的故障率是要降低一个量级的这个我不知道大家有没有感受因为你要真正一个产品上线之前你一定会做各种高压去测试我的性能稳定性 可靠性在我们实际生产当中第一条路径的稳定性是要差很多的就是因为这一个小道改动所以从这条路径我们还是很希望尽量把整个因为大家已经证明了或者已经带来形成共识是说卡塔这条技术路线是对的那我们怎么把它做到更可靠更可用更可靠的关键一个点就是减少里面的组件数量因为很简单当你系统运行压力很高的时候以各个组件中调度是顺序不可控经常就会导致你的控制性道上面的各种反应时间出问题 出误判而这件事除了误判之外基本上你没有招来恢复那就意味着就是一个很严重的事故那如果我们把这个做到一个迫折制有一个对应的实体全联络里面我一个迫折制管一个实体这一个实体死就是这一个实体活就活那我基本上系统里面不会出误判我们最害怕的是出误判本身那个实体还在活着就一个你从管控联络上把它判成死的然后又重新来购建一套新的系统起来这是非常危险的一件事情第四个点头刚才已经提到就是信用清谅因为我们可以明确地判断出来这个容器以后的部属密度在单机上部属上签个容器这个是很现实的话题虽然现在可能大家还没打到密度但是这个技术在往后走个一年到两年那我就单机部属上签个容器实体这是很现实的那在这个情况下正和一个支援耗用器是大家都要去考量的是不是最合适的用支援的方式第五条就是可运微信这一天的话可能平时大家不太有感受但是真正当你去做业务签译的时候你的业务方会说我原来运行装塞的这个容器的时候我整个系统因为是这么这么这么搞的现在你多了一个容器以后多了一个卡塔多了一个训练机之后我的整个管控联络走不通了那一条路我们可以让用户说那你要用我的方式你按我的方式来办事你给我当容器怎么搞这件事情可不会搞可以搞 但是你会很费力那我们有一种可能性让用户像管装塞一样的用为方式来管卡塔如果这条路走通到整个让卡塔落地这个通道会大幅打通因为意味着用户的整个管控体系是不用改变的不好意思 稍微有点紧张这也就是讲一个事情就是刚才提到了卡塔现在从卡塔手页上进去就是一个安全的绕炭我们期望中卡塔不只是一个绕炭它应该是一个容器的安全运行环境在这里面它不但要包含这个容器运行时的环境还要包括容器一些进行管理 网络的管理总之我任何一个实力的资源准备都应该以这个用户的身份去进行我们是很希望卡塔能以这个角度扩展自己的事业不举行以一个安全的运行环境而要实现一个安全不只是举行一个安全的绕炭而是作为一个安全的运行环境来定位自己这个那是给大家提出诉求的接下来讲一讲这个话题因为刚才讲到这里面我们是基于MicroVM的MicroVM里面到底VM是个啥那从其实在整个卡塔社区里面其实我们基本上可以把它叫做VM之战了最开始是Commune然后到Communite到Lume然后到Club HyperVacer后面这三个东西是在一年之内发生的从星期到衰亡一年时间所以很明确地感觉到对于云元圣这个场景下或者在卡塔这种场景下到底它下面的 HyperVacer该长成什么样子其实现在是没有形成定论的至少有一个结论是说基于Commune改版这件事情好像是不太行得通因为我们已经发生英特尔这个训练化团的已经发起两轮冲击从Communite到Lume最后这个方向上都不是太顺畅走的所以他们基本上从内部已经放其实还是走了Club HyperVacerClub HyperVacer这些东西接下来讲原来讲一讲Club HyperVacer到底是个啥东西其实Club HyperVacer都蛮清楚的其实整个技术原测反正大家搞技术的都不占商务就实话实说这个技术买卵是怎么来的2017年的时候Google针对自己的Commune的OS搞了一个Google的CrossWMCrossWM一句话总结就是用Rust写的简化版的WM然后这个AWS发现Google CrossWM之后然后就针对自己的场景改造了一个版本出来然后就像是说从CrossWM拍成出来一个Firecracker然后在Firecracker开源的时候这个事情说巧一巧说不巧也不巧在它开源之前其实阿里内部正在用C写一个这样轻量级的WM然后以Firecracker一开源我们发现这个挺好用Rust写这个语言比较安全然后大部分的工作也不用我们重复做了所以后来我们采用的程度也是从Firecracker的人派生出来然后实现自己的一个技术的WM然后最近Inter又从CrossWM拉出来了一个CrossWM这个本质上都是用Rust来实现一个安全轻量的WM来服务于云烟生和安全容器这个领域然后在这个里面其实大家会发现好像这么搞下去每个人都做重复工作不是太合适因为程序院的工资也很贵每个公司重新写也好像也不划算所以其实大家最后就形成一个合理组织的一个Rust写的社区就是说在这个里面大家公共的部分大家就被从头搞了大家配合起来把它放到一个开源社区里面大家共同来搞这件事情就可以了Rust们从它的单身之初其实都是从Kata这个社区长出来的最开始就是Firecracker进了Kata社区然后大家发现有这个共享代码Base的诉求然后组建拉出Rust现在算它单独作为一个项目来管理其实它是从Kata长出来的那我们再稍微这里面有一句话个人观点不知道大家认不认可因为我大概变成十几二十年从颗边语言到世界语言世界加瓦然后加瓦scriptACM5这些语言我都搞过最后我觉得在系统级的语言可能Rust是一个不错的可选之项大家如果以后再考虑系统语言宪行的时候可以考虑Rust因为最近它的成熟度上来了整个几大公司里面你都能感觉到有一些重量级的项目在网络大社的欢迎手从我们实际的使用经验来说的话用它有痛苦的地方就是说它下面的可用的基础组件相对偏少但是你一旦用上手你就会上瘾你会发现其实还是挺好的用好了我们实际在生产当中有好几次上千行的代码墨迹进去没有出任何bug它的其实核心一点就是一句话让你在你写代码的时候把你所有问题想清楚不要再上线之后再发现问题回过来修其实这是一个非常有良的设计思路就是按照它的规则写代码写代码不犯错这件事情其实是很好的一个设计思路回过来看到底Rustrem里面在干什么呢其实我们大概可以看一看Rustrem里面它本质上就是把作为一个像Kobe这样的VM的一个公共部分抽出来大家共享从Rustrem的一年发展来看大家可以看出几个节奏第一个就是先把VM里面这几个核心的东西做出来了就是跟KVM打交道的东西虐存管理啊这些核心的东西做出来到这一步基本上核心部分做好了现在到了一个阶段就是最近这几个月在做的大家众部做的事情就是说做设备模型的建模就是说到底我这个机器的设备模型怎么管理这个是正在做的一个过程当中我预估还可能需要三五个月可能要到明年二三月份可能黄色的部分大部分应该能READY了还会剩下一部分其实就是黑色的部分就是各种设备的驱动的实现这个可能到明年底能做完就差不多Rustrem和整个里面有很多共享库我们像我们阿里云的大根布还会做什么其实在这些共享库制上我们还要解决很多问题比如你的API的解口是什么你的AO调度怎么实现你的资源怎么管理热身一热切印这些认为能力怎么实现所以你会发现作为一些基础的能力大家是在Rustrem里面作为一些更高级的一些产品能力其实是每家公司还会自己在独立开发的这里面希望大家如果对这个方向感兴趣可以一起来来构建基础Rustrem来构建一些基础的能力后面我们基本上从阿里云这个安全杀箱其实它的整个思路很简单就是立足于自我然后通过生态共建来共同打造一个云原生的安全的运行环境这里面我们肯定会和卡塔肯尼尔深度配合把我们原来在阿里巴巴的卡拉帕克上面的一些设计一些能力然后逐渐和卡塔这边配合起来把它落到卡塔这个容器的这个社区里面去同时我们也会和Rustrem和英特尔卡拉帕尼尔深度配合来为这个云原生量生打造一个真正时刻云原生这样的一个为M的这样的应用我们不是说要替换KOM而是说在云原生这个场景下用KOM有可能不是最合适的解决方案所以我们会为云原生为容器这个生态去构建一套清亮级基础Rustrem跟这个清亮级安全的容器生态最往上我们必须是要和KBS这个社区做深度融合的因为这个东西搞不好的你的用户业务就用起来会很痛苦欢迎大家一起共同来构建这样一个云原生时代的基础的一个运行环境好 我的这个交流解说然后有什么问题大家可以随便问不好意思 多耽误了几分钟没问题的话就讲到这就结束谢谢大家