Hello 大家好 我叫唐天仪是来自阿里云容器服务的然后今天先给大家分享一下就是我们在阿里云容器服务使用肯天仪在一些超大规模的集讯中的过程中遇到过一些打斜的问题遇到过一些生产中哪些的比较难解的情况然后我们是如何利用肯天仪的插件机制并且在肯天仪内部做了一些调整和优化来解达这些问题OK 今天我们日程大概是这样的首先先为大家介绍一下我们的业务场景是什么样的我们面临的是什么样的业务集群是什么样的集群集群规模大量是什么样那么这会导致我们遇到什么样的业务问题这是第一部分然后在这些问题中我们可能会更聚焦于两点就是第二点和第三点在次盘管理中和经向管理中我们遇到过哪些挑战吧就是因为业务特性和不一样的业务特性他们带来的问题我们是怎么用可能的机制解决业决挑战的第二点 第三点我们的今天的重点然后最后可能会在留在一些Q&A session因为中间可能会有些很有问题的部分OK 首先我们是完全基于KBIS生态搭建的一套完整的集群在我们集群很小的时候其实就开始用Continue D了在最早的时候可能还是Docker时代的时候Continue D从0.2开始我们就自然的炮尸然后上面用炮尸来对接CRContinue D做运行时从0.2到后来帮不到1.0然后再到后面帮不到1.2然后直到Continue D release到1.25之后它内置了CR的差价我们完全遗弃了炮尸采用了Continue D做我们唯一的运行时再到现在社区发展到1.6或1.7我们选择了这个Long term release的1.6来做我们的稳定运行时就可能已经走过了一个很长的时间在这过程中的话我们的集群也逐渐变大现在已经变成是一个万级集团的集群了那么在这么大的场景下并且是个混布的场景业务就会有各种各样的形态当形态一多了它们对于磁盘的对于镜像的对于启动时间的诉求就会变得多样化比如有些业务它就用的是一些很L密集型的业务它们就会打很高的L请求当这种L请求和一些很大进向的客户通在一起的时候它们对于这块盘的L压力就会立刻吃满就会互相影响那这个问题我们要怎么解决那再或者就是说有一些业务说我就是镜像特别大但是我还喜欢我泡的可以秒击拉起几百个泡的那这种时候当它不在一个级点上我们不能准确地去预热这个镜像或者是在级点给它准备好一些东西的时候我们要怎么办这种诸如此类的挑战都是对于刚刚我说的那两个点磁盘管理和镜像管理带来的问题OK 首先我们先聚焦磁盘管理再说磁盘管理之前得不得不先大家先walk through一下就是contact D内部对于一个镜像是怎么prepare的或者说是一个镜像从仓库来了之后它是怎么变成一个容器内部可以使用的一个Root FS的可大家可以跟我一个图来今天我们的镜像和磁盘都会跟着这个图的脉络来走绕着它来做事情首先大家知道就是一个OCI镜像或者是一个更老的Dopper镜像它是分层的它有很多的layer你在构建镜像的时候构建出很多layer它会一层一层被打成一些最常见就是target z打成一个target z文件被推到仓库上去不管仓库是ACR或者是一个自建的harbor或者是一些其他镜像仓库那么从第一步我们当然是要从远端把这个镜像拿下来拿到本地之后会被存在一个地方这个地方在content地中就叫做content storecontent地中很多这样的storecontent是其中一个所谓的contentcontent这个content就是从仓库拿到的纯数据它被叫做content拿到啥就是啥但是很多种像图上能看到有manifest list有manifest还有config还有一些blop那其实在这里边上边那三种都是原数据它们很小它们不占什么空间它们描述的就是说镜像的属性镜像大小我启动镜像需要用什么user镜像要做什么volume mount就一些原信息而实际真正占空间的大象是下面那个blop也就是那个tarGZ那么一层一层的blop占了这个贴满了content store那么下一步我们干嘛呢有一个压缩文件了下不就要去apply它所谓的apply行为这个往简单的说其实就是下面咱们看一个方法unpack就是做了个unpack的行为就是做了个tarxdf把它挤压出来了把一个tarGZ变成了一个可以读的一个裸文件了那么在这个过程中我们需要做大概就是这么三步走大家可以看到又出了一个新的概念是啥呢snapshotsnapshot分两种有active snapshot和commit snapshot叫的名字很牛吧对吧然后跟那块看就有这个commit的还有点接近但是其实这个所谓的active commit就是只读和读写说白了就是做了三件事第一件事准备了一个空的可以读写的一个snapshot这么一个快招的空间然后把前面我们拿到那个content给它挤压出来挤压到这个可以读写的空文件中去再把这个已经添码了的snapshotcommit成一个指读的snapshotok 那这样每一层我们都这样处理过之后这样一个完整的镜像从仓库就变成一个指读的本地镜像了这样就到了最终每一层都会被添到这个snapshot store里面去那当然刚刚我说的比较浅浅的方式是基于只有tarGZ和只有tarGZ只有tarGZ和只有裸文件数据的行为但是对于apply来说它不止是这样的行为它说白了不是在不止是在做解压它做的更多事是把从仓库获取消的信息变成一个本地可以被用来mount作为其中一个base layer的信息那这个原始信息它不一定是tarGZ也有可能是一个tar也有可能是一个裸数据也有可能是一个加密镜像 加密过的数据那么对于这些数据的处理的行为都是在apply这部分这部分都做的而得益于可能是地理查件机制这个apply实际执行apply的applier它是可以被查件化的所以我们可以给它更多的可配置的空间可以说我不动可能是这原代码还能去上面做拓展等一下我们就讲说我们在这里做什么拓展然后刚我说那个是apply的源头apply的出口这个snapshot也不一定是一个裸的文件也不一定是一个你直接登到速度机上去看就能看到文件的空间它可能是一个诶它可能是一个tar它可能就只是一个tar但我只要能mount这个tar能呈现出一个最终的mount结构那其实就可以了我们真正car的不是这个commit的snapshot里面到底是不是裸文件所以它会有更多种多样的snapshot像是现在社区比较火的一些按需什么东西它其实成熟的数据都不是裸的文件系统but anyway就是这个apply是一个比较宽泛的概念那么现在我们已经有了一些纸独的snapshot的snapshot store里面了下一步就是要准备这样一个再准备一个空的独写的snapshot这个snapshot最终会变成你在容器中的入台白色所有的血iO会打到这个上面去这个snapshot加上我们刚刚就是这个容器中的那个镜像那些独的snapshot被mount到一起变成了一个入台白色的仕途那这样我们就完成了一个完整的一个从一个镜像到一个容器可以使用的根部录的生命周期了那这个我们刚刚讲的列录是最基本的这个mount的可能就是overlay fs嘛这些层能mount到一起一个overlay的挂载然后之后写行为都打到overlay的upper层那这样就有一个问题了大家看这张图就这个是把刚刚那个snapshot store展开了假设我们有一个镜像就是一个镜像比如说这个镜像是个sandbox这是个sandbox镜像有很多嘛 对吧那么就每一个sandbox都会有一个sandbox的独写层就呈现出大概这样一个仕途但这样的问题是什么这样的问题是你去mount这个目录的时候你发现它挂在一块盘上它最终实际挂到的还是一个后端设备不管是个什么设备它是中规是一块设备因为可能它是地管理的根部录是一致的那么假设说我其中一个人说我这个人疯狂地往里写湿满了这块盘那么它就会影响到别人的行为甚至会影响到镜像的下载行为就往这块添的时候添不上了因为已经被别人吃满了或者说想往这个容器写的时候写已经被它写满了就很难受这样就会出现租户间的互相影响一个人的行为或者说两个不相关的泡的一个泡的行为会影响另一个泡的那这个行为是我们不想看到的我们怎么把这个空间给它限制住虽然它们在一块盘上但是我希望说我两个容器的读写中它们不要互相争响这个空间至少说我给你们每个人来个上限对吧你一个人我不至于说单点打包我不至于说某一个人会把我整个几点打挂了OK 我们出了这样一个方案就是我们在准备这个科写层的时候就是准备刚刚咱看到那个图里面容器那个最终实际写行为打到那个目录的时候先给它创建一个spare file创建这么一个西数文件然后它是给它设了一个上限的当然我们还考虑过其他方案像project quota之类的但是这种因为钱交就比较多所以说最终选择了spare file准备这么一个spare file之后呢通过一个loop设备作为转换把它最终挂到了这样的一个空的目录里边去但最终实际写行为还会打到后边那个spare file那么它最终是会被限制住的这样每个容器我们都这样准备那么这个spare file的大小它是赶着跑 赶着跑 赶着创的嘛创容器的时候准备这样一个spare file这是由我们的还是德玉刚刚说的差价机制我们的外置snapshot做掉了那么它是由每个pod可以指定说我来的时候我要多大空间我告诉你多大OK 我创这么大spare file挂给你你这个容器那也不管你怎么写不管你玩命写你写不超这个spare file设了这么一个上限而这又可以由上层的管控来去给它加写可以把svm 护盖之类的东西给它注入这个标这样就可以保证它不会超了好 那现在我们已经做到了说空间上他们每个人不会打爆了但这样还有问题为啥呢因为他们中规还是在一块盘上还是在一块盘上by the way这个东西社区已经有一套三号完整的解法了shout out to DerekDerek已经有了这样一个blogsnapshotter你可以自己稍微再调整一下就是当前社区release版本的contentd稍微进行调整就可以使用了但是这样的问题就是你去FindMount它还是在一块盘上你虽然空间给它隔开了每个容器不会把它整个打爆了但其实你的所有lps和bps还是在共享的你刚刚在聊的问题我刚刚说的客户的问题某一个人比如我下了一个100G的镜像就算你盘够大我下得太快了可能是下得太快了导致说另一个容器里边的读写的行为我反而有写得特别慢我是能写进去的我写特别慢或者是两个容器一个人在疯狂的读写疯狂的读写把lps迟满了导致另一个人的行为受影响这样还是会出现足够简单的影响那怎么办呢那我们就想到了说OK其实用户在容器内能碰到的只有这么一个地方只有这么一个读写层镜像它碰不到它对镜像只有读写读写球那是不是说我们把所有用户能碰到的空间给它隔离开对吧我们不要让这个用户的行为能影响到一些管控策也就是镜像数据的下载非常理所当然我们想到这样一个方式我们把他们的读写层给他们摘出来对吧摘到独立的一个空间这样不让它的空间和镜像的下载互相影响你在每个容器内你可以做你的读写行为我空间刚已经有限制了那个路不发号嘛那个spare style嘛已经限制了那空间限制好了之后现在这样隔开之后LPS就先开了LPS你读写的LPS对你的镜像的LPS是不会有关系的最后在几点上是两块盘这样的话我们承认的仕途就是这样一个三个框嘛几点上会有三块盘一块根盘保证输入机的运行它不会被影响因为用户的空间不会影响这块空间一块是读写盘是所有POD的读写行为会打到这块盘上去一块是读写盘它只会影响形象只会存形象用户的行为也不会对这个里边有更多的天写的操作它只会有读操作读到也有可能会被吃满那这个是没有办法避免的因为数据大了读就大了这控制不了它那但是做这个事还是比较困难的我们在实际过程中还是比较困难为啥呢还要回到刚刚这个图上去大家看到有红框这块没其实这也是个snap shot的这也是个snap shot他们都是一个空的读空的可以读写的snap shot那么对我们来说最大的难点就是如何在不hackcontent-d的情况下去区分出我到底是在准备一个镜像的层还是在准备一个最终给容器用来使用的层那这个随着content-d社区的发展中规它是给了这样一个能力就是可以把这个label透传过去你泡得上的annotation会被透传给snap shot我们就可以通过外置插件的snap shot来判断说我这次创建某一个active snap shot的时候我到底是在启容器还是在下镜像因为启容器的时候会有一些额外的annotation过来这个是肯定是社区能力提供了那就很好了现在我就知道我什么时候在创这个指读层什么时候创这个读写层什么时候在创这个镜像层了那现在我们就可以给它拆分成这样故事讲通了这样就可以有完成的三块发了那到这儿是我们在存储这一块做的lps和这个空间的限制在这之后容器空间已经被限制住了但是还有个问题是什么呢就是容器启动还是慢刚刚咱说了嘛有一些突发性实力有一些容器对启动时间要求我镜像特别大我还是希望我启动得特别快那怎么办你就不得不聊到下一个事了就是镜像这中国也绕不开的事镜像在我们实际生产体验过程中它一直是占据了容器启动时间的一个大块那怎么办镜像下载不管是社区还是我们生产过程中遇到的客户问题普遍都在断一个事就是怎么加速镜像下载怎么下得更快我这镜像怎么能更快拉下来我能不能镜像越热我能不能更快把这个镜像获取下来但其实我觉得大家真正关心的不是这个事大家真正关心的事是我能不能怎么能更快把我容器拉下来你镜像快不快跟我没关系对吧你镜像能下来下不来我容器能起来就可以了镜像数据只要我能拿到我学校的数据我在我容器镜像在跑的时候它能正常地运行你镜像下得慢跟我没有任何影响OK那我们就回过头来看在这整个从一个镜像到一个容器的读写层的生命中期中哪儿是我们能做一些事的对吧就走了很长的链路那这长链路中我们哪儿能做得更好这在apply的时候因为这是可以插件话的它可以它是可能地提供插要机制的空间我们能不能做一些事情在这个时候我们就发现了那盒中一个文件系统它恰好比较契合叫做ELFS它是一个enhanced read-only file system它这个有个关键词我框出来了就是read-only大家有没有感觉到什么事情它和镜像非常的一致我们的镜像就是read-only的那么对我们一个read-only的镜像和一个read-only file system感觉就非常的契合那我们就开始寻找角度怎么能把这个file system的能力引用到我们的镜像中file system有两个比较关键的事一个是它是支持了随机解开对它的随机读现在说你一个tart不用解开你就可以读的了这就是我们需要的另一块就是加密解密的数据这块其实我们也需要但对时间听上不是那么重要OK那么回到这个图上在apply这一步的时候我们就可以尝试说能不能把这刚咱看到enhanced read-only file system结合到我们的镜像在解压过程中原来我们可能是从一个pargz解压成一个蠢的裸出去文件现在加上这个file system能不能变一下于是就可以就是我刚说的那个故事我们源头是一个pargz输出是一个readfs这怎么需要全部信息了那么我们就可以三号这样做原来在解压的时候我们是准备了一个空空路往里去解压这个pargz先去gzip.ind再去把它评铺开然后得到了一个裸的文件然后拿着文件去overlay挂到一起这是原来的链路那现在我们有了这样一个enhanced read-only file system了它可以它不需要去解压这个pargz了那我们这块是不是就可以省掉去评铺掉pargz的时间instap我们去生成一个erfs的indexing这个indexing比起pargz来说是非常省时的那么我们就可以在这个原来的unpacking的流程可能是地内部不去做任何的改变不去做任何社区去代码的改动只是说外置加两个plugin因为可能是提供了比较完整的plugin生态我们可以做一个pargzsnaprotor和一个pargzplier那么在准备snaprotor的时候我准备一个符合这个file system格式的一个文件然后在做pargzsnaprotor的时候instap of去做pargz的解压我们去生成这样一个erfs的索引这个总时间我们就可以把tar解压那部分的大头时间完全省掉最终实际我们的文件就只有一个tar文件和一个erfs的索引然后这是对应的是某一个层的snaprotor然后最终这些层snaprotor和之前一样和overlay非常类似它还是被和一个空的层揉到了一起通过了一个mount命令呈现出了一个统一的routefx试图那么之后我们的读写行为可能最终还是打到snaprotor里面去因为最终那个两层在出现这个mount之后下面那个mount在这个mount之后它们两个挂到一起我们仍然是用overlayfs的因为这里没有任何的耗水已经有一个目录了只是给一个空目录它也挂到一起把所有的读写行为打到这里这个overlay没有任何损耗可以继承只是这我们实际版选省掉了那么最终成立的试图是没有变化的用户的使用体验也没有任何的区别唯一的区别就是最终这个文件你在输入期间你是不能直接看到的因为你看到里面的每一层是indexing里面的每一层是indexing它需要中间转一个loop设备提供给overlayfs那盒它也去bundit根据你实际IoL请求过来的时候你到底访问的是它的哪块数据它再去bundit随机的找你要找那块数据给你读出来因为它在审源里它就一块一块拼一起的所以这块就是我们的能力这部分能力在内部我们它已经上线已经落地了已经使用了一段时间了然后后面因为这个文件系统是一个内部文件系统然后每天那也是在我们阿里云的所以说之后会想办法把这个能力推到设计区看能不能变成一个buling的snapshot然后大家都能不能使用吧因为它对仓库没有任何的邀请就聊到了下一块了就是按虚加载这个非常火的一个话题按虚加载刚刚为什么可以强调一下对仓库没有要求呢其实按虚加载来说的话它比刚刚我说的那个方案还要快因为刚刚说的方案你仍然需要下载经常所有的数据只是跳过了本地去解压Tar这一个流程但是刚刚那个方案对仓库没有任何要求仓库就是原来的OCR镜像你用过的仓库不用感觉原来是harbor就是harborharbor的方法是啥就是啥不需要重新构建但是不管是哪一种按虚加载现在是名人火的ECRGZ Overlay BDSOCI或者Genetus它虽然有一些是基于GCP indexing做的但是它们仍然需要通过推卸额外的东西嘛可能不需要对原来镜像格式进行找但是原来推卸额外的东西那对我们来说当然这也是有意义的因为它会让我们的整体速度会快太多了像我们刚刚说的那种case一个用户想一个100G的镜像想立刻就起来用刚刚那个方案绝对是起不来的但用按虚镜像可以起来当然起来的前提条件它仓库可能要进行一些转换或者需要推一些像SOCI的indexing可能需要先构建这个事但是实际使用体验是好的我们可以强一些策略来做这个事不过就我只能说当前按虚镜像和刚刚我说的那个tarfs它们两个都有意义那在都有意义的情况下我们就选择都使用我们就有一些情况我们可能是为了稳定性使用原来的overlay fs有一些情况我们使用tarfs有一些情况我们使用按虚镜像那在这种各种各样都有诉求的时候我们怎么才能让一个节点上不需要更多的成本不需要更多的运萎成本然后可以同时跑三个snapshooter这是非常困难的因为原生逻辑上你就是不能you just can't一个节点上你只能用那个启动的时候规定一种方式来启动一个snapshooter我启动的时候是overlay就是overlay启动的时候是exrgz就是exrgz它不能变了你变的时候除非重启一下可能重新再变一下然后把原生逻辑全都改它不能同时管理两个那这块我们觉得是有这个诉求所以说我们又深入看了一下发现没道理因为像我图中看到的你直接拿cd去跑一个ctrplugin能看到说有很多的差价像是btrfs像devicemapper像overlayfs native他们都其实被加载了他们也是ready的cd的差价机制是允许了这个行为存在的那是谁拦住了它呢那其实是在ctrd和kbs中间还有一层CRI是1.5的时候CRIG的主线那在CRI里面它是没有去识别这种多snapshooter的情况对它来说它就会摸上一种snapshooter那这个时候就不得不去做一些增强能力了我们在ctrd内部就是CRI这一层做了一些调整做了一些增强让CRI可以识别多种snapshooter并且可以让你的pod在启动的时候通过你的label或者annotation来选择我想用那种snapshooter那这个事不一定要用户认识你可以通过外户或者这些东西给它包装掉但是这个能力也在尝试往社区推但是现在最大的阻碍是什么呢这个问题其实我们内部也没有也没有太解决掉但是是一个思路吧因为对kbs来说它是需要认识镜像的想象你需要cobelite过来找运行师问说一个镜像有没有被解压运行师该怎么回答它吗当你支持了多个snapshooter之后你到底要回答它你是用哪个snapshooter再被解压cobelite来问你的时候你不知道怎么回答的这是现在最大的问题就不知道怎么告诉这个事所以现在还在社区讨论这个事情不知道最后的会怎么发展不过我认为这个最终还会有一些解决方案的我们也会持续地跟进OK然后so much for lazy pooling下一块就是可能描述一下第二块吧刚刚咱聊那个大图一个全链路刚刚我们focus在apply的过程中在解压那个过程中今天我们再来看一下前面那块从镜像获取数据那一块我们能不能让它变快一点从仓库拉下来的过程中从仓库添冲cobelite Store现在要走完整网络链路每一次的请求你的健全请求你的数据流都需要打捞镜像仓库这个镜像仓库不管是你在机讯中的某一个其他的harbor还是说是一个远端的一个云上章提供的仓库它都要花很久内容都很长那怎么办呢shout out to Derek againthanks to Derek他突然就开发了这么个transfer service刚刚有一个cognitive session也在聊这个事他把一切的行为都抽象一切镜像数据的行为抽象化了出来成数据的transfer那这样就给了我们很多空间了我们可以思考了说原来的transfer是从registry到content store的transfer那为什么只能这样为什么不能是从我本地从本地transfer到content store一或者是从某一个另一个节点的content storetransfer到这个节点的content store这样的话这路是不是短了比如说我同一个机讯中两个node我这两个node之间可以互相transfer他们的镜像数据相当于就是说我一个镜像下载下来之后在这个节点有了那么另一个节点就是可以从这个pair来获取这部分的镜像数据他们可以directly transfer了他们不需要再去仿人仓库了可能只需要仿人仓库做一个健全那这就是我们的思路我们现在做的方案就是相当于是我们叫做imgtransfer一个机讯中的content地门会构建一张p2p网络在第一次重按键机讯的时候它会先把自己通过kbs的能力broadcast给这个机讯中所有的节点他们自己再跟走neighboring的p2p协议然后这样构建网络之后每次拉镜像的时候会先去QoE这个仓库看一下仓库是不是能告诉我我要的是哪个digest因为对镜像来说每个层digest唯一的OK 那我再去问我这个p2p网络的neighboring谁有这个digest如果有我就会找到neighboring拉如果没有 我再说forbind都找仓库这样的话在我们的场景中从实际看到的现象来看大大减少了仓库的压力这是第一个第二个就是假设仓库挂了的时候我仍然能三不耗让我这个机讯能运行起来如果正常情况下你一个仓库挂了你就在你肯定起不来了嘛 对吧你找这仓库拉所有的镜像都起不来了你所有的pods都会卡在continuous creating因为它拉不到pods或者一直在imagerable backoff就是the backoff backoff但是现在我可以保证你说在我这个机群中已知的这个tag比如说我去拉一个santos modelatest我能做到的是在这个机群中我已知的santos latest是什么manifest我就用哪个manifest跟你启动这样能把pods至少先起来那么在然后在起来这个pods之后我会继续pull假设是仓库失败了之后的某一次你就会继续pull这个仓库那当仓库成功了之后我会update这个镜像直到latest应该是那个tag因为这次寝球之前是来过的会对比较time stamp看它是不是来过那么来保证说下一次起镜像的时候用的就是可能仓库更新的一个latest那就会用仓库latest来起下一个镜像这套协议我们现在还比较比较质嫩吧就只能说pods跑通了但是还需要更多的时间来锤炼但是中国的计划也还是把这套东西也能推到社区供大家使用因为毕竟这个东西它是内置在肯定的地里边我觉得是最合适的一种P2P的方式它不需要外置的任何cash它可能网络电路可以去优化但是这些都是可以去做的优化增强但是从机制上来说它内置在肯定的地里面肯定是最好的OK 最后就是这个img.gc的事情之前看到社区有一个人在关心这个事直到今天我们Coupcom之前的几周吧Shuttle the Derek for a third timeDerek终于把这个经向gc的能力给合进去了就可以通过像以前去gc一个contentgc snap shot一样去gc一个镜像了就是之前是通过list来控制的一个list可能可能会过期现在这个过期时间可以对经向控制了那么这就允许我们说在以此值上构建一些更复杂的策略了我们会构建一些白名单策略构建一些超时时间策略构建一些最多重视策略构建一些TTR策略经向最多活动节制或者是密内置策略那这些策略都是我们可以在插件中自己去优化这个插件不影响肯定对主代码的情况下来去分布它的gc plug-inOKThat's itThank you everyone有什么问题吗哎 你好有要求它是要5.10以上哦 这个是这样的它这个transverse service还在发展中它发展的中态肯定是让所有的拉进向推进向的和经向解压的行为都变成transverse service的使用者但是当前的状态然后pulling还是pullingpushing还是pulling它没有叫用transverse service当前的当前它还是在一个外置但是它的Derek和社区都在努力说让这个transverse service变成一个内置变成一个至少内置的所有推行为都变成是走transverse service的对 它就是feature它就是featureOK大家还有问题吗哎 很好很好的问题这个问题我们当时也考虑过就是因为这个策略就是比较毕竟完成一套P2P嘛策略比较复杂我们当前采用的策略就是纯按P2P跑到内部的内部的远近程度纯按内部的latency和实际转捉了那个网络的内部的远近程度来去判断说找谁先去curry然后再去找谁后curry不会暂时不会说根据那个接待IO反防程度来去做一些策略但我觉得这个是需要做的这个思路我觉得也是对我们也考虑过但是这个策略比较复杂吧因为它实际上冒的数据也要比较多实际上不能只上冒进向数据还要当前来要请求那这个实效性不是那么的好保证但是是对的 好问题你好我们这边把那个紫毒层还有可写层它分成两个盘VDP和VC这种情况就是隔离了那个农器可写层对可能肯定是第一对它本身的一个那些紫毒层和目的影响但是我们有没有考虑过就是对这些可写层去做一些IO限制内就是我理解这农器之间它们的可写层还在一个盘上面是不是还是会有一些影响比如说农器它停止的时候可能会做一些amount操作amount操作的话是不是就会我理解目能的话它会把那个可写层的那个刺法上面的所有张数据都回写出去回写出去对可能还是会有一些影响这方面是我们这方面方案是有办法解决吗这个也是很好的问题这也是我们现在做的方向就是我们现在做的方向就是说因为有secure v2的有了secure v2它有了更就是v1的时候可能它的block IO只能限制direct IOv2的话它能把buffer IO也cover到了那我们现在正在探索的就是说怎么用这个v2的能力来做到你刚刚说这个这个是当然最理想的素秀就是每个容器之间互相没有关系那怎么做这个事也是个还在探索但我觉得肯定是需要做的就像你刚说的那个现象那个画面一个容器写了很多或者它在下线的时候做了Mount Ipsync了然后吃了很多突然出了很多IO影响到了其他节点虽然图业存在一个反应还是会互相当然它们的IO还会互相影响我们现在只保证了可能空间不被互相影响这是第一第二我们保证了说它们的读写型的IO不会被镜像下载的IO影响这是第二我们现在保证了第三点它们之间的IO无非影响也是需要被保证的但是这个能力还在开发中但是你说这个方向是对的我们现在思考方向就是通过VR的能力因为VR可以把Block IO和VRIO都线住对 这就是对 那个它这就是ERFS的能力就是刚说在解R的时候要声称一份index不是TAR原生支持的indexing是ERFS提供的一个indexing相当于是在TAR文件前面加了一个Header这Header是给ERFS这个File System就相当于我一个文件搞出了Galaxy出来这个File System你去翻码它看到就是ERFS然后你的毒性球打过去的时候它会根据它自己Header记录的TRI来去找到对应的那块TAR就这个indexing不是TAR本身提供的是ERFS提供的但是如果听见你这个Header吗不需要就是这个是sorry I'm gonna go back for one second就是在这里就是原来镜像在解R的时候去TARGZ做解压嘛 对吧但现在我们不去做TARGZ了我们现在在在这儿去准备好一个空城Filling Data的时候我们Filling的不只是文件解压出来的Data还有去通过Applier生成的一份这个ERFS的indexing这个时间经过我们的压涩后它总时间仍然是把这个TAR完成的铺开有小很多的就这个生成indexing是在是在下载的时候对 不是在构建的时候做的你好 后面那个同学我看到就是说你们用那个西数文件去做容量隔离嘛 对吧它这个本身对这个IO的性能有多少影响就是因为你这加了这样一层又往Loop device加了这么一个绕了一层还好我们试过就是比较极限的场景和比较高密的场景挂一个Loop然后后面更新的文件还好不会有很大的影响的就是那个相当于横向和纵向我们都去尝试压滚从表现上来看还可以的你好 后面那个同学我同样还想问一个SPA-SPA的问题这个会对调度带来什么负面的影响吗比如说它实际的可容空间其实是大于它占用的空间的您稍微再拿一下您是指什么的空间大于它的占用空间就是比如说KVS的调度器它需要感知本地此谈的可容空间然后去调度破的然后SPA-SPA它其实能看到的它占用的空间是比较大的这样的话会对调度带来一些负面影响吗还说你们会去感知它实际的用量这个如果说就是那个它看得比较大那这也应该算是酷酷的Bug因为就是假设你一个SPA-SPA它是占了这么多空间但你仍然能看到它实际使用大小就是现在你计算实际使用大小的时候不要按照它去provision出那个空间来算而是按照它实际使用的空间来算这样就可以了目前这个空间和LPS调度不识别调度是不会说它不会上报不会识别因为这个事它比较复杂它会让整个调度系统就是它的账本很会计乱一个账本会计乱一个是根据节点上因为节点上除了容器本身之外还有镜像数据虽然我们做了盘子分离但是还有一些管控就这个部分数据它让K把S去识别这部分数据会变得就说这些东西是奇怪的就会改为但肯定地来做是干净的所以这部分能力增长没问题的但是让它调度识别我们也还在犹豫因为感觉肯定会有一些未见到的坑然后包括LPS的这些事更加难以去做的一个事了我们内部也看到了这个KEP但是我们内部也没什么好办法我们就是因为LPS现在是跟那个空间强隔离的跟空间是三号是刚刚不是分两块盘了吗我们只能说尽量把那块大盘根据它的空间然后给它觉得这么多空间的容器根据我们的经验这么多容器它们会用多少LPS就开一个好点的盘给它放上是这么做的划分优先级就是说比如说在专业争抢的时候谁优先谁往后排 是吗这个其实看内核能力我觉得这因为假设是像我刚刚说的继续CPU VR 继续做下去的话那依照看CPU VR能力是丰富到什么程度了好了 大家还有什么问题吗你好这个时间看镜像类型就是现在不能给你一个准确的百分比就是因为你镜像它TAR实际这个数据这个时间到底要花多少和你镜像里面所谓的什么数据它息息相关就是本来就比如本来你是一个100兆的一个TAR变成300兆的镜像那这个时间你说在全安路把这100兆跟300兆中站多少 是吗我们我也有很多就是TAR们给我这种问题但是真的不太好回答因为在平时测试的过程中镜像们的表现非常天下地别它不太能统一到一起那肯定是有了那肯定是有了对 肯定是有了就没办法对 因为它会先占占据部分的空洞的空间然后它会你赶着帮你写赶着会填满这部分空间但是它这个空间不会超过这个空间但是它这个时候实际对整个磁盘的占据的数据量还是那部分小的小的实际按讯赶着你用赶着填的那部分数据这个就是刚刚后面那个同学问的就是你在When I'm trying to getget this usage的时候我要get的是多少那这个事它应该准确的get到我实际使用量是多少而不是我sparcel要占了多少那这是couple能力上肯定可以做到你去丢一个文件看到就是对的了实际这样是sparcel里边那部分贴在了空间的大小就比如说一个实际的sparcel我就写了EM那couple来来或许的时候它应该或许到EM它如果或许错了它有问题没事用到啊sparcel没这样掉还有哪一东西有问题吗OKThank you for the time我是汤天一然后大家如果有兴趣或者教练的话可以加下这个阿里云的这个容器群容器技术讨论群可以一起讨论一下技术或者可以direct message me下面是我的contactAppreciate your timeThank you