小米科技|阿里巴巴超大规模 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的超大规模集群; 组件运维管控:ASI运维体系非常核心的能力建设 , Serverless全托管服务 , 最核心的就是各个核心组件都要有相应的研发团队进行功能扩展和运维支持 。 这样如何定义研发同学的研发模式 , 确保日常运维的稳定性和效率是ASI产品能支持大量业务的关键 。 所以在ASI成立之初(2019年支持集团业务上云)我们就建立起了ASI组件中心 , 逐渐定义和优化ASI核心组件的研发、运维模式; 节点全托管运维管控:这块是非常多云产品团队希望容器服务提供的能力 , 特别业务产品团队 , 他们对基础设施非常不了解 , 希望有团队能帮忙将节点运维全托管掉 。 节点运维能力也是ASI在支撑阿里集团过程中非常重要的能力沉淀 , 我们也将这部分经验输出到售卖区 , 并继续不断优化 。 云上最大的特点就是资源弹性 , ASI在售卖区也为云产品用户提供了节点极致弹性能力 。1-5-10能力建设:云上用户有一个非常重要的特点 , 对故障容忍度非常低 。 这也给ASI带来了非常大的挑战 , 如何及时发现、排查和恢复问题 , 是我们一直要不断探索的 。资源运营:备容 , 成本优化一直都是基础设施服务要解的问题 , 我们既要确保服务运行稳定(比如不OOM , 不出现CPU争抢) , 又要降低成本 , 更要降低云产品的服务成本 。接下来我会针对ASI全托管运维体系中关键系统/技术能力的设计思路和具体方案进行阐述 , 向大家呈现我们是如何一步步将大规模Kubernetes全托管运维服务建设起来的 。