南阳做网站公司哪家好,织梦网站安装播放视频插件下载,wordpress 网页特效,廊坊购物网站开发设计简介#xff1a;ASI#xff1a;Alibaba Serverless infrastructure#xff0c;阿里巴巴针对云原生应用设计的统一基础设施。ASI 基于阿里云公共云容器服务 ACK之上#xff0c;支撑集团应用云原生化和云产品的Serverless化的基础设施平台。 作者 | 仔仁、墨封、光南 来源 | …简介ASIAlibaba Serverless infrastructure阿里巴巴针对云原生应用设计的统一基础设施。ASI 基于阿里云公共云容器服务 ACK之上支撑集团应用云原生化和云产品的Serverless化的基础设施平台。 作者 | 仔仁、墨封、光南 来源 | 阿里技术公众号
一 序言
ASIAlibaba Serverless infrastructure阿里巴巴针对云原生应用设计的统一基础设施。ASI 基于阿里云公共云容器服务 ACK之上支撑集团应用云原生化和云产品的Serverless化的基础设施平台。
2021年天猫双十一对于ASI来说又是难忘的一年今年我们又完成了很多“第一次”
第一次全面统一调度电商、搜索、odps离线和蚂蚁业务全面上ASI统一调度架构整个业务核数达到了惊人的数千万核。第一次将搜索业务“无感知”平滑迁移到ASI近千万核的业务业务无感的搬到ASI但是我们却经历了很多个不眠之夜。ASI场景的K8s单集群规模超过万台节点数百万核超越K8S社区的5000台规模不断优化大规模集群的性能和稳定性。中间件服务第一次用云产品架构支持集团业务中间件基于ASI公共云架构将中间件服务平滑迁移到云上用云产品架构支持集团业务实现“三位一体”。
ASI在大规模生产应用的锤炼下不仅沉淀了非常多的K8S稳定性运维能力更是在支持serverless场景下孵化了很多创新能力。如果运维过K8S特别是运维大规模集群的同学一定会有很深的感触把K8S用起来很容易想要用好K8S真心不容易。ASI在使用K8S调度体系架构早期成长阶段也经历过多次血的教训过程中我们持续成长、学习和成熟。例如
一次正常的Kubernetes大版本升级流程在升级Kubelet时把一个集群近千台业务POD全部重建一次线上非标操作将大批量的vipserver服务全部删除幸亏中间件有推空保护才没有对业务造成灾难性影响节点证书过期由于节点自愈组件故障情况误判并且风控/流控规则判断也有误导致自愈组件误将一个集群300节点上的业务全部驱逐
以上列举的各种故障场景即使是专业K8S团队都无法避雷如果是对K8S了解很少的用户肯定更无法预防和规避风险。所以给所有正在使用K8S服务或者想要用K8S服务的用户一个中肯建议不要想着自己就能运维好K8S集群里面有多少坑你真的想象不到专业的人做专业的事让专业产品和SRE团队来实现运维。在这里我也是强烈建议用户使用阿里云容器服务ACK因为我们在阿里巴巴大规模场景下沉淀能力增强、自动化运维和能力都会反哺到ACK中帮忙更好的维护用户的Kubernetes集群。
ASI能运维好这么多庞大K8S集群一定得有“两把刷子”。今天我会给大家详细介绍ASI在为阿里集团构建云原生基础设施和支持阿里云云产品Serverless化方面我们的运维体系和稳定性工程能力。
二 ASI 技术架构形态
在介绍ASI的全托管运维体系之前我花一点篇幅来介绍一下ASI。ASI是基于ACK、ACR之上面向集团和云产品的Serverless化平台旨在支撑阿里巴巴应用云原生化和阿里云产品Serverless化。下面介绍容器服务家族的几位成员ACK、ASK、ACR。 针对阿里巴巴和云产品业务场景在K8s集群功能层面我们会给用户提供增强的能力比如调度能力增强、Workload能力增强、网络能力增强、节点弹性能力增强和多租安全架构等等在集群运维层面提供Serverless化的No Ops体验比如集群大版本升级、组件升级、节点组件升级、节点CVE漏洞修复、节点批量运维等为用户的K8S集群稳定性兜底。
三 ASI全托管运维支撑体系
ASI为大规模K8s集群提供了全托管、免运维的用户体验。这些能力不是Kubernetes原生就具备的而是在大量实践和失败过程中沉淀出来的系统稳定性加固能力。而放眼整个行业正是阿里巴巴的规模化复杂场景才能锤炼出大规模场景下的Kubernetes运维服务体系。
在讲ASI运维体系之前我先强调一下在做系统能力建设过程的一个重要原则不重复造轮子但是也不能完全依赖其他系统的能力。没有哪一款产品、系统能cover住所有业务的所有问题特别是ASI这样体量的业务。依赖上下游链路已经建好的系统能力但是不会完全依赖要做好系统分层设计。如果一个系统做好了底层的运维通道我们一定不会再去做一个运维通道而是会基于上层运维通道做我们自己业务变更的编排如果一个系统做好了监控、告警链路的能力我们会做好监控、告警规则和路由分发的管理。
另外一件非常重要的事情做稳定性的团队要想做好运维管控系统就一定要对业务架构有非常全面、深入的了解。稳定性团队不能只做运营也不能仅仅在架构外面做1-5-10能力这样是很难把控整个架构的稳定性。ASI SRE虽然是为ASI基础设施稳定性兜底的团队但是很多SRE同学都可以独立去对接新的业务并能决定整个业务上ASI的架构。其实很多时候如果是SRE和研发配合去接的业务方往往问题都少很多因为两个角色非常互补研发在技术架构上有很好的判断SRE在架构合理性和稳定性风险有很好的判断。 如上图是ASI集群部署架构完全基于ACK产品Infra架构的KOKKube On Kube底座。整个架构分层为
元集群KOK架构底层K用于承载Kubernetes业务集群的核心管控组件将业务集群管控容器化部署能保证部署方式更加标准部署效率也会大大提升。Control-Plane就是业务集群核心管控4大件kube-apiserver/kube-controller-manager/kube-scheduler 和 etcd 集群。Add-OnsServerless核心功能组件调度增强组件统一调度器、网络组件、存储组件、Workload组件OpenKruise、coredns和其他一些旁路组件。Data-Plane节点管控组件比如containerd、kubeletkata 等还有一些其他节点上的插件。
基于ASI整个架构我们经过不断探索、抽象将ASI运维体系抽象成核心几大模块如下图所示 统一变更管控这个是我们从ASI的第一天就开始建设的系统能力因为从阿里巴巴技术发展过程中吸取的经验教训来看很多重大故障都是由于变更不规范、没评审、没风险卡点导致集群运维管控ACK会提供K8S集群全托管的标准产品能力但是如何/何时做规模化升级的编排、验证、监控是我们需要考虑并且我们还需要建设合理的备容机制保证集群的稳定性ETCD运维管控ETCD也是完全基于ACK的提供的全托管ETCD Serverless产品能力我们会和ACK同学一起共建ETCD性能优化、备容来更好的服务ASI的超大规模集群组件运维管控ASI运维体系非常核心的能力建设Serverless全托管服务最核心的就是各个核心组件都要有相应的研发团队进行功能扩展和运维支持。这样如何定义研发同学的研发模式确保日常运维的稳定性和效率是ASI产品能支持大量业务的关键。所以在ASI成立之初2019年支持集团业务上云我们就建立起了ASI组件中心逐渐定义和优化ASI核心组件的研发、运维模式节点全托管运维管控这块是非常多云产品团队希望容器服务提供的能力特别业务产品团队他们对基础设施非常不了解希望有团队能帮忙将节点运维全托管掉。节点运维能力也是ASI在支撑阿里集团过程中非常重要的能力沉淀我们也将这部分经验输出到售卖区并继续不断优化。云上最大的特点就是资源弹性ASI在售卖区也为云产品用户提供了节点极致弹性能力。1-5-10能力建设云上用户有一个非常重要的特点对故障容忍度非常低。这也给ASI带来了非常大的挑战如何及时发现、排查和恢复问题是我们一直要不断探索的。资源运营备容成本优化一直都是基础设施服务要解的问题我们既要确保服务运行稳定比如不OOM不出现CPU争抢又要降低成本更要降低云产品的服务成本。
接下来我会针对ASI全托管运维体系中关键系统/技术能力的设计思路和具体方案进行阐述向大家呈现我们是如何一步步将大规模Kubernetes全托管运维服务建设起来的。
1 集群全托管运维能力
当我们在运维大规模Kubernetes集群的时候最深的感受就是规模化既会给单个运维操作带来很大的复杂度也会将单个运维操作的风险爆炸半径大大扩大。我们也是经常会被下面的问题挑战
所有变更是不是都有变更风险管控这么多的集群这么多的节点ASI单集群已经超过了上万节点怎么做灰度稳定性风险最小黑屏变更无法杜绝如何把控风险单个运维动作虽然不难但是我们经常面临的是多个运维操作组合的复杂操作系统如何方便的去编排这些运维操作
带着这四个问题接下来我会详细介绍我们如何在实践中不断抽象和优化我们的系统能力并沉淀出目前对ASI全托管服务非常重要的稳定性系统能力。
统一变更风险管控
2019年当我们刚成立ASI SRE团队的时候就在探索如何把控变更带来的风险。当时的稳定性系统能力还非常弱真的是百废待兴新的SRE团队的同学都是从阿里云自研的Sigma调度系统各个子研发团队抽调出来的所以大家对容器、k8s、etcd这些技术都非常精通但是对如何做SRE如何做稳定性都是一脸懵。记得刚开始我们在ASIOps系统当时还叫asi-deploy里接入ChangeFree变更审批都花了23周的时间。面对新的架构Sigma - ASI、新的场景集团业务上云和如此复杂、庞大的Kubernetes业务体量我们也没有太多外界的经验可以借鉴。
当时我们想的是靠系统来做变更风险管控肯定是来不及的集团业务全面上云已经开展起来大量新的技术方案出来、大量线上变更只能先靠“人治”。所以我们就在整个ASI团队宣导任何变更都要让SRE审批但是SRE并不能了解ASI所有技术架构细节做完善的风险评估。为此我们又开始组建“变更评审”会议在评审会上邀请每一个领域的专家同学参与进行变更方案的风险评审。也是因为这个变更评审机制帮助ASI在变更风险阻断系统能力非常不足的情况下稳定的渡过了那段“艰难”的时期。ASI的变更评审会议也一直延续到今天没有封网特殊时期都会如期召开。也是那段时间SRE通过参加每一次线上变更的审批也沉淀了非常多的安全生产规则 与此同时我们开始将这些已经非常明确的变更风险阻断的规则实现到ASIOps系统中。刚开始是实现ASI底层系统架构层面的风险阻断能力后来发现很多变更只通过底层ASI的指标/探测是没办法发现问题的需要有一种机制能联动上层业务系统来触发业务层面的一些风险阻断规则判断这样才能尽可能的确保我们的变更不会对上层业务带来影响。所以我们开始在ASIOps实现变更风险规则库的管理并实现了一种webhook的机制来联动上层业务方的巡检检测/E2E测试。 ASI有了这套在线变更风险阻断系统能力之后我们再也没有出现过封网期私自变更变更不做灰度、不验证等这类触犯变更红线的行为。
变更灰度能力
从实际经验来看每一次线上变更不管我们前期方案评审多么仔细、多么严格风险阻断做的多么完善运维功能写的多好。代码上线之后总是会出现我们“意想不到”的情况。对于已经知道的事情我们一定会做的很好可怕的是我们考虑不到的事情这不是能力问题现实架构他就是足够复杂。
所以功能上线一定要灰度。当然我们还要保证变更动作的确定性不能说张三变更是这样顺序去灰度的李四同样的变更又是另外的一个灰度顺序。ASI变更灰度能力我们也是经过了好多次迭代。
Sigma时代集群都是跨机房/跨Region部署的所以如此庞大的业务体量Sigma也只需要10个不到的集群来承载。对于研发来说因为集群个数不多集群做什么用的、业务类型是怎样的都很清楚所以发布成本不是很高当然由于爆炸半径太大发布小问题也是不断。但是演进到ASI架构之后集群规划是严格按照Region/机房来进行切割的并且由于K8S集群本身可伸缩性问题无法像Sigma集群那样一个集群能承载十几万的节点K8S社区当时给的是单集群规模不能超过5000节点虽然现在ASI已经优化到单集群上万节点但是过大的集群在稳定性与爆炸半径方面的风险也更高。在这种架构形态之下ASI集群的个数肯定会远远大于Sigma集群的个数。研发同学都还在Sigma后期、ASI早期时代很多研发习惯还是沿用Sigma当时的模式发布工具还是Sigma时代的产物没办法支持大规模K8S集群精细化组件发布。各个团队的研发每次发布也都胆战心惊也怕出问题。
当时在集团ASI集群个数还没有增长上来之时我们就已经意识到要去解决变更确定性的问题。ASI这么多集群几十万的节点如果让各个研发同学去决定如何变更肯定是要出问题的。但是当时我们的系统能力又非常不足也没办法很智能的通过综合判断各种条件来为研发同学的变更确定一条最佳的变更灰度顺序。那怎么办呢系统不牛逼但是也得要解决问题啊。所以我们提出了一个pipeline的概念由SRE主导和核心研发TL一起确定线上核心集群的发布顺序定义为一条pipeline然后所有研发在做组件升级的时候必须要绑定这条pipeline发布的时候就可以按照我们规定好的集群顺序来进行灰度发布了这就是pipeline概念的由来。这一个“看起来很low”的功能在当时消耗了我们非常大的精力投入才做出一个初版。不过当我们“满怀信心”把pipeline推广给研发同学用的时候却没有收到我们想象中的“鲜花和掌声”而是很多“吐槽和优化建议”。所以我们改变推广策略逐步小范围推广、逐步修正、然后大范围推广直到大家完全接受。现在pipeline已经成为了ASI研发同学必不可少的发布工具了。现在想起来也觉得蛮有意思的。也让我们明白一个道理任何新的功能不能“闭门造车”一定要从我们的用户角度出发来进行设计、优化只有用户满意才能证明我们系统/产品的价值。
下图就是我们按照测试-小流量-日常-生产这个顺序为研发定义的集团核心交易集群的发布顺序 静态pipeline编排ASI集群顺序的能力在当时只支持集团为数不多的ASI集群时问题还不大。但是当ASI业务扩展到了阿里云云产品之后特别是我们和Flink产品一起孵化出了ASI硬多租VC架构之后一个用户一个小的集群集群数量陡增这种人工编排集群顺序就暴露很多问题了
更新不及时新增了一个集群但是没有通知相关同学没有加到对应的pipeline自动适配能力不够ASI新接入了一个云产品需要人工新加一条pipeline经常更新不及时维护成本高随着业务越来越多各个研发owner要自己维护非常多条pipeline扩展能力不足pipeline顺序不能动态调整ASI支持云产品之后有一个非常重要的需求就是按照GC等级进行灰度静态pipeline完全无法支持。
基于上述静态pipeline总总不足我们也是早就开始了技术方案的优化思考和探索。ASI核心是资源调度我们的调度能力是非常强的特别是现在集团做的统一调度项目将集团电商业务、搜索业务、离线业务和蚂蚁业务全部用统一的调度协议上了ASI。我就在想ASI统一调度器是资源cpu、memory的调度集群信息、Node数量、Pod数量、用户GC信息也都是“资源”为什么我们不能用调度的思想去解决ASI集群灰度顺序编排的问题呢所以我们参考了调度器的设计实现了Cluster-Scheduler将集群的各种信息整合起来进行打分、排序得出一条集群pipeline然后提供给研发同学来进行灰度发布。 Cluster-Scheduler实现了一种“动态”pipeline的能力能很好的解决静态pipeline碰到的各种问题
组件灰度发布的时候通过Cluster-Scheduler筛选的集群范围肯定不会漏集群集群发布顺序按照GC等级来进行权重设置也能根据集群的规模数据来动态调整集群的权重研发发布的时候不需要再维护多条静态pipeline只需要选择组件发布范围会自动进行集群发布顺序编排。
当然静态pipeline有一个很大的优点集群发布顺序可以自助编排在一些新功能上线场景中研发需要有这种自助编排能力。所以未来我们也是静态/动态pipeline一起配合使用互相补充。
集群webshell工具
SRE在做稳定性风险把控的时候一定是希望所有的变更都是白屏化和在线化。但是从我们运维K8S的实际情况来看没办法将所有的运维操作都白屏化来实现。我们又不能直接将集群证书提供给研发同学一是会存在权限泄漏安全风险二是研发在本地用证书操作集群行为不可控风险不可控。ASI初期也出现过多次在本地用kubectl工具误删除业务Pod的行为。虽然我们无法将K8S所有运维操作都白屏化在系统上提供给研发使用但是我们可以将kubectl工具在线化提供给研发来使用然后基于在线化工具提供稳定性、安全性加固、风控等能力。
所以我们在Ops系统里提供了集群登陆工具webshell研发可以先按“最小可用”原则申请集群资源访问权限然后通过webshell中去访问集群进行相应的运维操作。在的webshell中我们会将用户的所有操作记录下来上传到审计中心。 在线webshell对比用户本地证书访问集群我们做了非常多的安全/稳定性加固
权限精细化管控权限与用户绑定有效期、权限范围严格管控安全不会给用户提供证书所以不会出现证书泄漏的问题审计所有操作都有审计风控检测危险操作发起在线审批之后再运行操作。
变更编排能力
前面讲的风险阻断、变更灰度和黑屏变更收敛都是在解决ASI稳定性问题。但是谁又能帮助解决我们SRE同学面临的挑战呢
做稳定性的同学都知道只有将变更白屏化/在线化之后我们才能对这些变更中心化管控把控变更风险。但是对于ASI这种非常庞大复杂的基础设施服务来说变更场景繁多、复杂。我们SRE负责整个ASIOps运维管控平台的建设既要面对每天繁重的运维工作还要建系统更要命的是我们的同学都是后端开发工程师出身Ops系统需要做前端界面写前端是后端工程师的梦魇经常是一个后端功能1h写完前端页面要画至少一天。
SRE团队是一个技术服务团队不仅仅要让我们的服务方满意更要让我们自己满意。所以我们在搞系统能力建设的过程中一直在探索怎么降低运维系统开发的成本。大家应该也知道运维能力和业务系统能力不同运维操作更多是多个操作编排起来的一个综合操作比如解决线上ECS上ENI网卡清理的问题完整的运维能力是首先在节点上执行一个扫描脚本将泄漏的ENI网卡扫描出来然后是将扫描出来的泄漏的ENI网卡作为入参传给清理ENI网卡的程序最后ENI网卡清理完成上报相应的状态。所以我们当时就想做一个事情实现一套运维操作编排引擎能快速的将多个单个独立的运维操作编排起来实现复杂的运维逻辑。当时我们也调研了很多编排工具比如tekton、argo这类的开源项目。发现要么是项目PR的非常好但是功能还是太基本没办法满足我们的场景要么就是在设计上更多的是适用于业务场景对于我们这种底层基础设施非常不友好。
所以我们决定取现在已有编排工具的精华参考他们的设计实现ASI自己的一套运维编排引擎工具。这就是ASIOps中Taskflow编排引擎的由来架构设计如下图所示 PipelineController维护任务间的依赖信息TaskController任务状态信息维护TaskScheduler任务调度Task/Worker任务执行
举一个节点扩容功能的例子如果是单独实现一套节点全生命周期管理的功能所有的操作功能都要自己写。但是在使用了Taskflow编排能力之后只需要实现3个executor执行器逻辑Ess扩容、节点初始化、节点导入。Taskflow会将这3个executor执行流串联起来完成一次节点扩容操作。 目前Taskflow这套编排引擎在ASIOps内被广泛使用覆盖了诊断、预案、节点导入导出、VC集群开服、一次性运维、发布等场景也大大提升了新的运维场景系统能力开发的效率。 经过两年多的锻炼SRE团队的核心研发同学基本都是“全栈工程师”精通前、后端研发。特别是前端界面研发现在不仅没有成为我们团队的负担相反成为了我们团队的优势。很多系统能力都需要前端界面暴露给用户来使用而在ASI这个绝大部分研发都是后端工程师的团队SRE团队前端开发资源成为了我们非常重要的“竞争力”。也充分证明了技多不压身。
小结
关于ASI集群全托管运维能力我这边核心介绍了在系统能力实现上是如何做变更风险阻断、变更编排、变更灰度和收敛黑屏变更。当然我们在ASI管控全托管层面做的远远不止这些系统能力还有非常多次的架构升级的大型线上变更正是因为我们有如此多场景积累才能沉淀出很多重要的系统能力。
2 组件全托管运维能力
关于ASI组件全托管能力我们之前已经发表过一篇文章进行详细介绍ASI 组件灰度体系建设大家有兴趣可以详细看一下确实在ASI如此大规模场景下才会有的技术和经验的沉淀。所以我这里就不做过多的技术方案的介绍更多是介绍我们技术演进的过程。ASI在组件灰度能力建设的分享也入选了2020年KubeCon topic《How we Manage our Widely Varied Kubernetes Infrastructures in Alibaba》感兴趣的同学可以去找一下相关的视频。
ASI全托管模式下组件全托管能力是和目前半托管容器服务云产品一个非常重要的区别ASI会负责Kubernetes集群中核心组件维护工作研发、问题排查和运维。这个其实也是和ASI起源有关ASI起源于集体业务全面上云时期我们提供一个大集群公共资源池的模式让业务逐渐从Sigma架构迁移上ASI。对于集团业务来说肯定不会去维护K8S集群以及集群里的各种组件所以这块就完全由ASI团队来负责也让ASI逐渐孵化出了组件全托管的系统能力。 如上图ASI整个架构的各种层面的组件现在都是基于ASIOps进行统一的变更灰度编排管理。其实在现在看来ASI的所有组件放在一个平台来维护并且统一来进行灰度能力建设是非常理所当然的事情。但是在当时我们也是经过了非常长时间的“斗争”才让今天的架构变得如此合理。在多次激烈的探讨和各种来自稳定性的压力背景下我们终于探索出了一个比较符合目前K8S架构的顶层设计 IaC组件模型利用K8S声明式的设计来将所有ASI组件类型的变更全部改为面向终态的设计统一变更编排组件变更最重要的是灰度灰度最重要的是集群/节点灰度顺序所有组件都需要变更灰度编排
组件云原生改造原来节点基于天基的包变更管理改造成K8S原生Operator面向终态的设计这样节点组件实现基本的组件变更通道、分批、暂停等能力。由上层的Ops系统来实现组件版本管理、灰度变更编排等。
经过两年多的发展ASI体系下组件变更也完全统一在一个平台下并且基于云原生的能力也建设出了非常完善的灰度能力 3 节点全托管运维能力
前面我也介绍了我们在建设系统能力时不会重复造轮子但是也不能完全依赖其他产品的能力。ACK提供了节点生命周期管理的基本产品能力而ASI作为ACK之上的Serverless平台需要在ACK基本产品能力之上建设规模化运维能力。从Sigma时代到ASI支持集团超大统一调度集群过程中ASI沉淀了非常多规模化运维节点的能力和经验。接下来介绍一下我们在售卖区如何建设节点全托管能力建设起来。
节点全生命周期定义
要建设比较完善的节点全托管运维能力我们首先要梳理清楚节点全生命周期的每一个阶段需要做哪些事情如下图我们将节点全生命周期大致分为5个阶段
节点生产前售卖区比较复杂的场景是每一个云产品都有一套或多套资源账号还有很多需要自定义ECS镜像。这些都需要在新业务接入时进行详细定义节点导入时集群节点导入时需要建设节点创建/扩容/导入/下线等操作节点运行时节点运行时往往是问题最多的阶段这块也是需要重点能力建设的阶段如节点组件升级、批量执行脚本能力、cve漏洞修复节点巡检、自愈能力等等节点下线时在节点成本优化、内核cve漏洞修复等场景下都会需要节点腾挪、下线等规模化节点运维能力节点故障时在节点故障时我们需要有节点问题快速探测能力、问题诊断能力和节点自愈能力等。节点能力建设大图
ASI售卖区节点托管能力建设1年多已经承载了售卖区所有上ASI的云产品并且大部分核心能力都已经建设比较完善节点自愈能力我们也在不断优化完善中。 节点弹性
在云上一个最大的特点就是资源弹性节点弹性能力也是售卖区ASI给云产品用户提供的一个非常重要的能力。ASI的节点弹性能力依靠ECS资源的极致弹性能按照分钟级来进行ECS资源购买和释放帮忙云产品精细化控制资源成本。视频云云产品目前就在ASI上重度依赖ASI节点弹性能力进行资源成本控制。视频云平均一天节点弹性3000多次并且经过不断优化ASI节点弹性能达到几分钟内完全拉起视频云业务。 在节点弹性上我们在节点整个生命周期中都进行了性能优化
管控层面通过控制并发度可以快速完成几百台ECS的弹性任务处理 组件部署优化 daemonset组件全部修改为走Region vpc内部地址拉取rpm组件采用ECS镜像内预装模式并进行节点组件部署序编排来提升节点组件安装速度最后就是yum源带宽优化从原来走共享带宽转为独占带宽模式避免被其他rpm下载任务影响我们节点初始化。业务初始化引入dadi镜像预热技术节点导入过程中可以快速预热业务镜像目前能达到10g大小镜像的业务拉起只需要3min左右。
4 1-5-10 能力建设
ASI全托管模式的服务最重要的还是我们能为云产品用户进行底层集群稳定性问题进行兜底。这个对ASI的1-5-10能力要求就非常高接下来主要给大家介绍3个核心稳定性能力
风控在任何场景下ASI都应该具备踩刹车的能力KubeProbe快速探测集群核心链路稳定性问题自愈庞大的节点规模非常依赖节点自愈能力。
风控
在任何时刻ASI一定要有“踩刹车”的能力不管是我们自己同学误操作还是上层业务方误操作系统必须有及时止损的能力。在文章开头我也介绍了ASI曾经发生过的大规模重启、误删pod的事故。正因为之前血泪教训才造就了我们很多风控能力的诞生。 KubeDefender限流对一些核心资源比如pod、service、node的操作特别是Delete操作按照1m、5m、1h和24h这样的时间维度设置操作令牌。如果令牌消耗完就会触发熔断。UA限流按时间维度设置某一些服务UserAgent来标识操作某一些资源的QPS防止访问apiserver过于频繁影响集群稳定性。UA限流能力是ACK产品增强能力。APF限流考虑apiserver的请求优先级和公平性避免在请求量过大时有一些重要控制器的被饿死。K8S原生增强能力。
KubeProbe
KubeProbe是ASI巡检/诊断平台经过不断迭代目前我们演进了两种架构中心架构和Operator常驻架构。KubeProbe也中了今年上海KubeCon议题感兴趣的同学到时候也可以参加一下上海KubeCon线上会议。
1中心架构
我们会有一套中心管控系统。用户的用例会通过统一仓库的镜像的方式接入使用我们通用的sdk库自定义巡检和探测逻辑。我们会在中心管控系统上配置好集群和用例的关系配置如某用例应该执行在哪些集群组上并做好各种运行时配置。我们支持了周期触发/手动触发/事件触发(如发布)的用例触发方式。用例触发后会在集群内创建一个执行巡检/探测逻辑的Pod这个pod里会执行各种用户自定义的业务巡检/探测逻辑并在成功和失败后通过直接回调/消息队列的方式通知中心端。中心端会负责告警和用例资源清理的工作。 2常驻Operator架构
对于某些需要724小时不间断的高频短周期探测用例我们还实现了另外一套常驻分布式架构这套架构使用一个集群内的ProbeOperator监听probe config cr变化在探测pod中周而复始的执行探测逻辑。这套架构完美复用了KubeProbe中心端提供的告警/根因分析/发布阻断等等附加功能同时使用了标准Operator的云原生架构设计常驻体系带来了极大的探测频率提升(因为去掉了创建巡检pod和清理数据的开销)基本可以做到对集群的724小时无缝覆盖同时便于对外集成。
另外还有一个必须要提的非常重要的点那就是平台只是提供了一个平台层的能力支持真正这个东西要起作用还是要看在这个平台上构建的用例是否丰富能不能方便的让更多人进来写各种巡检和探测用例。就像测试平台很重要但测试用例更重要这个道理一样。一些通用的workload探测组件探测固然能发现很多管控链路上的问题但是更多的问题甚至业务层的问题暴露依赖于基础设施和业务层同学的共同努力。从我们的实践上来说测试同学和业务同学贡献了很多相关的检查用例比如ACKASK的创建删除全链路探测巡检金丝雀业务全链路扩容用例比如本地生活同学的PaaS平台应用检查等等也得到了很多稳定性上的结果和收益。目前巡检/探测用例有数十个明年有机会破百巡检/探测次数近3000万次明年可能会过亿。可以提前发现99%以上的集群管控问题和隐患效果非常好的。 自愈
当我们的业务规模达到一定规模如果仅仅靠SRE团队线上Oncall去解决问题肯定是远远不够的一定需要我们系统具备非常强的自愈能力。K8S面向终态的设计通过Readiness、Liveness机制能帮忙业务Pod快速自愈。但是当节点故障时我们也需要节点能快速自愈或者能快速将节点上的业务驱逐到正常的节点上。ACK产品也提供了自愈能力ASI在这个之上做了很多基于ASI业务场景的能力增强。如下是我们售卖区节点自愈能力的架构设计 随着ASI业务形态的发展未来我们将在如下场景下进行节点自愈能力增强
诊断、自愈规则更加丰富目前的诊断、自愈规则很多场景下都没有覆盖需要不断优化覆盖更多节点故障场景基于节点池的精细化的自愈风控、流控节点自愈的前提是不能让现状变的更糟所以我们需要在做自愈时做更加精确的判断节点自愈能力与上层业务打通不同业务形态对节点自愈的要求不同。比如Flink业务都是任务类型遇到节点问题需要我们尽快驱逐业务触发任务重建最怕的就是任务“半死不活”中间件/数据库业务都是有状态服务不允许我们随便驱逐业务但是我们如果把自愈能力与上层业务逻辑打通就可以做到将节点故障上透给业务让业务来决策是否要自愈以及业务如何自愈。
四 未来展望
ASI 作为容器服务 ACK 在阿里巴巴内部持续打磨的统一Serverless基础设施正在持续构建更强大的全自动驾驶 Kubernetes 集群提供集群、节点、组件的全托管能力并一如既往地输出更多经验到整个行业。ASI 作为阿里集团、阿里云基础设施底座为越来越多的云产品提供更多专业服务托管底层 Kubernetes 集群屏蔽复杂的 Kubernetes 门槛、透明几乎所有的基础设施复杂度并用专业的产品技术能力兜底稳定性让云产品只需要负责自己的业务专业的平台分工做专业的事。
原文链接 本文为阿里云原创内容未经允许不得转载。
