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

简介： 台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。

作者 |  韩堂、柘远、沉醉
来源 | 阿里巴巴云原生公众号
​

前言

台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。
​
长夜有穷，真水无香。领略过了 K8s“身在江湖”的那种惊心动魄以及它那生态系统的繁花似锦，该是回过头来体味高可用体系境界之美的时候了。毕竟仅能经得起敲打还是不能独步武林的！
​
在 K8s 高可用领域有一个问题被大家所熟知，那就是 K8s 单集群规模带来的 SLO 问题，如何持续保障？今天就以单集群的规模增长带来的高可用挑战来作为引子来给大家一个体感。
​
ASI 单集群规模支撑超过社区的 5000 台，这是个非常有意思且具备极大挑战的事情，对需要进行 K8s 生产化的同学，甚至具备 K8s 生产化经验的同学来说，一定会是个感兴趣的话题。回看 ASI 单集群规模从 100 到 10000 的发展之路，伴随着业务的增长和创新带来的每一次集群规模增长，都在逐步使我们的压力和挑战发生质变。
​

ASI：Alibaba Serverless infrastructure，阿里巴巴针对云原生应用设计的统一基础设施，ASI 是阿里公共云服务 ACK 的阿里集团企业版。

大家知道 K8s 社区只能够支撑五千个节点，当超过这个规模时，会出现各种性能瓶颈问题，比如：

• etcd 出现大量的读写延迟。
• kube-apiserver 查询 pods/nodes 延时很高，甚至导致 etcd oom。
• 控制器无法及时感知数据变化，如出现 watch 数据延迟。

以电商场景为例，100 节点增长到 4 千节点的时候，我们提前针对 ASI apiserver 的客户端和服务端做了大量的性能优化，从 apiserver 客户端的角度优先访问本地 cache，在客户端去做负载均衡；apiserver 服务端主要做了 watch 优化和 cache 索引优化；在 etcd 内核上利用并发读提升单 etcd 集群读处理能力，基于 hashmap 的 freelist 管理新算法提高 etcd 存储上限，基于 raft learner 技术来提高多备能力等等。
​
从 4 千节点增长到 8 千节点，我们又做了 qps 限流管理和容量管理优化、etcd 单资源对象存储拆分、组件规范全生命周期落地通过客户端的规范约束降低对 apiserver 的压力和以及穿透到 etcd 的压力等等。
​
终于迎来 8 千节点增长到上万节点的时刻，我们开始如火如荼地开展 etcdcompact 算法优化；etcd 单节点多 multiboltdb 的架构优化，apiserver 的服务端数据压缩，通过组件治理降低 etcd 写放大等；同时开始打造常态化的压测服务能力，持续回答 ASI 的 SLO。
​
这些例子在高可用挑战中司空见惯，列出的能力也只是其中一小部分，你也许很难看到能力之间的关联和底层的演进逻辑。当然，更多的能力建设沉淀到了我们的系统和机制当中。本篇文章会作为一个开始，以综述的形式分享我们在建设 ASI 全局高可用体系中的几个关键部分，再往后会有针对性地对进行技术点和演进路线的详解。如果大家有什么问题或者希望了解的部分，欢迎在评论区留言。

ASI 全局高可用概述

高可用是个比较复杂的命题，任何日常的变化例如服务升级、硬件更新、数据迁移、流量突增等都可能造成服务 SLO 受损，甚至不可用。
​
ASI 作为容器平台，并非孤立存在，而是与云底层及公共服务形成完备的生态系统。要解决 ASI 的高可用问题，需要纵观全局，找出每层的最优解，最终串联组成最优的整体解决方案。涉及到的层面包括：
​

• 云基础相关管理，包括可用区的选择，规划和硬件资产的管理
• 节点的管理
• ASI 集群管理
• 公共服务
• 集群运维
• 应用研发

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

ASI 全局高可用设计

如下图所示，现阶段高可用能力建设整体策略以 1-5-10（故障 1 分种发现、5 分钟定位、10 分钟止损）为目标牵引，注重将能力沉淀到系统或机制中，让 SRE/Dev 能够无差别的 oncall。  
​
尽量避免发生问题、尽快发现、定位及恢复问题，是实现目标的关键，为此我们将 ASI 全局高可用体系的实现分三大部分展开：一是基础能力建设；二是应急体系建设；三是通过常态化压测以及故障演练等完成上述能力的保鲜和持续演进。 
​

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

全局高可用基础能力建设

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