大家好,欢迎来到Kubukang我们这一场分享今天我们要分享的主题是以一个一致的体验去构建和管理跨集群跨环境的应用然后本场这个分享会有我和我的同事来给大家一起共同的介绍我先介绍一下我自己我叫孙建波,我来自阿里云然后后面当我们介绍到oCm部分的时候会有我的同事逢勇给大家深入的介绍然后大家也可以通过上面的联系方式联系我们我们今天的主题是两项项目一个是Kubela,一个是oCmKubela是一个简单应用并且高可扩展的应用交付系统它可以用于交付如今的这样一个混合环境多环境的这样一个部署结构它是一个声明式的应用交付项目它可以天然的支持GitOps的这样一个模式同时为大家带来这样一个围绕开发者的以应用为中心的这样一个一致的应用交付体验然后同时它也是一个CNCF的一个开源项目大家可以通过上面的这样一个地址去访问和查看然后对于这个Kubela的用户而言它们通过这样一个CI的系统也可以对接像Jagons, GitLab这种模式也可以走GitOps的模式然后通过Kubela做这样一个资源的渲染编排最后可以交付到不同的集群不同的语音上面我们可以看到在Kubelitis的这样一个生态里面大家其实都在做各种各样的CICD的这样一个系统可以把现在大部分典型的这样一个CICD的模式称为一个CIOps的模式这些模式尤其以GitLab,Jagons对接Kubelitis为主这些模式它们从传统的这个模式演变而来但是它其实存在一些所谓的anti-pattern而为什么不正确呢这里面有几个大的问题首先它是一个就是安全的问题我们可以看到右边这张图它里面有好几个流程这个其实就是我们一个经典的CICD的流程就是CID和CID其实是用的同一套模式所以我们在CICD系统里面也会配置这样一个Kubelitis的APS server的权限然后Kubelitis的APS server在部署到这样一个YAML或者Helm Upgrade的以后其实我们就会去自动的去读取这样一个镜像仓库啊或者这样一个Helm Chart的仓库这种模式呢其实我们可以看到有好多地方其实是权限是比较混乱的尤其是最主要的是这个CI系统里面它持有了所有的Kubelitis集群的权限如果不控制好这里面的权限的话其实是很容易引发故障的比如说物杀了某一些存储物杀了某一些容器的资源等等第二个大的问题是我们的所有的体系通过CI的这样一个管道流程去部署的时候容易出一些配置漂移的程序情况就是你的这样一个CI的系统它可能会部署到不同的Kubelitis集群上面去那你的这个Kubelitis集群有一些可能已经配置好了部署好了有一些可能由于CI的系统它运行出错然后它可能配置失败了或者说没有部署成功那这个时候在系统比较庞大的情况下比如说你有上百个集群的时候你可能就无法正常的工作了因为它有一些配置可能和你这边CI上面跑的结果完全不一样它出现了大量的这样一个配置漂移第三个大的问题就是和配置漂移相似的我们的CI系统对接到比如说你通过Jagons部署到N个这样一个Kubelitis集群以后其实你在这个集群里面部署的这样一个工作负载它到底有没有成功你的CI系统根本不去关心也就是说它只是负责把这个东西Apply部署到这样一个Kubelitis系统里面然后就不管了那这个时候呢很多情况下它其实是无法正常运行的那这个时候一般的这样一个传统的CICD Pipeline会说这个事情是你的Pass平台要关心的你的Pass平台需要去提供这样一个可观的性能力那这个时候呢如果我们需要重新那这个时候假设我们有一个Pass系统它发现了这样一个问题对吧部署失败了OK那这个时候要么你重新走一遍所有的CI流程比如说你可能要部署到N个集群或者重新配置一下某一个动作再重新部署一遍那这里面呢可能出现一次新的不一致那这个时候呢其实它的动作呢其实都是人来控制的它没有一个自动化的过程也没有一个长期的一个守护的模式去说一旦这里面部署失败了就去重新部署我们知道K8S的这个模式全都是声明式的我会不断的去通过一个控制循环保证这样一个工作负载的正确性但是在应用交付这一环其实这里面就缺失了我没有一个传统的CIS系统它其实是没有一个东西去保证你的交付的正确性然后更复杂的情况其实是出现在混合环境如果我们有不同的语音不同的集群不同的环境是当这个体系变得非常的庞大以后其实是很难管理的它的这个复杂性会非常的高Kovela会用什么模式去解决这个问题呢首先Kovela它是天然和GateOps的模式可以比较大的到了Kovela这里Kovela可以把这个和K8S集群交互的所有的权限它收敛到Kovela这里面然后CD系统只有Kovela来管理然后Kovela会读写这样一个代码管理部署配置的一个代码仓库然后配置由Kovela来部署到这样一个K8S系统里面并且Kovela还可以将你的配置能部署到不同的集群里面去不同的云上甚至是边缘的环境Kovela的一个很大的好处就是你所有的配置都是通过一个Kovela的一份压抹文件就是一个应用交付的一个配置来管理的然后Kovela作为一个Kubinitis的控制器它会不断的在这里面去运行所以呢整体的一个部署的环境和部署的这个模式全都是有一个确定性的保证的就是Kovela的控制器会不断的向你的交付的中态去靠拢收敛然后同时它整个过程也是可观测的同时Kovela会根据可观测性的一个结果比如说这个部署失败了那么它会去重视最终的达到一致的效果所以它里面有一个转动化可观测性并且是收敛收敛到最终你的声明式的描述的中态以及它是一个确定性的结果如果比如说你的这个机群里面某一些资源被误删了或者由于某些操作失败了那这个时候它会帮你去重新的做一些恢复的工作同时Kovela还可以帮你管理这样一个跨环境的交付Kovela里面内置了一个应用交付的工作流在某一个环境以后你可以做一些教验的工作然后在教验成功以后再部署到另外一个环境那这一切的这个不同的环境也好不同的云场上也好它都是在用户的这个体系里面都是一份的这样一个配置用同样的一个体验去完成整个的流程我们来看一下Kovela的这样一个它的配置文件它的这个Kovela的整体的配置文件的其实就是一个部署计划这个部署的计划的名字叫Application然后它里面分了几部分第一部分是组件这组件可以分为好多类型就是你里面比如说是一个正常的这样一个web应用或者说一个HelmChart包或者一个云资源或者一个Teleform的模块都可以通过这样一个Kovela的组件呈现出来那区别就是这样一个Type的不同然后对于用户来说只需要填写比较简单的像镜像和端口这些被Kovela抽象过后的子端这抽象的过程其实也是一个最佳实践你在里面是填写的一个运为或者平台管理员总结出来的最佳实践Kovela里面也会有大量的开箱机用的组件包括HelmWeb服务Teleform的一些云资源等等然后另外一部分是这样一个Trade也就是运为特征运为特征其实就是一个相应的运为体系的自动化运为的一个贩子比如说我们需要有一个可以备访公网访问的一个路由或者一个自动拓缩容的一个策略或者说一个部署的策略那都可以通过Kovela的Trade的模式集成进去第三个部分是这样一个应用的交付策略这个应用的交付策略其实也是一系列的像安全策略配置教验跨环境部署的一些策略第四部分其实就是这样一个工作流这个工作流其实就是你的整个交付的过程到底是如何定义的比如说在一次部署的过程中你可能是部署到开发环境然后在经过验证以后加入一个人工审核人工审核成功以后再去部署到生产环境那对于每一个阶段完成以后Kovela内部会有一个状态机在这个状态机里面会记录当前这个阶段完成以后它对应的所有的资源是什么状态然后持续的面向中态的去保证这些状态是确定性的然后Kovela其实是通过一个统一的体验来把整体的这样一个应用管理起来那这个统一的体验当然也包括云资源这部分的统一体验比如说我们要创建一个云的数据库那这个时候怎么办呢Kovela通过和Terform做一个集成来完成这样一个工作用户在这个部署的过程中同样的也是部署一个Kovela这样一个应用也就是一个交付计划它整体是一个多组的一个模式那我们可以看到基于Kovela和Terform这两者的结合我们把云资源的交付也变得统一了然后我们在Kovela里面还有一个整体交付的工作流我们知道其实在应用交付的过程中不同的环境他们的差异性是非常的大的比如说我们在开发环境测试环境中其实它里面会有大量的需要调试远端执行日治还有技术确实化等等工作然后我们的应用的创建的生命周期和云资源创建的生命周期他们是一致的那到了预发环境就是一个生产前的连条部署验证的环境中它里面的云资源可能不是实施的创建因为你需要和不同的团队去连条会的资源都是通过绑定的方式去创建的然后同时我们可能在里面需要去使用可观责性的组建而不是说去通过直接EXEC或者用容器的login的方式去查看所以对应的应用的部署的这个方式会有很大的不同然后到了生产环境可能我们就有更多的差异性它可能涉及到一些运为监控流量的挥度等等的差异所以我们可以看到不同的环境其实是它需要有不同的配置然后同时我们在应用的交付的过程中可能会涉及到不同的这样一个环境的部署比如说先部署到开发环境然后做一些验证然后不同的环境有不同的配置然后验证通过以后再去部署到生产环境整个过程其实是一个应用交付的工作流程所以呢酷威拉把这样一个应用交付的过程通过一个bookflow来整体的描述这样的话用户对于这个用户的体验而言它其实是通过一份配置就可以完成整个跨环境的这样一个完整的交付过程一会我们在demo过程中也会去演示一下这样一个体验然后酷威拉的多级群技术其实我们就是通过ocm来完成的那为什么要选择ocm这样一个多级群技术呢下面将有我的同事冯勇来为大家介绍ocm的一些进入细节大家好先做一下自我介绍我的名字叫冯勇在阿里云周永云负责中群台前面我的同事是剑波给大家分享过酷威拉这个项目那接下来我会给大家介绍一下ocm这个项目以及ocm和酷威拉如何构成同一的绝对方案并且这个绝对方案我们怎么计划在阿里云落地那最后呢剑波也会给大家做一个整体的demo来介绍一下这个方案的具体之心ocm的全程就是open class management它的主旨是在将open class社区的技术托管到多级群火红云领域让用户和研发人员在多级群火红云的环境下就像现在在单一open class的集群内一样使用他们所喜欢的项目和技术ocm它已经具有相当长的研发历史了最早是在2017年由IBM的专用云容器团队为了解决在企业环境下couplified v2的一些遇到的一些问题而创造的新的架构它在多级群环境下解决的问题跟couplence的单级化解决问题类似couplence的单级群它首先要解决节点的管理问题包括节点的注册上面的生命中心的管理以及特殊资源的描述这样分成在各处的多个节点组合成为一个完整的集群为用户的应用提供服务相应的它也要解决这个用户的应用以及应用相关的资源在这个节点内的分发问题已经在分发的过程中所遇到的调度问题最后couplence自身其实也是一个编程平台它由最初的control manager到后面的cld以及aggregate API它提供了一些的平台和技术帮助研发人员扩展它的能力那今天早上早些时候我们团队的另外一个同学金明也给大家介绍了围绕着aggregate API这一主题也给大家分享了相关的技术OSM与couplence类似它在多集群和火候运环境下也要解决首先解决集群的资源管理问题包括集群的membership以及集群上面部署的特殊资源的管控和信息它将分散在各处的多个集群就会是一个整体用户提供服务同时它也要解决应用以及应用相关的资源在多集群的分发以及在分发过程中的调度问题同时OSM资源也是一个扩展平台它具有iDom frameworkI帮助研发人员将couplence类似的社区的其他项目迁移到多集群环境下那OSM与之前的集群管理项目到底有哪些不差异呢像刚才提到的它的诞生支出是为了解决couplence的微图在针对企业应用在多集群合合用环境下的问题而诞生的那couplence的微图到底遇到哪些问题呢首先是整体架构的模块问题couplence的微图是相对紧偶和的一个整体研发人员很难在couplence的微图上进行功能的裁减和扩展其次因为couplence的微图它的集中控制面的问题我们它遇到了潜在的性能瓶颈我们在测试环境测试室我们发现当集群规模超过50个以上时couplence微图就会遇到比较显著的性能下降遇到了它自身的瓶颈第三个就是安全性问题这个安全性体系下有多个方面首先couplence微图需要集群在中央集群的注册那注册是使用的token就是控制在管控集群未来访问被管集群的token那为了满足需要我们不得不使用一个相当大的全线的token而且couplence微图也没有提供这个token的生命日记管理的能力最后一个就是可控染性就像前面提到的一样couplence微图并没有提供有很好的机制让研发人员对自身的功能进行产业和扩展那为了解决这一系列的问题ocm提供了自己的解决方案那首先就是模块化ocm其实是用一系列的子项目构成的那所有这些子项目就像乐高玩具一样研发人和用户可以随意的选择他们所喜欢的项目聚合成为一个整体的方案第二条就是scalability就是可控染性我们借鉴了couplence的设计原则使用了couplence和APS or control manager类似的东西模式那这样理论上ocm可以支持的进行个数和couplence能够支持的这种个数是类似的第三个就是安全性问题刚才说到安全性在多个方面我们不再需要在ocm中我们不再需要在管控机群中注册手动的注册一个背管理机群的方案方式解决了背管理机群和管理机群的自动化的注册问题在零信任的条件下的自动化注册问题在大多情况下它不再需要直接与背管理机群通信而是由背管理机群通过铺的模式来获取相应的资源在有些情况下它也需要通信的时候它使用的其实其实是背管理机群的ServiceCount的证书这个ServiceCount就像K8中的Klan的访问中心级点是第四ServiceCount的证书也会我们有相应的FramoKlan完成ServiceCount的证书的并计划的refresh这样就从两个层次上解决了这个安全性的问题那最后就是可供染性因为OCM的iDom Framework它提供了更好的困扰能力研发人员可以在iDom Framework之上来开发自身的做一些管理能力这是OCM的整体架构由Kovovilla和OCM共同构成的整体软件站就实现了应用和基础设施的他们是之间是怎么一起工作的呢第一个由Kovovilla的Workflow这个模块通过解析应用布置所选的资源来调用OCM提供的最基本的Work API而实现这些资源在多机群的分发那这些分发对上层的Kovovilla都是统一的OCM在整体架构它都选择了哪些子项目像刚才说到的一样OCM整体是像一个勒高金目一样在这个方案中第一步我们选择了第一个选择了API子项目它来实现节点的什么就是预管理和自助测同时我们还选择了API子项目之上的两个iDone framework第一个iDone framework就是IC Manager它的工作就是来实现被管理机群的Service count的证书在管理机群的refresh问题这样来说的话管理机群就可以使用被管理机群的Service count来和被管理机群通信第二个iDone framework我们称为PoxAdentPoxAdent它利用ANP这样的一个项目来实现来和管理机群实现一个反向代理在此之上我们通过class getaway来实现request的自动路由我们之前提到过work project它是通过Pox这种模式从被管理机群主动的获取管理机群部署在被管理机群的资源它有的好处就是它的扩键量激情但是另外有一点就在于它还是需要对Eo的应用进行改造需要让Eo应用将它的request封装为ManifestworkManifestwork可能可以理解为是一个信封可以包含任意的K8资源这样有很多的可过染性的好处但是刚才说到的它需要对上当应用进行一些改造在这些应用完成解改造之前我们也同时提供了PUSH的这种通信模式PUSH的通信模式用户可以使用Eo的固定CPU来完成我们隐藏了通信所需要的安全和通路一些的问题由Class Gateway来自动的实现路由用户不再指定被管理机讯Landpoint而是通过机讯名称就可以分方便的将命令分发到指定的机讯内部那有了这种整体的人家构之后我们就可以实现应用的在多机讯领域下的整体的生物秩序管理研发人员可以完成研发之后将这个应用的镜像提交到镜像仓库同时将这个应用以OEM模型描述的PUSH资源文件提交到Gate的仓库由QoEla的订阅模式组建来监控这些进行仓库订阅仓库的变化当根据预先订阅的策略的变化发生时QoEla可以主动的去获取这些应用的部署资源同时我们也支持客户主动的铺来实现主动的资源处方像刚才描述的一样用户可以通过一种描述方式QoEla就可以将这个应用在不同集群环境下的条件进行渲染使用OCM来屏蔽底层集群的差异性将这个应用分发到各个集群环境下来实现一次描述多地部署这样的一个能力最后就交给这个剑波OK 下面进入我们的demo部分我们的demo一共分为四个步骤第一步是配置这样一个GitOps的监听它会监听GitHub的这样一个仓库和Docker进向仓库然后第二步监听完理会它会自动化部署部署过程中我们可以在开发环境去做一个调试验证这个可以不继续部署然后就中断然后第三步就是本地的开发者可以在本地做这样一个代码的修改然后重新推送到代码仓库里面后面的这个流程全都是自动化的然后最后我们在开发环境的验证通过然后可以做一个approve的操作然后我们就可以跨环境部署了然后我们整个的这样一个demo的环境它都是在这样一个唯一的联通性是这样一个中央的集群它是被这样两个子集群能够访问的也就是说这个子集群里面会有ocm的这样一个agent去访问这样一个中央的集群然后整体都是基于这个ocm的铺模式来完成的好 下面开始我们的操作我们可以通过vela clusterlist查看集群里面的集群信息然后我们现在有两个集群一个是开发环境一个是生长环境这些集群的准备工作由于耗时照常我们就已经提前准备好了你也可以通过vela clusterjoin这样的一些命令来加入到这样一个把子集群加入到中央集群里面来好的我们来看一下我们的目录结构里面一共包括三个文件第一部分是一个应用的目录第二部分是这样一个GitOps的监听然后第三部分是这样一个技术是触触化的一些环境信息我们先把集群信息部署起来OK这样就部署起来了然后部署完成以后其实他整体的这个过程全都会自动化的去做一个部署我们来看一下这里面的内容这里面的内容首先是这样一个监听这个监听我们会去监听到这样一个GitOps的仓库然后他会监听这样一个分支这个APP目录所以这个文件其实是在监听整个这样一个APP文件然后同时他也可以监听进项仓库监听的是这样一个进项仓库符合这样一个政策表达式的信息然后他会根据进项的这个标记是不是增加了然后去触发这样一个自动化的一词的部署然后他部署的过程中其实是会去替换这样一个进项的字段然后我们部署的应用它里面就是包含了一个基本的Web访问和它的Web的Ingress以及它的整体的一个多级寻多环境跨环境部署的一个配置然后不同环境的差异化的信息我们可以配置在这里然后另外一个其实也是类似的我会监听这样一个infrastructure目录这里面是两个数据库一个是开发环境的这样一个运资源的数据库另外一个是这样一个生产环境的数据库OK我们可以看一下现在的理论上已经付出好了我们先整体来看一下它的这个状态OK整体都正常了然后我们可以用看一下它的认识OK它在监听Valor status看一下它的这个域名然后我们再打开Valor Logs可以持续的看它的认识OK我们来访问一下好访问成功了那我们怎么修改呢切换到我们的开发者的这个环境里面那我们想要把这个页面做一些改动这个页面是success所以我们想要改一下success again加一些字好然后呢我们就可以把这个代码修改check in到这个success6Push到我们的这个仓库里面Push到仓库以后呢我们的这个kit hub配置了这样一个监听的流程kit hub里面配置了这样一个ci这ci呢会自动的把这个对应的镜像呢上传到我们的dokal hub的仓库里面它会build一下这个镜像这个ci的配置呢大家也可以参考这样一个仓库里的模式啊OK这里就已经推送成功了ls就是我们的这个app的dokal hub能会自动的做监听自动修改以后呢它这里会重新开始跑susbanding就对了susbanding的话就代表的它会它已经更新了应该我们再来刷新一下页面OK它已经更新成功了然后这个时候呢我们就认为它已经部署成功了那么我们就管理员就通过了所以呢我们就要进行到下一个环节就是要跨这个机群部署了所以呢我们的这个vella的这个workflow呢就可以执行一行工作流的继续re-sumere-sumemy appOK然后呢它就会开始继续的执行继续执行然后呢会执行到哪里去呢执行到这个生产环境的机群里面去OK我们这里可以看到开发环境和生产环境的都有了那生产环境的这个域名可能还没ready就是英国人还没ready那我们可以来看一下这个日治的情况my app我们有两个环境的日治那我们想要看一下生产环境的日治OK它已经已经在正常工作了这个日治也是正常的好那我们再来看一下好此时呢两边都成功了好再来看一下这个生产环境的状态OK success again所以到这里呢我们的这个demo就成功了最后呢我们来讲一下1.2的roadmap在1.2中呢我们将开放出一个GUI控制台也就是说大家可以通过GUI的操作介面来操作上述的这样一个应用交付的过程同时呢我们会提供更好的监控日治以tracing的能力能够让你非常可观测的看到你的整个应用交付的状态然后呢我们也会提供和现有的ci的体系以及cd的这个体系的一些结合的案例大家可以从jagons的这个过程中呢直接交付到qvilla的这个系统内不光是走github的模式其他的模式呢也都可以对应上然后以这个一致的体验呢完成整个应用开发到最后交付的全过程然后呢我们也会提供一些像ai啊大数据啊边缘啊等场景的案例大家也可以访问这些官方文档的这个内容了解更多的详情那我们今天的分享呢就到这里谢谢大家