好酝酿一下大家好我们今天跟大家介绍一下就是卡塔和卡天尔蒂之间的接口眼镜随着这个接口眼镜给我们带来的架构和架构上的提升以及整体的性能和稳定性上的极点上的提升我是蚂蚁集团的潘涛他肯定是架构元汇的成员大家好我是吴超我是来自阿里云的基础软件团队的一位同学我们主要是做隐约身还有安全容器相关的然后彭涛刚有提你是卡塔的那个AC的成员我是卡塔的那个一个明天的今天我们主要就是想从这个接口眼镜的一个角度来看一下安全容器或整个容器生态的一个眼镜那么首先让我们从最大家可能一问最多或最基础的一个问题开始就是说在Sensef的那个landscape里面我可以看到很多容器的各种所谓的肯定上的轮胎组建比如像卡塔肯定上的地或者是蚂蚁刚开的KusarGivizer等等我们有一个很全的一个肯定上的一个University但是他们各自的组建他到底他的那个生态位置是什么他的作用是什么他的差异是什么呢我觉得我们要解释这个问题就要从接口开始说起虽然接口这个东西很小但它却很好的规范出来他们每一个组建他们的一个生态的位置那么就让我们从接口来说起吧就是在2015年的时候就当时容器开始新起了然后呢叶杰就会觉得Dalker你有自己的一套标准然后像RKD你有自己的一套标准容器的镜像呢可能在别的容器的那些组建里面的镜像就跑不起来了所以Industry就是说我们需要有一个大家一个Universal的一个标准一个标准来去说这个容器到底是怎么一回事所以在2015年的时候定义了穿一套标准叫OCI就是Open Container Initiative这边这个I也需要特别强调一下画了一个线因为它是一个initiative而不是一个interface所以说它其实本身定义的是Ethelier specification这边我也从它github的repo里可以看到它有定义镜像的标准是什么然后Rentime的标准是什么The Tribulation的标准是什么在这个这个接口的定义出来以后其实在Dalker和RKD它跟往上去定义那一层的接口就清晰了那么再往下Kubernetes它出现了以后它又开始有点疑惑了就是说你现在有KentnerD有CRIO有等等不同的一些容器运行时那么我需要有一个统一的方法向下去沟通否则的话我没有办法就要在它的代码里面去偶和很多的不同的容器运行时的逻辑所以这时候它们就定义出一套接口叫CRI这边就是KentnerRentime interface这边它就是真正的一个接口的一个interface可以看到这边的话它有像image的service还有Rentime service就是说镜像是怎么它要去怎么去交互的Rentime它怎么交互的然后呢整个CRI其实它就是去定义Sendbox那一集它要做什么操作KentnerRentime那一集它要做什么操作镜像那一集要做什么操作在这边我们着重强调一下Sendbox是什么因为这个跟我们后面演讲内容息息相关Sendbox它就是在我们去容器去生产的时候它是第一个去在第一个去产生的然后它是最后结束的它去规定了整个PoS一个资源的一个情况同时呢在不同的这个低阶的容器运行时里面它的这个形态是不一样的比如说在RunC里面它就是一个C-group的形态加上一个PoS Kentner那么像在我们Kata这样的话它其实就是一个MicroVM一个轻量的虚拟机那么介绍好这些接口以后其实就到最关键的这一步了他们是怎么串联到一起的他们整个故事现在是怎么铺开来的那么从一开始我们最开始组建我们现在分别看有四层第一层就是一个高阶的Kentner Management然后再往下是高阶的一个Kentner Runtime再往下是一个低阶的Kentner Runtime最后到我们实际生产出来的容器我们一层层往下看KBS有了CRI接口它就知道它怎么跟不同的这样的一个容器高阶容器运行时去对话了它用CRI接口可以跟Kentner立可以跟CRI-O或者说像Asuna这样去对话然后有了OCI这样一套标准的话这些Kentner立他们又知道怎么对接下面不同的这些低阶的容器运行时去生成不同的一些容器像Kata,Giviser,RunC那么在最后由于我们低阶容器运行时有不同的实现那么像Kata它最后启动的形态就是一个Micro的VM一个轻量的虚拟机里面其实包了一个容器然后像Giviser它就是启了一个Sandbox就是它会对它的Syscall做一些处理然后去确保安全性里面是Kentner那么RunC的话就直接是一个Kentner了那么其实这样的话这张图我们就可以定义出来整个我们低阶里面整个容器的一个宇宙里面他们大概各自在什么样的一个生态位里面而这一切的一切都是从接口开始的就是有了些接口大家就明确记得位置在哪里明确他们要干的活是什么明确他们最后的形态是什么那么今天我们的演讲也是想以小见大从接口这样小小的一个点展开来看Kentner的D和Kata这两个生态组建之间他们是怎么演进的他们讲他们这个接口演进的里程怎么让这两个组建不断地去自我的革新还有在性能啊稳定性啊等等上去做提高那么接下来先由彭涛来先介绍一下Kata肯定有了一些情况还有一开始的一些接口演进OKKata肯定是我们这个项目我们大概是在七年底的时候开编出来的然后他其实看到的是一个容器发展的整个生态发展的潮流大家最开始在部署的时候其实都是在物理机上直接部署各种各样的进程这些进程之间就会相互干扰在后来的话Doker就发明引入了容器这个概念然后大家开始把各种各样的容器进程包到容器的抽象里面去然后他们之间通过Linux Name Space和C Group去做隔离但是在下一代我们认为就更强的隔离性的时候我们需要更强隔离性的时候其实我们再把迅机这一层引入进去就是把迅机作为一个隔离的一个一个边界而不是把Linux Name SpaceC Group作为经济的边界这样的话我们可以得到一个更好的继续迅远化的隔离性而继续迅远化的隔离性其实在infrastructure and service这种就是大家买迅机这种场景就云产上的迅机场景就迅远化这个隔离它的隔离性是经过了这个行业十几年的一个长期的检验的所以这个是让大家能够得到更好的隔离性的一个方案所以其实从那个时间线上我们可以看到就是从Bear Metal的那个进程到Tradition到Zero容器然后再到Kata Connors不同的容器的形态然后在2017年我们把Kata Connors这个项目把它开源的时候当时的架构大概大致是这样我们通过通过引入了Kata的SIMKata的Runtime以及Kata Proxy来把hose上所谓的管控上的链路打通然后在迅迅机里面通过走那个JRPC Over Jamax这样的一个接口通过串口把它通到Guess里面的Edginer然后由Edginer在Guess里面去创建那些容器的进程然后在Kata我们当时能做Kata这个项目其实很大的原因就是因为有OCI刚才提到了吴超提到了OCI的这个组织他们定义的一个RuntimeSpec就是就容器运行实际标准这个Spec基本上其实就是把RuntimeC的它那些命令行做的事情把它标准化把它定义出来然后我们这儿看到的是最开始的时候是ContinuerD它会创建在上面这个字体可能看不太清ContinuerD会创建一个叫Bundle的东西它里面大概就是会有容器的RouteFS然后还有一个Config这个Config就是Runtime的Config它来描述就是告诉容器的运行时我要怎么去运行这个容器然后这个就是RuntimeC Create这个时候ContinuerD就会调RuntimeC Create这个命令它做的事情就是真正地把容器的UnitProcess起起来这个Process它就会有具有一定的格式就有LimitsStats然后有C Group在这儿然后它在里面包到它的RouteFS它有一个临时的Unit进程跑在那儿然后这个进程在RuntimeC Start的时候这个进程会被UXAC替换成一个大家在容器里真正地Enter Important的进程Runtime Start的时候其实大家的容器就跑起来这个时候所有的容器的操作都可以执行了然后在容器生命中期的下一个的话就是大家要怎么去停止这个容器就是其实在ContinuerD和RuntimeC之间它其实调的那时候RuntimeC Kill这个命令这个命令就是会把一个Single会把一个信号量发给就大家的容器的进程这个容器进程受到这个信号量之后它会退出同时它所谓的Name Space C Group都会被销毁掉但是它整体在House还会有一些资源在那儿比如说Overnummer资源比如说RouteFS还绑得起来的就这些资源它可能还在那儿然后这个时候还有一个清理的操作就是ContinuerD会掉RuntimeC Delete这个命令然后用这个命令来把House上所有资源的给清理掉然后Cata基于这个的时候我们就在Cata最早的版本就做了一个RuntimeC的完全的替代就对ContinuerD来说的话就是看起来就是Cata和RuntimeC没有任何区别它只需要从掉RuntimeC CreateRuntimeC StartRuntimeC KillRuntimeC Delete变成掉Cata RuntimeCreatRuntimeC Start这样的话就是大家在那个年代大家要用Cata的时候其实就是把Runtime如果你甚至可以Hank一点把Cata的命令行把它从命名为Runtime然后把RuntimeC换掉这样都是可以跑起来的所以这是因为当时只有RuntimeC的一个标准RuntimeC就是ContinuerD和容器运行时间唯一的接口所以当时我们就做成这样然后这个就是ContinuerD当时的做法当时它首先还是有个系门叫ContinuerD系门这个系门它通过RuntimeC的RuntimeC Connect Interface去掉各种各样的真正的容器运行时就是刚才提到有RuntimeC然后有Cata然后RuntimeV是我们在Cata之前做的一个项目这个项目后来和Intel的ContinuerD合并成的CataContinuerD所以在那个年代大家都是去模拟RuntimeC的命令行来执行这个然后其实当时已经有一套GRPC的接口但是它是ContinuerD这个进程和ContinuerD系门这个进程之间的一个GRPC的接口然后它到真正的ContinuerD的系门到具体的容器运行时还是一个命令行的接口这个接口当然能work但是实际上就是它很多假设就是大家都是RuntimeC这个时候就很RuntimeC因为不同的运行时其实还是会有一些稀缝的差异这个很难去做一些就真正的能够更native的集成的东西然后它引入了一个最大的问题就是系门的爆炸就当时当时整个社区都在看系门太多的问题其实不只这一层有系门就很多 听完系门都很多但是在这一层的时候我们的问题就很明显就是首先是我们每一个容器都一定要有一个系门就是会有一个ContinuerD的系门每个容器还会有一个Cata的系门然后因为我们不只起个东西我们可能还会CC进去看一看什么东西之类的然后每个CC又会有一个系门又会有一个ContinuerD的系门又会有一个Cata的系门所以我们整个后色上的系门的数量是非常非常多这也造成就是大家在生产上真正的用的时候万一哪个系门出一点问题就各种系门就跑飞的问题就出现了然后这个时候就是整个社区都看到这个问题所以大家就开始想怎么去解决这个所以解决的方案就是我们和ContinuerD社区一起设计了一个叫新V2的API这个API就是它刚才ContinuerD系门ContinuerD和ContinuerD系门之间是JRPC Interface然后ContinuerD系门和容器的运行时之间它其实是Component-line Interface然后我们把这一层也把它换成JRPC的Interface而且把ContinuerD和ContinuerD系门之间的接口把它收拢了一下所以这样我们就可以做到一个价格就是ContinuerD对于一个Port来说一个Port里面可以有很多容器但是一个Port里面可以只有一个ContinuerD的系门然后ContinuerD这个系门然后再来调不同的那个就不同的系门的而且这个ContinuerD因为ContinuerD的价格它的系门它其实它是集成到那个就它系门的Client是集成到ContinuerD的Binary里面所以它后上就只需要有一个ContinuerD然后不同的运行时再去实现自己的新V2的ServerJRPC的Server这样的话通过ContinuerD和JRPC Server之间通过JRPC来交互的时候我们就当然这儿话了一下实际上当时做的时候我们就社区能够看到有三种实现一个是让C做了新V2的实现Kara做了新V2的实现还有Google的那个Givitor也做了一个让C的新V2的实现然后有这种价格这个价格其实它能做这个事情就是把最开始的新V1的就ContinuerD和它的新V2之间的接口把它下沉到了让运行时来实现这样的接口其实新V2的接口是非常非常相信的可能就差异就在这儿就是这个有一个Connect的一个下档就是创建和清理的其他的接口几乎是很类似的它其实是一个JRPC的下沉的过程然后基于这个接口其实我们就做了第一版的Kata的价格的演进就是从最开始的一个Sandbox一个Port可能会有很多各种各样的系目然后我们就把这些系目全都放到一起变成了一个ContinuerDGang 系目Gang Kata V2这样一个进程这样的话就是每一个Sandbox就只有一个系目了这样其实大家很明显这个价格就清爽很多然后后世上的进程不管是大家因为这些系目都是构写的它本身的内存开销也很大然后它各种系目跑费的情况也很多换成这个价格之后其实后世上整体的性能和稳定性都得到很明显的提升然后这就是就可以回顾一下就刚才这个价格的优势就是首先第一个就是它只有一个Port只有一个系目然后而且有更少的构的那个系目的Port是因为当时我们都还是用构来写的然后这些从最开始的就是可以我们看到就是Continuer数量要乘2然后再加Xciter数量乘2还有一个Proxy然后再加一个Vm这个Vm可能是Qm可能是Color High Profile当时然后其实然后我们就把它变成了就是我只需要一个性命价一个Vm然后因为整个整个进程的数量变少所以内存的开销也是大极大的降低了而且我们整个安装部以及都简单的很多而且也没有那些就是性命跑费的问题就几乎没有出现了然后当时我们做了这个时候其实我们当时因为当时和Continuer地社区聊的时候其实我们最希望的是有一个更上层的借口因为我们看就是从Color角度看的话我们其实是把一个虚拟机一个MacroVm当成一个Port的抽象Port Sandbox的抽象来做这个事情所以我们当时是希望有一个Sandbox的抽象在Continuer地里面但在当时Continuer地社区觉得就Color还不是一个主流还不希望不希望在价格上做那么大的改动所以就还是有一个有些Liftover然后这些就是一个问题其中一个就是我们其实还是能看到我在后置上还是至少会有两个进程就一个进程是一个SIM一个进程是一个VMM这些是我们后面要去解的问题然后还有就是因为我们有两个进程其实我们还是有理论上还是有那个状态不匹配的情况就如果是SIM认为VMM还活着让其实VMM已经退掉了或者是VMM或者是VMM还在然后SIM又退掉了其实各种还是会有一些清理的问题在这这些就是我们在下一次的那个价格严谨的时候会去尝试解决的问题然后这个就是我们在3.0刚才提到的那两个问题我们在Color Conditioner3.0去尝试去解决了然后因为在2.0的时候在2.0的时候我们其实除了那个说SIM以外我们还有一个IO的进程我们有支持Vertifest的协议然后有Vertifest有两种实现一个是Vertifest一个是Nedasd其实在HOST上我们还是可能有多个进程而且那个当时的SIM是用构写的内存开销还是挺大然后在3.0的时候我们做了一件事情就是我们用Rust重写的Cata的Round Time这样的话我们同时又引入一个引入捐购报捐购报也是Rust写的这两个进程我们就可以把它合到一起所以我们看在Color Conditioner架构里面我们在HOST把SIM进程和VMM进程也合到一起了这个因为捐购报同时也实现了Vertifest和Nedas的协议所以整个这一套就从刚才的HOST上可能有两个或者三个进程的架构变成了HOST上整体就只有一个一个进程的架构我们再也不会存在就是某一个进程死了然后另外一个进程的机会它还活着这样的情况而且少了这些进程内存的开销也明显就会降低下来然后下面可以我稍后来继续讲一下Sandbox好 那么做了刚刚的技术架构眼镜以后我们其实也慢慢发现就是看它再往前走的话会存在一些跟上游社区的一些问题吧就是说Sandbox这个概念一直都在像我们刚刚最开始介绍接口的时候CRI的接口里面也有很多Sandbox的一些操作但是我们发现它整个接口是有存在一个断层从Cribnities到CRI到肯定是D这边它会说我要runpo Sandbox我要去stoppo Sandbox但是再往下到刚彭涛介绍的Sandv2里面它就变成了start delete它没有任何Sandbox的概念了Sandbox的概念在肯定在CRI到Sandv2那边就出现了一个施争和断裂的情况那么我们也发现虽然Sandbox这个概念如此重要像GivizerCata Container这些他们唯一唯特殊的原因就是因为他们那个Sandbox是特殊的但是在接口层面我们却没有给它一个特别的定义那么这会有什么问题呢就我们发现Ccontainer的操作和Sandbox的操作在Sandv2的接口里面是缠绕在一起的那么像我们Cata这样组建的话就要去从Sandv2它给那些容器语音的东西里面去推测哪些是VM要做哪些是Sandbox要做的可以看一下这样的一个图就是从Ccontainer第一它发了一个Sandv2过来那么对于我们Cata Sandv2来说的话从这个Sandv2的StartDelay的Create的等等里面去推测哪些是Ccontainer要做哪些是我们要给DragonBot这些或者Cumul这些VMVM要做的这个语异本身就是有一个施之的情况在那么这会导致什么问题呢第一个问题就是我们觉得这很容易就发生问题或者说是会让人去写代码也好读代码也好去审视整个流程来说都是会有一些就是比较困惑的那么就比如说我们来说对于同样的一个SIM API的一个命令它可能到Cata这边它在不同情况下它会做不同的操作那比如说Create在最开始的时候我们还是要去Create一个Sandbox去Create一个PostCcontainer那么到中间阶段可能它的意思是说去Create一个Ccontainer就好了那么Delete也是一样的我们Delete要去判断它到底是Delete杀箱中间的一个Ccontainer还是说最后要把整个杀箱去做一个Shoutdown第二个问题是说整个状态因为这个CMV2的接口它只有只是Container的语异它整个状态是缠绕在一起的所以说就像彭涛刚说的我们这些VMN的状态和Container的状态因为这个CMV2接口定义不得不缠绕在一起然后我们在下流的组建就要去解这个缠绕同时每一个下流组建它都要有自己的定义的一个方式你这个CMV2过来我这个Sandbox要做什么操作那么我们也发现就是在云云深圳的一个接口眼睛的里程里面只要有不清晰的地方出现那就有一个机会我们可以去把它定义清晰就像CRR它被定义出来就像O3它被定义出来其实把它定义清齐就是一个架构眼睛上的一个机会于是其实后面Container的地社区就尝试去把这个事情去做得更好那么CRR这边Cruvinities还是用像Rample SandboxStarsPole Sandbox这些下来是Container地道Kata的那个SIM接口这边从原来的Task API又抽离出来了一个Sandbox API专门去做Sandbox相关的操作以此让Sandbox真正的在这一条语言体系里面成为了一个一等公民的一个状态我们可以清晰的知道Sandbox的状态到底是什么它需要做什么它需要改变什么那么我们可以继续往下看就像刚刚那个图原来的话我们只有一个Task interface现在的话我们Container地社区就引入了一个Sandbox interface具体的接口定义也在右边我们有拨出来它就详细的去定义了我们在什么时候要去Create Sandbox什么时候去Start什么时候是去Stop等等这个操作这个特性你在1.7里面Container地道1.7的是一个实验的一个特性那么对于Kata来说的话首先对于像我们刚刚说的Kata 3.0的一个Dragon Ball的一个架构那么它其实我们现在做的就是第一步把这个整个Container的逻辑和Sandbox逻辑做一个Decouple就是把它分解开来那么Sandbox API就我们去做Sandbox的一个服务Task API就做Task API的服务容器做容器的事情杀箱做杀箱的事情让整个逻辑的链路变得很清晰很流畅那么当然我们也在往后想一步就是后面Kata应该怎么发展或者说是Sandbox API能提供给我们怎么样一个机会所以我们也在这个一个改变就是说对于像非Dragon Ball这种架构也就是没有标准到一个进程的架构像Cumul, Cloud, Hypervisor这些他们因为他们没有办法容到Kata的shame里面所以它势必会有一个多余的一个进程那么在后置上就有很多不同的进程那么对于这种情况我们想的想法是把所有的shame能不能收缩到只有一个东西它可以我们这边先理名叫Sandbox让一个结构去管理它因为我们可以看到整个云圆圣这个节点这个链路Cubelet它是一对N去管理Port的Continuity它是一对N去管理的那么像Kata这样一个shame它能做到一对N去管理所以我们现在的现在还是一个实验性的想法就是说Continuity它把Task API和Sandbox API传到我们一个Sandbox的一个结构里面一个后置上的一个单风赛的一个组建里面然后这个单风赛它可以去一对N去处理不同的这样的一个VMPort的一个创建等等如果是Sandbox API的请求它要去做Sandbox杀相的操作如果是Task API的操作它就会走Task API的操作但我们这边Task API还是会经由Sandboxer而不是直接的去到HosGas里的Kata agent原因是因为我们觉得有很多因为我们有一个虚拟机的状态所以Hos和Gas的很多的值或者说它的一些地址等等都是有变化的我们没有办法直接把肯定的逆它得到Task API去做一个直接连到Gas里面所以说我们这边还是全部要经Sandboxer还有一点要提的是我们这边也在提我们也在提就是把容次的Io通过一个FD-based一个VSock直接转发出来然后看可不可以给上游社区直接跟肯定的地址或者说更上游直接去对接这么做的原因就是说我们这样的Io就可以不用去走像Sandboxer或者说类似Same上的一个Hos的进程那么对于Sandboxer来说它就可以自由的去做更新去做替换去做热升级等等这样可能的操作而不用担心它的Io流是被打断的那么这个架构也是我们在实验和探索架构它的特点就是首先我们想尝试把Same的数量尽可能降低第二个我们尝试想构建一个1比N的一个Sandboxer进程和Po的一个模型最后我们想做就是让Io流直接通过一个FD-based VSOC往上去做转发而不经由Same或Sandboxer那么Sandbox API对于这个业界有什么样的一个好处和提升我们认为有这么几点第一点Sandbox它终于可以成为一个一等公民的形态存在在整个容器生态里了那么说我们就再也不会下面的不同的不同的continental runtime有缠绕在一起的和Sandbox逻辑的一切都会变得更加清晰和易懂第二个的话通过这个Sandbox API我们理解了这个Sandbox行为以后我们就可以去尝试像把这些Pose container等等这些原来在Cata里面可能有点此怪逻辑看能不能就是做一个经检和去掉了最后的话像我们刚刚想尝试做一个1比N的这样的一个形态的话其实它就是对整个内存开销也好和启动速度也好都有个比较大的提升最后的话就是我们推出这Cata3和DragonBot这个一体化的一个架构和对比Cata2加Q的这个架构可以看到因为我们首先是用了DragonBot这样一个清亮几则Building的一个Rust写的一个VMM同时我们又是把整个进程做了一体化可以看到它整次一个启动速度相比Cata2加Q是快了两倍然后整个内存占用是清了1.8倍以上就是我们想讲的所有的关于Continue和CataContinue接口眼镜的故事这边最后也做一个小小总结我们今天其实就首先以小见大从小的一个接口眼镜大家看了一下Continue和Cata从CV1到CV2再到现在社区正在活热进行的Sandbox API它的一整个架构眼镜它对于Continue的地带的影响和对CataContinue架构上带来的影响最后呢其实也是通过这个小的例子想大家看一下在整个云元身的容器的一个图谱里面接口这样一个常常被大家所忽视的东西其实它有大大的一个魔力它能引发整个架构上的眼镜和每一个容器它的一个生态位上的一个定义对所以说也像最后这句话想说的就是说这样一个小小的接口眼镜其实它也就见证了这个云元身容器的一个眼镜那么最最后其实我们有一个小彩蛋小彩蛋就是我们要做一个很恐怖的事情就是我们要现场跑一个demo我们要真正的Live Demo对我们会跑一个CataContinue 3.0就是Dragon Ball架构然后去用我们已经提出来PR的Sunbox API去跑一个简单那个Basic Box容器所以眼镜呢我们这完全是现场演示所以很湿如果网络不好就有问题我们先会登到这个机器上然后OK 先看一下CataContinue的配置我们是打开了那个Sunbox模式Sunbox API模式也可以看到在社区这边你就是用这个Sunbox Mode等于Same你就可以打开这个Sunbox API模式然后在这之后用CataD创建这些POD它都是用Sunbox API来走的然后就是对然后就是我们Sunbox的一个定义的这个JSON文件还有就是Continue定义的JSON文件都比较比较整单之后说我们用了这个Gun RCata就是让CataCtrl去走Cata的Runtime而不是走RuntimeRuntime这儿已经创建出来了现在这个容器应该就居然是Running的然后现在就创建出来一个Cata的一个安全容器了用的是Sunbox API的一个创建的方式然后也可以看到我们跑到这个容器里面去执行的这个Uname Gun R就是它OS的一个系统是5.10这也是我们Gas Kernel的一个系统然后现在下一个Uname Gun R就是我们在Hose上执行的是4.19就可以看到安全容器这样应该有一个虚拟Micro VM的形态所以它的Gas和Hose是有不同的这个OS的一个版本的这个是我们想展示的是对于像Cata 3.0Building Dragon Ball的形态整个Cata你创建出来就是一个进程没有别的进程了就是这样一个ContentD SIM Cata V2我们把所有的那些分散的抽离的那些组件都容到这一个进程里面去大大加强它的一个效率还有它的一个资源开销等等对 这个可以看到就是这个是Cata SIM的PID然后我们去把那个进程列表可以看到这个SIM同时也是它是连到那个内核的KVM的现成的所以就是这个可以看到就是Cata的SIM同时它也是VM这个是我们可以展现出它是融合到一起的一个点DEMO很简单就是这样好 DEMO成功了没有挂这个就是我们今天主要的一个想要跟大家分享的内容了然后谢谢大家如果有什么问题我们也可以处理那边有一位同学你好我看到你们提出了后来提出一个SANDBOXER的构想然后这样的话其实调链路是相当于一个CoupletCouplet的顿一个Continued D然后再顿一个Sandboxer那你们有没有想法直接把这个Continued D给替换掉呢其实不需要替换Continued DContinued D是允许做Plugging的大家在BuildSandboxer的时候其实可以把Continued D和SandboxerBuild到一起并不是替换Continued D这个和Continued D就是你可以把它分开分成两个进程你可以把它分成两个进程然后就Continued D你就用上游的Continued D然后Cata的新Sandboxer就是Cata的Sandboxer你也可以选择把Continued DBuild到Sandboxer里面因为Continued D是允许昨天我们和福尔也聊过它是允许这样一种Plugging的形式把整个Continued D到其他的Bandroid里面去的好的 谢谢喂 就是Sandboxer那块其实刚才看到就是说它Task API还是会往Sandboxer调但这块我觉得可能语异上面是不是会有点问题因为你Sandboxer你既然那个名字叫Sandboxer你是不是应该是做Sandboxer管理的东西那它如果可能地的Task API也往这里调的话是不是就有点因为就是这样就是我们只是把它叫Sandboxer最后的话它肯定会叫一个Catashim如果对命名上有意见我觉得都可以商量因为它最后肯定会叫Catashim它不会叫一个Sandboxer对 我不知道就是那个我觉得那个无常那边应该很清楚就是我们那边其实也有一个想法就是说那个Sandboxer它Sandbox本身我给它一个定义就是说你必须得提供这个Task API然后这个Task API可能地其实是可以直接调过来的其实这里面要解决的问题其实就是比如说像Catashim这种场景下面它其实就是虚机内外资源的一个一个硬射关系其实就是这么一个小事情我觉得这个事情其实Sandbox本身也可以做掉的这个也是我们那个刚才你们也觉得Kreuzer那个例子我们开源Kreuzer想做这个事情对因为我们是是想希望就在Catashim把这些就是Sandbox实现的细节完整地把它屏蔽掉不希望把这个东西再往containercontainer地去暴露所以我们希望就是通过Task API现在是什么样子就还是什么样子不希望去改Task API希望Task API直接下来至于Taskcontainer那些resource的硬射我们希望就是由Cata这边来把它负责掉整个事物就是不把这些本身Cata内部的一些设计的细节把它暴露给container地有问题艾峰头我问个问题就是还是接着上面那个Task API那个问题那Task API我们为什么不放在刹箱里边呢你是说直接从container地直接从Sandbox放在刹箱里边的就是跟不是跟那个CataAgent的合作一起因为container地看到的Task就比如说container一个resource的路径和在Gas里面看到resource的路径这个是指示一点就是RouteFS的东西其实所有的资源相关的东西RouteFS,Volume,Device这些东西container地看到的视角和在Gas里面的CataAgent看到的视角是完全不一样的这个是需要有一层Cata在外面有一层逻辑把它给做一个替换硬射的又是Cata新闻在做的事情我明白这个转换必须要放在外面吗因为在Gas里面你是不知道外面的东西这个转换能不能放在Standboxer去做就是在Standboxer我知道但是Task都是在里面去做那这样的话就涉及到container地要先调Standboxer做一支转换把Task的swackedrequested swag的转换调Standboxer转换一次然后再调Task API到Gas里面去但是我们觉得这样的话会引起container地的更大的误解container地希望我有一个Task的Client然后你给我一个Task的server让我发给你你就不要告诉我我还要去做一些什么资源硬射的转换这些东西看看大家还有什么问题吗如果没有的话那就今天就感谢大家来到我们的演讲谢谢谢谢