大家好,我是来整医,下面由我来为大家分享用以应用为中心的方式管理多级群中的应用首先做一下自我介绍,我是来自青云科技的工程师同时也是Cubisphere的维护者主要关注的方向是应用商店、网络、多级群等功能下面是我的联系方式和GitHub账号地址如果你在会后对我的内容有任何的疑问,都可以和我沟通这是本次分享的大纲首先我们会来介绍一下两种常见的应用类型然后再介绍Cubisphere以及应用商店在Cubisphere中的实现最后我们再介绍我们之后会进行的工作和QA环节在云原生的世界中有两种常见的应用打包类型它们分别是Cume和OperatorCume的逻辑非常简单它就是Cubinatus中的包管理器根据官方的介绍CumeChart可以帮助你定义安专升级那些非常复杂的Cubinatus应用下面是一个势力的CumeChart目录其中Chart.yaml定义了这个Chart相关的信息License包含了这个Chart相关的许可Redmi包含了一个给人看的说明文件Values.yaml包含了这个Chart默认的配置文件Values.schema.json包含了这个Values.yaml相应的jsonschema文件用它来教验用户输入的Values是否符合规范下面的Chart文件夹包含了这个Chart所依赖的字ChartCRD是文件夹包含了这个Chart相应的CRDTemplace文件夹包含了这个Chart需要渲染的模板文件Templace.sql.notes.txt包含了一个纯文本文件它可以让你在使用HELM客户端时获得一个简短的使用说明HELM的核心思路都非常简单它就是围绕着KBAR-S资源做一个模板化的渲染它的升级和安装都是通过模板的形式来处理的而operator的模式不太一样它需要开发者编写一定的代码逻辑来控制资源的生产用户在使用时也需要先在集群中安装对应的operator比如图上作为例子的plomiceos operator它可以通过HELM的方式进行安装也可以通过operator framework中的OLM组件进行安装operator其中plomiceos的operator会监听它所需要的自定义资源相关的CRD比如图上左侧的plomiceosplot manager service monitorplomiceos rulers等CRD一旦plomiceos的CRD被创建出来plomiceos operator监听到了相应的创建行为它会创建对应的deployment或者statable set后续的CRD相关的变动operator在监听到CRD的调整之后也会按照自己的业务逻辑控制是否需要调整相关的deploymentstatable set service或者configure map等资源operator模式它可以实现的功能很多而它本身的生命周期管理也是一个问题那么对比HELM和operator他们的区别是什么呢这里我们借用一张operator framework博客中的一张图来对比operator和HELM的区别HELM可以覆盖到阶段1和阶段2而operator可以覆盖到阶段12345也就是说HELM可以实现基础的安装和升级而作为用户你希望使用更丰富的应用功能比如说全生命周期管理监控告计 日治处理或者是自动的横向和纵向的弹性声缩或者自动配置调优的那么你需要使用operator版本才可以实现HELM它使用起来非常的简单和快捷而operator使用起来功能很强大在开源设计中有很多应用都有HELM的插头包并且有更多的应用它正在实现operator化那有没有一种办法可以同时使用HELM和operator来分别进行部署应用呢下面介绍我们在CoopySphere中的实现首先我们需要介绍什么是CoopySphereCoopySphere是一个分布式的操作系统它的愿景是打造一个以CoopySphere以CoopyNetus为内核的云元生分布式操作系统它的架构可以非常方便的使第三方应用与云元生生态组建进行集差集用的集成支持云元生应用在多云与多域集群中进行统一的分发和运维管理目前CoopySphere已有70多万次的下载量社区中已有200多位的贡献者和70多位成员也欢迎大家访问下面的链接加入CoopySphere社区我们在CoopySphere的应用商店中同时兼容了operator应用和HELM应用对于用户使用来说其实区别不大不过operator应用它的功能会更加的丰富比如图上它就是一个operator应用用户在部署时需要指定相应的租户和集群也就是图上下车的location字段中它有相应的operator space和相应的cluster表示它相应的租户和集群然后是配置operator应用中相关的参数比如对于PG operator它支持自定义数据户的版本资源配置存储类型存储大小从数据户的数量等参数用户在指定完配置之后即可部署相应的customer resource部署后可以进入到它的详细页面查看或者更改用户的实力的工作负载或者反映方式这个数据户实力本身对应的其实就是KBS的customer resource前端页面有数据户的开发者自定义需要展示的内容比如图中你可以看到它相应的数据户的一个反分的连接方式以及相应的数据户接点所在的破的信息和它的类型和它的存储的一些规格图上是数据户相关的用户管理的tablet本质上也是修改customer resource然后交由operator去处理这个应用的operator它可能是修改相应的config map也可能是由相应的deployment去读取customer resource更新到数据户中图上是数据户实力相关的配置tablet它可以修改数据户实力相关的配置也是一些比较常用的配置下它的实现其实本质上也可以是customer resource也可以是普通的config map这个由开发者去决定并配置相应的UI页面完成UI可视化的配置下面我们来讲解它后端的主要实现方式在CoopySphere中有KS controller manager组件它会坚定上面的CRT比如如果是operator应用它有自己的operator app和operator app version如果是cume应用它有自己的cume app和cume app version同时cume应用我们还支持用repo的方式进行部数对于一个operator应用来说相应的应用实力就是其中的manifest CRT当一个manifest CRT被创建KS controller manager监听到它的创建后就会去该机群中卡着operator是否已经安装到这个机群上如果没有部数的话那么会由KS controller manager在机群中部数相应的operator如果已经部数了operator的话那就会直接跳过然后创建manifest中相应的自定义资源由其中的operator根据customer resource这种自定义资源来去创建相应的工作负载下面是operator应用最主要的spike其中operator application表示单前的operator应用以及它的名字和描述还有它的图标operator app version也就是operator application version表示operator应用有哪些版本每个版本它的安装方式是什么比如CRT需要转哪些operator对应的安装方式是什么比如在这个例子中使用HELM安装TIDP operator它对应的HELM chart是哪一个这样的话KS controller manager它就可以去知道我需要先装CRT然后再装HELM chart这样就能把operator安装到这个机群中manifest表示用户实际部数的资源实力它定义了部数到哪个具体的机群和版本这样KS controller manager就可以知道要将自定义资源下发到哪个机群中的哪个name space装并且在安装自定义资源之前它会检查相应的CRT和operatorKS controller manager在安装CR之后还会监听相应CR的status变动然后更新到manifest中这样manifest相应的status的变化就可以在前端体现出来而图上是另外一个HELM应用的例子我们提取了其中的Values.schema.json作为UI化的辅助教业同时用户也可以直接编辑这个chart中的Values.yaml文件图上就是适力的Values.yaml如果有需要修改参数的可以直接编辑之后进行部署部署之后也有相应的应用实力的详细页面也可以看到这个HELM chart部署后包含的工作负载和service相关的信息比如图上上半部分就是service相关的信息下半部分表示它相应的工作负载以及工作负载目前的部署状怀还可以继续跳Tabye来查看这个HELM chart相关的readme也就是这个HELM chart相关的描述也可以查看这个chart中已有的文件默认是查看Values.yaml同时你还可以查看它其它的比如说它的配置文件比如说它的notes等文件的然后你还可以跳Tabye查看它的相应的HELM的配置如果有需要的话还可以对它进行更新相应的KS controller manager会更新这个HELM应用HELM的部署的话它同时支持两种方式一种是从HELM的repo中部署应用还有一种是在自己的租户中上传应用然后发负到平台的应用商店中这里我们先讲解一下HELMrepo中部署应用首先你只需要创建相应的HELM repo实力也就是前面这部分HELM repo这个相关的然后创建HELM release关联使用这个repo其中HELM repo中也比较简单的这个自断的描述比如说像URL定义了这个repo相应的这个repo的地址credential包含了这个repo需要反问这个repo是需要用到的这个配置文件或者是它的健全文件HELM release中包含了这个应用它所在的这个chartname和chartversion还有repo id有了它们controller就可以定位到具体是这个repo上的哪一个chart包然后通过里边的Values这个Values它是一个Base64编码它纯字不串然后用这个Values作为输入参数安装到对应的集群中然后坚定到最后的安装结果它本质上其实就是KS的controller manager去调用HELM install然后把这个HELM chart包去安装到这个集群中这是一个租户在这是一个用户在租户中创建HELM chart的例子它对应一个chart会有一个App有一个或者是多个的version在这个例子中我们就用一个version来表示每个版本的这个chart包它都会data key的作为文件名存储到S3上这里我们CoopySphere内建了S3的服务端是minio然后由相应的这个chart包存到S3上同样是HELM的应用和HELM应用的版本用户创建相应的release来指定版本和应用同时还需要指定Values的Base64的这个参数然后由KS的controller manager去获取到相应的数据比如说它先获取到相应的版本和相应的这个应用然后获取到版本相应的这个chart包然后配合这个Values通过chart包加上Values来执行HELM Insta安装后KS的controller manager还会监听这次安装后续的结果另外我们还调研了Pretor very mark中的operator life cycle manager 组件它可以满足单个集群下operator更丰富的生命周期管理这里也简单介绍一下operator life cycle manager它是一个非常简单却有效的单集群的管理组件它主要包含下面的CRD每个CRD的功能不同比如说operator group用来定义多个租户下的operator指定operator安装到哪个命名空间下还有cluster service version简称CSV包含了operator相关的元数据也就是operator相关的mem或者是version或者是icon或者是它必须的一些资源还有它整个的安装过程需要设计到的那些资源还有catalog source它是operator相关的仓库它包含了很多的CSV和CRD还有operator工作副管复杂相关的包信息install play用来计算出安装或者升级CSV过程中需要创建或者更新的资源subscription用来跟踪安装包的channel变化来执行版本的更新图中的catalog operator通过subscription来判断是否需要监听package server一旦有更新则会生成install player来更新CSV有了新的CSV这个OLM operator就会负责安装或者升级operator使用OLM之后可以更简单的管理单个几群下的operator并且根据它自己内部的逻辑可以维护operator的升级对于我们在多几群环境下去进行operator的风发很有关注目前我们已经将Chrome和operator应用都接成到应用商店中后续还会支持OLM也就是Cubula应用目前的operator应用的风发还不够灵活后续我们也会将operator应用的生命周期管理作为CubeSphere可插拔组件的一部分进行结合然后支持在多个几群环境下去风发可插拔组件同时和operator life cycle manager去进行结合做到更简单的去风发多几群下的operator应用感谢大家我的分享到这里就结束了感兴趣的同学有问题可以提问谢谢大家