Hello 大家好,欢迎大家观看我的分享,本次分享的主题就是在Open Close 中如何我们在拓展对Control Runtime 运行室的一些操作。我是来自阿里云的救助,证明叫王思宇。我是Open Close 的一个commentar,也是一个最初的一个作者。同时呢,我还是Combinatis 组一级其中的Control Runtime 一级一些Covid Statemapics 这些项目的一些contributor,是Covidatis的member。除此之外呢,对云原生领域的一些像OVM、Covidata 这些项目也都有过参与。那我本人呢,其实主要关注在这个机型管理walkload,也就是我们常说的应用工作负载,开发调度相关的领域。那本次分享呢,主要分为以下几个部分。首先我们介绍一下就是在Covidatis 中,我们针对这个容器专time,它的操作限制有哪些。也就是说我们在Covidatis 中,它的机制限制了我们哪些操作,其实是对Control Runtime 是做不到的。第二,Control Runtime 做不到的。第二点呢,就是OpenClose,它是怎么样来拓展对Control Runtime 的这些操作。第三点呢,是我们简单做一个demo,就是我们如何通过OpenClose来实现这些操作的。第四点呢,是简单介绍一下我们后续的一些规划。OK,先来看第一部分。那这里呢,是Covidatis 的一个基本结构,它的结构上在每个节点上,也就是每个note上面,那其实是Covidatis,在Apple Server 里面收到它的比如说pod的变化。比如说Covidatis 收到一个pod的双切之后,它是通过底下一个Ci 以及Ci 以及类似的这种公共的接口,比如说CSI。它是通过这种接口来调用底层真正的这么一个接口的实现者去完成这个操作的。那么对于容器运行室来说,它通过Ci接口调用底下真正的Runtime 运行室,来完成比如说对容器的创建,启动进行拉取这些操作。那Ci 其实是Covidatis 1.5 之后加入的一个新闻。它的目的呢,其实就是说对于Covidatis 能屏蔽底下的Runtime 实现的细节。比如说1.5 之前,Covidatis 其实是与Docker 相偶合的。也就是Covidatis 容器是引入了Docker client来直接对Docker 做操作。那么有了Ci之间呢,其实对于Covidatis 它就不用关心底下真正的Runtime 实现是什么。它只需要调用这层接口。那接口背后的实现呢,可能是这个content.d,可能是CiO,也可能是Docker。当然Docker 目前还是要通过一个Docker shame。OK,那看下来其实Ci这个接口啊,它的制作还是很明确的。那它就是说我是来对这个容器运行时,你对镜像做相关的管理。那其中就包括对容器的这个启停操作呀,对Sandbox 容器的操作,容器的这个States 的这个数据采集,以及镜像的这个拉取,而镜像的查询相关的操作。OK,这个是Ci听的接口,大家看到其实它对于相对来说,是比较完善的一个容器管理的接口。而对于Kubernetes 来说呢,对于Kubernetes 来说,它Kubernetes API 其实并没有提供任意的这个对真正容器运行时的接口的这个操作。那Kubernetes 提供了唯一的接口就是对这个v1 版本的pod 操作。那除了pod 创建,pod 更新之外,唯一能跟这个round time 做比较相对应的操作的其实就是一个exe和一个log,也就是说Kubernetes 的 API 层面限制了用户,说你只能创建,删除pod。那除此之外对里面的容器,那也只能限制说只能做exe,也只能做log。那其实在Kubernetes 接口层面这个用户是做不了更多的事情的,比如说要用户想在一些级点上去提前拉好镜像,或者说他想去重启某个容器,这些接口其实都是Kubernetes 的不提供的。那真的这个问题啊,因为我们的背景是说Kubernetes 它目前,也许将来应该是这样,就是说它是没有提供任何的这个hook,就是google,就是plugin 的这个操作来让外层能去动态拓展Kubernetes 做的事情,比如说Kubernetes 的接口,就是它是不提供这样的插心机制的。那么第二点就是说,我们在思考是否能提供这样一个组建,那这个组建做什么事情呢?它是跟Kubernetes 做类似的事情,它也是会调用CI 这一层,比如说它可以去拉镜像,它可以去重启容器。那它同样的,它上层也可以接受一个对于Kubernetes API 上定义的一个,比如说一个CRD 资源,这个CRD 资源,它定义了让用户能够去声明说要对CI 接口,还去做一些操作,比如说它还可以定义说让用户,可以去指定说要去拉镜像,可以去重启容器,可以做更多的事情。通过这种方式呢,是我们想到的对于Kubernetes 容器运行时operation 这么一个拓展的一个思路。OK,那第一点呢,就是我们背景讲完之后,我们前面讲到了Kubernetes 它的限制背景,OK,还有Kubernetes,我们对Kubernetes runtime 拓展的一个思路,那我们接下来介绍一下就是Open Close,它是,首先,什么是Open Close,就可能有些东西不了解。第二点呢,是介绍一下就Open Close 中,它是怎么样来根据我们刚才的思路来拓展最终对这个Content runtime 的操作的。OK,那先介绍一下就Kubernetes,它的 GitHub 和 Website 这里就有兴趣的朋友可以看一下,欢迎留个 Star.那Kubernetes 呢,这个Open Close 它是Kubernetes 的一个,可以理解为一个拓展的套件。它其实弥补了Kubernetes 中很多这种功能的不足,比方说对于应用工作负载,也就是应用不足发布相关功能的不足。也比如说呢,我们今天要介绍的就是它对于这个Content runtime 的操作的不足。这个Open Close 呢,它是在去年也就是2020年11月份,所谓Sandbox 加入了CNCF。那因为刚刚介绍了Kubernetes 中,其实我们这个Open Close 它的角色,它是一个拓展套件的这么一个机制。它是一个,可以理解为它是一个增强的这么一个功能的套件。所以Open Close 呢,它本身并不是一个Pass 平台,但是Pass 平台呢,可以通过利用Open Close 提供的这些拓展能力,能够更好地去管理,去用为像了我们的原原生的应用,大概是这么一个角色。OK,那Open Close 其实提供的功能也很多了,就是我这里呢,就不仔细去描述了。主要分为几大块儿,一块儿是应用功能复杂,其中就包括了针对无状态应用,有状态应用,它的更多的这种,比方说挥动发布,流量控制,它的原地升级,这种相关的功能。第二点呢,就是我们针对Sidecar 容器有更多的增强的独立定义以及独立部署,也就是动态出入。第三点呢,其实是Multi-domain management,它其实是对应用多分区的这么一个管理,也就是一个应用,它如果要部署在多个分区,就是多个不同类型的切点上,比如说是多个可用区,或者多种不同类型的机型上,它是做一个打散和分片的管理。OK,然后第四点其实是一个应用可用性的一个防护,它可以保护我们这个原原生应用在community实际上运行时的这么一个高可用。那最后一点其实我们就是我们本次主要介绍的一些能力,它其实是一些拓展增强的这么一个operation,这么一些应为能力和操作。中国这种方式呢,就是我们实现对continent runtime就运行时这一层类更多的这种增强的这么一些操作能力。OK,那我们后续就从这几个部分,就简单给大家介绍一下就是如何拓展对cognized runtime的这么一个操作。OK,那想要拓展,就是先介绍一下openclose的这么一个架构。这个架构呢,其实这里的每个节点上的close demo,其实就是我们在前面第一节中讲到的这个背景中讲到的我们的一个思路。就是说我们通过close demo能够避免对coblet做改造,通过这种方式拓展的方式呢,能实现对ci runtime的这个操作。那中心端呢,其实cruc其实主要分为中心端和节点端两个组件。中心端的cruc manager呢,它其中其实就包含了我们比较日常听到的一些controller和webhook这么一个角色。通过cruc manager的这中心端角色和每个节点上这个cruc demo这两个所功能结合来完成很多cognized所本身不提供的这么一个能力。OK,先简单介绍一下我们第一部分,就是今天主要介绍我们三部分对于one time的一个拓展。当然第一部分呢,其实并不是直接通过close demo去拓展了,它其实是利用了一个coblet的这么一个原生那个机制。它这个叫原地升级,那什么叫原地升级呢?其实简单看这个例子,就是它是一个我们比如说看原来有一个pod A,这时候pod A呢,比如说它是通过deployment或者说openclose的close set,那扩容出来的。那么这个时候呢,就是我们想要升级其中这个app容器就这么一个进行版本,比如说要从fv1升到fv2。OK,那这个时候正常啊,比如说大家使用这个deployment的部署的时候,它其实是采用叫recreate update,也就是重建pod升级。那重建完成之后呢,其实我们看到这个pod名字poduid,当然镜像也会升级v2,那pod所在的节点以及pod ip其实很大程度上都会发生改变了,这个后面这两者。那前者的这个pod名字和uid是一定发生变化的,因为它已经不是同一个pod对象了。那相对于我们这次介绍的原地升级,其实pod对象,它还是原来的对象,就是它的name它的uid其实都不变。那么其次呢,就是它所在节点它的这个ip也都不变,那它唯一变化的其实就是镜像从v1升级掉到v2,那它有什么好处呢?其实这个也很明显啊,就是它节省了调度的耗时,因为它节点没有发生任何变化,它这个pod对象就不需要经过调度系重新调度,包括它的这个ip分配,它的这个volume分配,那挂载这些耗时其实都是能去消除掉的。那么第四点呢,就是说它可以reuse,也就是附用大部分镜像的layer,因为大家知道就是我们比如说应用镜像从v1升到v2的过程中,其实可能只是最顶上几层layer发生了变化,其实底下绝大部分的这个base镜像也好,绝大部分的这个公共的layer也好,其实都是没有发生变化的。那么当我们在同一个节点上面做原地升级的时候,其实就可以附用到原有的这个v1镜像的大部分layer,这张下载小部分的layer镜像。那第四,第五点呢,就是在升级的过程中,比方说在升级App容器的过程中,其实pod的其他容器,比如说这个sidecar容器,它是一直在正常运行的,就是说它没有受到影响。那么反过来来说,当我们升级sidecar容器的时候,其实App容器也是正常运行的,就这样可以很大程度上避免了我们在升级一个旁路的比如说应为容器的过程中,也而对这个业务容器造成影响,这是一个好处。那么这个原地升级的这个原理呢,因为时间限制啊,我这边就不具体去介绍它的细节了,可以简单理解为,就是cublate在它在创造的时候,它创建每个容器的时候,它会为容器计算一个哈细值。那当我们上层修改了,比如说修改了App容器的img之后呢,在cublate看来啊,这个App容器的它的哈细值就发生了变化。ok,那cublate发现这个pod spec中这个App容器的哈细值和实际,比方说在contentD,启动这个容器,它里面记录了就是它创建时候的这个它对应的哈细值是不一致的。那这个时候呢,cublate就会把旧的这个App容器停掉。ok,然后用新的镜像去再新建一个新的App容器,通过这种方式呢,来实现我们应用的这个这么一个容器原理升级的这么一个能力。那当然还有更多的比如说这个啊,如何判断原理生理成功呀,它其实它的细节很多啊,这些就不具体介绍了。大家有兴趣的话可以到网上搜一下我们有过相关的一些分享的文章。ok,那第二部分就是介绍一下我们叫容器重启,这么一个功能。啊,这功能其实怎么说其实是很多业务啊,以及它的这个运为平台都是很依赖的这么一个功能。啊,当然大家可能会问啊,就是呃,我这个在cublatex中,一个pod,它既然是这个。呃,比如说diplomatiare泡了它都是无状态的,那如果我想重启的话,我直接啊,删除泡了新鲜鱼泡了不就可以了吗?啊,当然这个是完全可以的啊,但是对于业务来说啊,就是呃,首先说业务,它可能有很多这种debug场景啊,它其实并不是说重建一下啊,建出一个新的泡的就完事了。对吧,它可能是要把呃,当前这个容器原地,从原地发容器重启一下啊,相当于说把里面的这个业务进程重启一下啊,但是它可以比如说想保留一些,呃,这种扩大母信息啊,保留一些这种just like这种对战信息啊,这个输出的出来的,这个都有可能了。啊,这种种这种呃,场景啊,导致业务其实需求的是说,对于cublatex泡的一个容器原地重启的这么一个能力啊,当然这能力呢,这cublatex原生其实是不具备的。啊,cublatex对于cublatex来说呢,它的容器啊,要么你想重启它,只能呃,手动进入容器啊,把它这个容器里面,比如说,这个业务进程啊,或者把它英英的进程啊,就是一号进程啊,杀掉啊,这个说容器退出之后啊,cublatex会再把它拉起啊,当然这种方式呢,其实都比较hack类这么一种方式。啊,所以说呢,openclose所提供的这个容器重启能力,其实只需要。哎,对于API来说,只需要创建这么一个CR。啊,这个CR里面,其实写的东西也很明确,就是namespace,只要定义它的这个gumpaud.txtnamespace啊,这个name呢,是一个自定义的名字。OK,然后只需要指定它的需要重启的pod是哪个,然后container列表,也就是重启pod出来哪些container啊。当定义了这些信息之后呢,当提交了这个CR,哎,那close,说到这个CR之后,closemanager会先经过webhook会给他注入一些信息。OK,然后接下来closedemon拿到这个CR之后啊,他就会根据CR中定义的信息,比方说啊,他会找到对应pod的这个容器啊,他会先执行prestop hook,啊,通过CR接口,通过这个extc,去先执行prestop。OK,然后prestop执行完成之后,再调用这个CR的stop,其实这个停止方式呢,和本身couplet在删除pod的时候的对容器的停止方式是一致的。那当crosedemon他对旧的容器,比如说对这个0号的f容器停止之后,哎,那couplet就会发现这个,哎,我这个f容器停掉了,啊,couplet会感知到,感知到之后呢,couplet就会新建一个fe这么一容器,并且把它拉起。通过这种方式呢,能够实现优雅了这么一个对容器的一个原地重启的能力。OK,那,呃,第三点就是简单介绍一下我们经常预热,经常预热这个场景啊,就是也很多就是,呃,比较常见的呢,是说,哎,比如说我这个集群的维护者呀,比如说集群的管理者呀,他要提前,啊,在整个这个我们的一些集群中,去预热,哎,业务的一个这么一个公共的,比如说基础经向,啊,或者预热一个我们,呃,很多业务都会注入的这么一个,或者都会配置的这么一个塞卡容器的经向,比如说我们预热一个我们,呃,很多业务都会注入的这么一个,或者都会配置的这么一个塞卡容器的经向,比如说我们预有一些,呃,类似于Locktail的这么一些日治采集的经向,呃,这些,这些容器呢,可能会被绝大部分应用,泡的所使用,呃,那这样的话,只要我们提前在节点上,啊,包括在新建出来的这个note上面,还提前把经向预热好,将这段大幅的减少我们后视泡的扩容的这么一个耗时,啊,那背景上的话,其实,呃,对于上层用户来说啊,就是OpenGloose也是提供了一个,呃,这么一个CRD,叫ImageProJob,哎,在这边,帽子中的用户可以定义说我这个要预热哪经向,啊,同时呢,可以选择性的可以是select,啊,这个select可以是,嗯,节点的标签选择器,啊,也可以是根据泡的选择,在这些泡的所在节点上面去预热,啊,这都是可以的,那么当用户建了这个ImageProJob之后呢,啊,对于CRD内部的逻辑来说,CRD会把这个job拆分到,啊,每个note的对应的这个有一个,还有一个叫note image,这个CR上面,啊,那当同步上去之后呢,啊,节点上的CRD就会拿到这个本个节点所对应的这个note image这个select,哎,在节点上去预热这个select中定义的多个的这么一个倾向,啊,换句话来说,每个节点所对应啊,这个节点的note image中的倾向列表,啊,其实就表示了这个上层所有ImageProJob,啊,指定说在这个节点上要拉出了倾向的这么一个,啊,拳击,啊,大概是这么一个概念,OK,那CRD呢,其实它,底层拿到这个note image之后,啊,相当于也是调用,啊,cooperate的,啊,调用这个CI的这么一个,啊,破Image的接口来完成倾向的预热,啊,OK,那,啊,接下来呢,简单做一些demo,啊,OK,啊,这里是,啊,我这边见的一个,看了几群,啊,它有三个worker节点,啊,这时候呢,我CRD中已经,CRD已经部署在里边了,啊,我们接下来看一下就是现在的,啊,这是三个endings的通过department的部署的pod,那,这时候呢,其实我,啊,可以新建一个concept,啊,OK,那这时候其实我这边先演示一下容器重启,那重启的话呢,其实它是针对,啊,pod的做什么器材,所以说它是不需限于这个pod,啊,它是被department的,被still set,还是被这个openclose的close set管理,啊,这部分是不做限制的,啊,所以说这个地方呢,我可以,啊,选择department的pod,可以选择conceptpod,啊,这地方我以departmentpod为例,比方说我要重启这个pod中的一个容器,OK,那我这边已经准备好了一个container request request,这么一个文件,嗯,啊,这个样子其实很简单,就是我把这个podname,只要替换为我需要重启的这么一个pod名字,那重启中,重启的形象是anym形象,啊,这个name是一个随机的一个名字,啊,default是和pod的同一个space,OK,那我只需要常见这个siam,这里其实看到这个pod已经被,啊,这个容器已经被重启了一次了,那最后呢,我们也可以看一下这个siam的状态,它是一个已经完成状态,啊,它的pod名字,啊,错在no的,都这个都有信息显示,当然啊,这里边可以看到它的更多的一些详细的信息,比如说它的这个重启的时间点,啊,完成的时间点,啊,以及它的这个状态,其实都能看到,OK,这是siam,就是我们能重启一个任意的pod中的容器,啊,原地重启,OK,那接下来呢,就是我们简单演示一下经常预热,那经常预热其实也很简单,就是我们可以先看一下这个yamo,啊,这个yamo也很简单,就是它里面定义了说我这个,啊,叫我的名字是什么,啊,叫他的预热的镜像,啊,是比如说endings1.9.1这个镜像,啊,这个是一个并发度,也就是说当我们在,啊,整个集群或者是说在AP节点上做预热的时候,因为为了防止啊,对这个镜像仓库造成太大的压力,可以定义这个并发度,也就是说同时只能有多少个节点在拉去这个镜像,啊,这是一个并发度,啊,这这些侧链呢,就是就不多多介绍了,可以大家给有兴趣,可以看下open close的官方文档,OK,那我接下来创建这个info job,好了,啊,接下来看到,这是因为我们总共一个master,啊,三个walkers,总共四个节点,啊,所以说他toto,就是他的期望啊,拉去的这个节点数是4,那active是2,因为我们设置的并发度是2,啊,所以说他这个active最多只能是2,啊,这个时候还只是在拉去前两个节点,OK,那这时候呢,我们看到就是总共四个节点,那两个已经完成了,啊,两个还正在拉去,就是我们可以再拉去后面两个节点上的镜像,这里可能要稍等一下,好的,三个已经完成了,OK,四个都完成了,OK,啊,那这以及后面呢,可以简单看到他的一个job的一个progress进度,那通过这种方式呢,能够定义我们在,呃,指定的一批节点或者说在整个集群范围上,来拉去我们特定的一些镜像,当然目前啊,这个impa job呢,他单个CR里面只能写一个镜像,也就是说当我们如果想在集群中预热多个镜像的话,得创建多个这么一这么impa job这么一个CR,那后续呢,我们也可能会,呃,支持一个job里面,指定一批镜像来做拉去,啊,这个时候我们后续了一个,呃,可能做的这么一个事情,OK,那我们接下来还是回到我们的PVT,好的,那最后呢,就是时间差不多了,最后呢,我们简单介绍一下我们后续的一些规划,那open course呢,他目前的,呃,大数量应该已经接近2800了,那contributor呢,大概是,呃,将近70个,那,呃,其实open course从,呃,19年啊,0.1版本发布到今年为止啊,其实已经经过两年的时间了,那接下来是我们在年底呢,大概在12月份,呃,中旬左右,会发布open course,1.0正式版大版本啊,那,呃,另外呢,就是我们计划在2022年,呃,申请呢,进入这个CNSEF这么一个incubation的这么一个stage,啊,那目前其实open course呢,就是呃,他的用户在国内也是很非常广泛的,除了呃,权量这个使用open course,部署这个应用的这个阿迪达瓦集团,呃,还有其他像蚂蚁集团,斗鱼生通啊,以及我们呃,大家比较熟悉的像这种协成啊,小红书呀,呃,以及今年就是我们刚登记了open course的这种用户,也就是说跟正式使用open course的小米呀,这个网易啊,为谈金融化,其实都是open course的这么一个生产用户,呃,那呃,大家对open course有兴趣的话,就是说,也可以加入,就是可以回头看一下,就是我里面刚刚我跟个人介绍的页面啊,有我个人的一些呃,信息,就是大家有兴趣可以,就是在slack,或者在这个微信上加我,那对open course的社区啊,交流感兴趣呢,也可以加入我们的这个slack channel,以及我们的这个订阅群啊,这个都是我们交流的一个途径啊,非常欢迎大家来进行一个呃,共同交流以及这种分享,包括呢,大家能开与共建,OK,好,谢谢大家。