阿里巴巴|阿里巴巴超大规模 Kubernetes 基础设施运维体系揭秘( 四 ) kubernetes|阿里云|中间件

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 ，然后提供给研发同学来进行灰度发布。