阿里巴巴超大规模 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 中，帮忙更好的维护用户的 K8s 集群。

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 集群，提供了全托管、免运维的用户体验。这些能力不是 K8s 原生就具备的，而是在大量实践和失败过程中沉淀出来的系统稳定性加固能力。而放眼整个行业，正是阿里巴巴的规模化复杂场景，才能锤炼出大规模场景下的 K8s 运维服务体系。

在讲 ASI 运维体系之前，我先强调一下在做系统能力建设过程的一个重要原则：不重复造轮子，但是也不能完全依赖其他系统的能力。没有哪一款产品、系统能 cover 住所有业务的所有问题（特别是 ASI 这样体量的业务）。依赖上下游链路已经建好的系统能力，但是不会完全依赖，要做好系统分层设计。如果一个系统做好了底层的运维通道，我们一定不会再去做一个运维通道，而是会基于上层运维通道做我们自己业务变更的编排；如果一个系统做好了监控、告警链路的能力，我们会做好监控、告警规则和路由分发的管理。

另外一件非常重要的事情：做稳定性的团队要想做好运维管控系统，就一定要对业务架构有非常全面、深入的了解。稳定性团队不能只做运营，也不能仅仅在架构外面做 1-5-10 能力，这样是很难把控整个架构的稳定性。ASI SRE 虽然是为 ASI 基础设施稳定性兜底的团队，但是很多 SRE 同学都可以独立去对接新的业务，并能决定整个业务上 ASI 的架构。其实很多时候，如果是 SRE 和研发配合去接的业务方，往往问题都少很多，因为两个角色非常互补：研发在技术架构上有很好的判断，SRE 在架构合理性和稳定性风险有很好的判断。

如上图是 ASI 集群部署架构，完全基于 ACK 产品 Infra 架构的 KOK（Kube On Kube）底座。整个架构分层为：

• 元集群（KOK 架构底层 K）：用于承载 K8s 业务集群的核心管控组件，将业务集群管控容器化部署，能保证部署方式更加标准，部署效率也会大大提升。
• 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 的超大规模集群；
• 组件运维管控：ASI 运维体系非常核心的能力建设，Serverless 全托管服务，