阿里巴巴超大规模 Kubernetes 基础设施运维体系

一 序言

ASI：Alibaba 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架构的KOK（Kube On Kube）底座。整个架构分层为：

• 元集群（KOK架构底层K）：用于承载Kubernetes业务集群的核心管控组件，将业务集群管控容器化部署，能保证部署方式更加标准，部署效率也会大大提升。
• Control-Plane：就是业务集群核心管控4大件：kube-apiserver/kube-controller-manager/kube-scheduler 和 etcd 集群。
• Add-Ons：Serverless核心功能组件，调度增强组件（统一调度器）、网络组件、存储组件、Workload组件（OpenKruise）、coredns和其他一些旁路组件。
• Data-Plane：节点管控组件，比如containerd、kubelet，kata 等，还有一些其他节点上的插件。

基于ASI整个架构，我们经过不断探索、抽象，将ASI运维体系，抽象成核心几大模块，如下图所示：

• 统一变更管控：这个是我们从ASI的第一天就开始建设的系统能力，因为从阿里巴巴技术发展过程中吸取的经验教训来看，很多重大故障都是由于变更不规范、没评审、没风险卡点导致；
• 集群运维管控：ACK会提供K8S集群全托管的标准产品能力，但是如何/何时做规模化升级的编排、验证、监控是我们需要考虑；并且我们还需要建设合理的备容机制，保证集群的稳定性；
• ETCD运维管控：ETCD也是完全基于ACK的提供的全托管ETCD Serverless产品能力，我们会和ACK同学一起共建ETCD性能优化、备容来更好的服务ASI的超大规模集群；</