【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

• 云基础相关管理，包括可用区的选择，规划和硬件资产的管理

• 节点的管理

• ASI 集群管理

• 公共服务

• 集群运维

• 应用研发

特别是在 ASI 这个场景下，要支撑的业务集群数量庞大，涉及到的研发运维人员众多，功能发布频繁的迭代开发模式以及业务种类繁多带来的运行时的复杂多变，相比其他容器平台来看，ASI 高可用面临更多的挑战，其难度不言而喻。

​

ASI 全局高可用设计

================================================================================

如下图所示，现阶段高可用能力建设整体策略以 1-5-10（故障 1 分种发现、5 分钟定位、10 分钟止损）为目标牵引，注重将能力沉淀到系统或机制中，让 SRE/Dev 能够无差别的 oncall。

​

尽量避免发生问题、尽快发现、定位及恢复问题，是实现目标的关键，为此我们将 ASI 全局高可用体系的实现分三大部分展开：一是基础能力建设；二是应急体系建设；三是通过常态化压测以及故障演练等完成上述能力的保鲜和持续演进。

​

通过 3 个部分的轮转驱动，实现一个 ASI 全局高可用体系的构建，其顶层是 SLO 体系和 1-5-10 应急体系。在应急体系和数据驱动的体系背后，我们建设了大量高可用基础能力，包括防御体系、高可用架构升级、故障自愈体系、以及持续改进机制。与此同时，我们建立了多个基础性平台为高全用体系提供配套能力，如常态化故障演练平台、全链路仿真压测平台、告警平台、预案中心等等。

​

全局高可用基础能力建设

================================================================================

在建设全局高可用能力之前，我们的系统在迅速发展和变化下不断出现事故和险情，需要隔三差五去应急，导致让问题追身的局面，并且追身后没高效应对的手段，面临着几个严峻的挑战：

​

• 如何在架构和能力上去提升我们的可用性，降低系统发生故障的概率和影响面？

• 如何在核心链路性能和架构上做一些突破，能够支撑这么复杂多变的业务场景和业务增长的通用需求？

• 如何让问题不再追身，做好预防工作，避免应急？

• 如何在应急发生时，能够快速发现，快速诊断，快速止损？

针对这些问题，并且总结出以下几个核心原因：

​

• 可用性能力不足：在集团场景下，组件不断在变化，不断增加系统的压力和复杂度，ASI 在生产可用性的能力上缺失，如限流降级、负载均衡等，组件容易乱用造成低级错误，影响集群可用性。

• 系统风控和 pod 保护能力不足：在人为误操作或系统 bug 时, 容易造成业务 pod 无辜受损或者大面积受损。

• 容量风险：集群数量几百，组件接近一百；另外历史问题因 podCIDR 和节点 IP 数的配置，大多 ASI 元集群的节点规模被约束在 128 台以内，随着业务快速发展，对容量风险而言存在较大挑战。

• 单集群规模受限，加上横向扩展能力不足影响业务发展：单集群不断增长规模，以及业务类型变化，组件变化都对单集群支撑的最大规模产生影响，对 SLO 持续稳定产生影响。

1. 高可用基础能力顶层设计

---

针对这些解决的问题，我们做了高可用基础能力的顶层设计，这些基础能力建设整体主要分为几个部分：

​

• 性能优化和高可用架构建设：主要是从性能优化和架构升级的角度来提升整个集群支撑的业务类型和业务量。

• 组件规范全生命周期管理：主要从规范