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

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的非常好，但是功能还是太基本，没办法满足我们的场景；要么就是在设计上更多的是适用于业务场景，对于我们这种底层基础设施非常不友好。