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

所以，我们决定取现在已有编排工具的精华，参考他们的设计，实现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系统来实现组件版本管理、灰度变更编排等。