非常高兴大家今天来听我们的分享今天分享的主题是基于Tekton来构建大规模云原生4SAD系统会有我和我的同事金铭为大家带来这次分享这次分享我们的议程主要分为几方面首先我会为大家简单介绍一下直接调动在云原生DiWAP4SAD系统上建设的一些理念接下来我的同事会为大家介绍Tekton的架构以及我们基于Tekton构建DiWAP4SAD平台的一些实践和经验为了云原生架构的设计理念已经成为驱动我们业务增长的重要支柱其实这些调动整个基础设施的发展也是云原生眼镜的一个缩影我们从很早就开始拥抱了云原生相关的技术目前的话当可维内的集群也达到了10万台的规模微幅数也接近了10万实施容器数接近千万每日的线上便达到了4万次我们主要为了的三个重要的理念来构建我们当前云原生的架构体系首先是基础设施的平台化极力用云原生的基础来统一纳管基础设施在广泛采用云原生基础之前我们还无法屏蔽调底层的物理资源对业务放而言是有额外的使用成本的也不利于业务的快速迭代无法从全局去提高资源的利用率而用保云原生之后我们得以逐渐收拢资源构建基于可不可以类似的一个业务入口另外一方面云原生技术也进一步降低了我们去构建多云弹性的能力目前我们的技术设施与其在各大云服务厂商之上根据业务的需求可以实现快速的弹性和融在的能力后面我们同时也会简单介绍一下流水线支持多于地域的一些实践其次是应用架构的现代化也就是图中的第二个框这块的话其实核心的逻辑是回答如何重塑我们构建应用的一个方法去面对当前比较复杂多变的数字世界这里我们充分结合了云边端的能力实现了云化移动化和轻量化从原生的角度来看我们实际上是希望做到为了应用和服务的核心来构建我们的平台在基础设施平台化之后我们从2018年也逐步开始了ServiceMesh的建设构建公司级的流量和容带体系基于染色的精气化调度还有一些强制安全策略的微业物提供了相当多的基础级的能力当前已经有3万架的微服运行在生产环境当中而在其他方向上例如寒树计算引颈商量日军活跃寒树达到了10万架在云边协同并面协同场景上我们也借助云边生的技术实现了核心计算引擎比如说边位容器落地了诸直播图片服务等场景在移动端我们构建了晚辈的端技术框架结合云实现了一战士移动研发流程在开放平台轻服务性能观测上都有比较不错的落地的场景最后是开发运维的敏捷化如果说基础设置平台化和应用架构的现代化是基础的话那么敏捷就是业务实现快速增长的中央引擎通过敏捷化的业务迭代才能够将云边生架构积转的能力输出到最终的用户手上那么今天的主题主要也是与敏捷化相关在接下来的GDPVT当中会重点展开那这里就不再坠述基于以上的介绍的话其实我们认为云边生不仅仅是DevOpsWIFT或者直接去做平台化而是一系列的平台和一些类的方法一些类的实践构成了云边生整体的架构理念Delay提示其实现在我们的整个云边生的架构也在探索下一代的架构该怎么去发展比如说这样敏捷化的话我们也在延伸出标准化比如说如何去在这么多微幅的场景下做到一些标准那么去降低我们的成本去做我们的性能优化那么应用架构的现代化也尝试的去理解怎么去做好分离化这样的话去应对这个5G和AiOT的一个眼睛另外的话在平台化层面上我们也去考虑怎么去利用智能运为或者说云加数加字的方式去做到更好的智能化接下来简单介绍我们在Devov设计上的一个理念严格来讲Devov设计到组织工具团队等方方面面限于篇幅和主题今天重点介绍我们在Devov平台设计上的思考Devov平台的设计的逻辑是一套分层的理念首先Devov平台的基础是原子能力开放中心既有那些用户和平台共同贡献在研发全流通当中最小的执行单元最简单最直观的例子就是代码扫描稍微复杂一点的能力比如说分级部署我们将Devov平台和基于COVID-19的发布平台打通实现了小流量部署单接防部署全流量部署的能力原子开放能力是支持了生命周期的管理最重要的是我们订阅了一套原子能力标准使得原子能力在附用性上有大大的增强例如我们质量架构部门的同时可以将质量准入准出标准固化的原子能力当中还可以去挥度实现一些新的质量方案比如说FTF一种基于流量的新型真的化测试它可以将测试这种化升级为测试自制化那么这样一些能力都可以通过原子能力去提供给中断的业务方据我们统计一下某些常用的原子能力日均使用次数超过了千次接下来是核心的流水线定义我们称之为效能的操作系统它对上承接不同的业务可以定义针对业务自身特性的一些流程对下去衔接各种原子能力通过原子能力来丰富流水线所能提供的场景流水线部分也是我们连接仓库需求服务多环境管理的重要部分在接下来的解评当中会展开讲解流水线这里就不再坠述最后是贴近业务的研发模型一般由业务来基于流水线能力执行定义DiWars平台提供的主要能力在这里主要提前在两方面一方面是试图的管理让用户由统一的试图来关注需求变更以及代码分支的能力现阶段我们主要经历还是聚焦在研发策的活动那么未来的话还会更加关注于在需求度量和变更等不同维度的一个能力另外方面DiWars平台会提供租户管理权限管理通知管理的能力以及支持业务介入的专项方案全面补全平台化的能力在分享了一些我们对Clownative和DiWars的理念之后接下来我们简单介绍一下CSSD也就是上面提到的流水线部分这里我先做一些简单的铺垫那么后面会有我的同事来介绍GVTekton的时间我们登队CSSD的设计有两个原则一个是灵活性一个是磨块化对于灵活性而言我们认识到公司的研发团队是多种多样的研发知识也是各一的那么想要通过固定的模式来完成研发活动是不切实际的那么在丰富的原子能力之上我们是必须要支持自由编排的方式来匹配各种业务场景GVTekton流程引行我们可以很大程度上满足需求其强大的扩展性也为我们持续严禁流水线提供了保障磨块化使流水线设计的第二个原则其实它与面向业务的灵活性而言是一体两面的也就是说我们尽管为业务提供了较高的灵活性但是对平产车而言我们还是希望有能力去推崇一套较为标准的研发使用知识去方便业务的接入和统一我们基于磨块化的思想设计了构建类 测试类部署类 前端类 功能类等不同类型的接入方式并且也在持续扩展当中基于CSCD流水线我们实现了各种上层的业务场景比如说火车发布 滚动发布多环境 计购部署 制动化测试等目前业务已经有大范围的使用了接下来会有我的同事金鸣介绍Tekton以及我们的实践大家好我叫岳金鸣来自这些跳动目前主要负责Pass2BO非常感谢德元前面对Devus您和CSCD系统的介绍接下来以后我给大家分享一下我们基于Tekton构建大规模运原生CSCD系统的一些经验首先对Tekton做个简单的介绍Tekton是一个功能强大且凝活的用于构建CSCD系统的开源框架主要有三个feature第一个是CoreLatv所有流水线定义和运行都是基于CoreLatv的CRD直接通过CoreLatv的CRI和APS Server就可以对它们进行操作第二个是CSCD系统 兵牌框架我们可以据它抽象的CRD定义出任意组合的拍摄烂流水线来完成各种长期下的CSCD任务第三个是Tekton正在打造的完备生态系统包括CRIDashboardCatalog和HUB希望通过生态中的一系列工具来降低诱惑的使用门槛例如CRI是基于CoreLatvCRI购建能够更加高效的跟Tekton交互Dashboard是web页面能够比较直观的看到流水线的执行情况Catalog和HUB是社区共性的流水模板方便大家附用这里简单介绍一下Tekton的逆势背景它源自于Kelitv的子线目Build后来作为独立的开源项目引进目前主要由谷歌Redhead等公司贡献并已经加入CD基因会CD基因会是Ninux基金会下专注在持续交付领域的一个基金会Tekton在社区已经得到比较广泛的使用Kelitv和JankusX中的CSD能力都是基于Tekton接下来介绍一下Tekton的架构Tekton按层级定义了一组KelitvCRD来描述流水线及其运行这样就保证了足够的灵活性途中除了左下角的PepdanController其他都是Kelitv中的资源最小的执行单元是STEP基于一组输入之间后会产生一组输出Task是一组顺序执行的STEP的集合也可以只包含一个STEP一组可以圈形和变形执行的Task构成一条PepdanPepdanRUN是基于一定输入的Pepdan的执行而TaskRUN是基于一定输入的Task执行Tekton最终都是基于GurlasePort来执行流水线一个TaskRUN对应一个Port一个STEP对应Port中的一个Container左下角的PepdanController是Tekton唯一的核心组件它控制着整个流水线的执行过程执行流水线时会创建一个PepdanRUN来管理多个TaskRUNTaskRUN又会管理具体执行的Port一次流水线的执行过程中如果不同任务之间需要共享数据可以通过PV实现数据的传递我们希望打造一套大规模远原生CSD系统来支撑业务的发展由于我们的业务量非常大而且需求比较复杂Tekton只能满足我们前两条需求在大规模上有一定的矩性Tekton完全基于CRD这导致它跟Coreless的偶和非常紧密这种实现其实是一把双刃剑优势是足够的Coreless Latio能够充分利用Coreless能力利于前面提到的直接使用Coreless CI和APS Server劣势是受单个Coreless集群的规模和性能的限制同时也无法满足因资源安全等因素需要独占集群的特殊场景我们的CRD系统叫CodePapana简称CP就是为了解决Tekton在大规模和多集群等方面的命令的挑战这是CP的架构图整体比较简单清晰上面是控制面包含两个核心组件CP Server和CP Controller以及两个外部依赖触触MangoDB和对象存在TLS下面是数据面多个Coreless集群承载着流热线的运行每个集群中都运行着一个Papana Controller来控制该集群中流热线的执行过程CP Server是APS Server对外提供API当流热线被触发时会从MangoDB中获取流热线定义结合触发参数构造出Tactone的Papana Run根据调度侧脸下发到执行的Coreless集群中默认情况下会使用共享集群用户如果对购进集群有安全资源等方面的特殊要求也可以自行注册集群在流热线执行时调度系会把流热线调到用户注册的集群中CP Controller监测各集群中Papana的执行情况将流热线中各阶段最新的状态和日质分别持有化到MangoDB和TOS中具体实现是CP Controller会为每个集群通过Groutine的方式起一个Controller来握起相应集群中Papana Run的状态变化并实施更新到数据库中当Papana执行完后会新起一个Groutine来收集破的日质并持有化到TOS中同时把Papana相关的资源清理掉当集群数量非常大这种一个Groutine处理一个集群的简单方式可能会给CP Controller带来性能问题到时候我们可能会做一些下准策略让一个CP Controller只负责管理一批集群而不是相信在管理所有集群刚刚介绍了流热线执行完后收集并持有化到TOS中这只是针对于逆时日质对于流热线运行过程的实时日质CP Server是直接掉Copalattice的日质接口来获取破的实时日质并对外提供一个WebSocket的实时日质查询接口下面介绍CP的一些重要概念与Task统相比比较接触的Stap Task是复用的但是比较上层的Papana和Papana Run根据产品形态的需求计划成了自己的Papana和Papana Record由于用户并不用关心Task Run所以对用户屏蔽了这个概念同时从提升运用线的角度CP额外增加了两个概念一个是StageStage是一组必行之行任务的集合这样就能够清晰的在流热线中体现出各阶段另一个是WorkspaceWorkspace是用来高效管理一组流热线包括它们使用的代码员以及分组和全线控制的这是一张流热线编排的截图最开始是代码员作为输入接下来就可以通过拖拉拽的方式对阶段和任务进行高效的编排凝固的控制这些任务的串形和并行顺序针对于每个任务都可以添加多个串形之行的步骤任务不仅可以直接从任务模板中选择也可以自定于任务的内容同时我们也可以把这些偏偏好的流热线保存为模板方便后面聚于模板兴敬相同的流热线前面提到我们的目标是打造大规模云原生CSD系统那么这套系统的性能到底如何呢这里有一组压缩的数据3000个Workspace20万条流热线5000万条流热线执行记录在这样的数据量底下能够支撑500多条流热线同时避行执行这里简单列了一些比较耗时的NIST API的数据它们仍然能够保持比较高的QPS和比较低的延迟需要说明一下的是NIST PAPLAN在查询流热线的时候会获取和分析最近一次执行记录因此它的QPS相对Workspace直接查数据库会低很多部分业务还在往这个平台前移的过程中后面我们还会持续优化和提升性能最后分享一下我们的一些经验和总结首先是针对于大规模的扩展性主要有4点经验第一点是使用数据库来存储流热线和流热线执行记录等原数据信息这样就避免了使用CubeLattice来存储的性能问题方便我们充分利用数据库的特性进行性能优化第二点是紧紧使用Tactone作为流热线的执行引擎跟低一点结合起来就能达到流热线原数据和执行分裂的目的第三点是能够注册更多的CubeLattice集群来执行流热线不仅解决单个集群规模和性能的平净而且也能够满足对流热线运行环境有特殊需求的业务场景第四点是流热线能够运行在任何标准的CubeLattice集群上几大的放宽对流热线运行环境的限制这四点结合起来就充分体现针对于大规模的宁和口窥展现其次是针对于大景象的构建速度优化在AI场景中我们经常会遇到非常大的惊吓我们将单个20G的AI现场构建时间从30分钟缩得到5分钟CPE使用Docker开源的工具BuildCade来固定景象由于流热线都是跑在CubeLattice集群中为了安全考虑BuildCade必须在容器中以RuleLittice的模式运行这会导致BuildCade的参数OCI Walker,SnapShorter,默认的FuseOverlyFS不生效从而回头到Latv模式在Latv模式下景象构建的每一层都会复制所以大景象的构建速度会非常满通过FuseDivisePlugin将DVFuse注入容器中这样BuildCade即使在没有特权模式下也能够使用FuseOverlyFS模式最后是提升流热线的运行环境的安全性很多流热线在一个共享的继续中执行不同流热线的port调到同一台主机上有些甚至会拿取一些外部依赖并执行这对整个购进环境的安全提出了很大的挑战为了保证用户的安全需要从多购为渡进行安全加固首先是主机开启安全防护防止上面运行的容器越权攻击其次是VuelLittice的安全加固给执行流热线的port赋予最小权限通过App Armor限制容器对资源的访问通过Sigcom限制容器的系统调用的然后就是一些敏感数据需要及时清理使用NIN時的secret推拉键项或拉鞋代码并在使用后立即删除用来给部署间NIN时共享数据的PVC是主为Dinit回收策略流热线执行完后会自动清理PV中的数据最后通过网络策略来限制访问在CSD场景下流热线的port不需要相互访问和对外提供服务只有从外部拉鞋代码依赖和进向式采货产生流量因此需要禁止东西向流量只允许流入的南百姓流量