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

[](()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. 高可用基础能力顶层设计

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

?

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

• 组件规范全生命周期管理：主要从规范的角度在组件的整个生命周期去落地，从出生启用和集群准入开始，到每一次变更，到下线整个生命周期都要防止组件乱用、野蛮生长、无限膨胀，控制组件在系统可承受范围之内。

• 攻防体系建设：主要从 ASI 系统本身触发，在从攻击和防御的角度来提升系统的安全，防御和风控能力。

下面针对我们的一些痛点进行几个关键能力建设的描述。

?

[](()2. K8s 单集群架构的痛点

• 对 ApiServer 的掌控能力不够，应急能力不足，我们自己的经历，历次集群 Master 出现异常的次数超过 20+，历次恢复时间最长超过 1 小时。

• ApiServer 是 APIServer 集群的单点，爆炸半径大。

• 单集群规模大， Apiserver 内存水位比较高，压力来源于频繁的查询，写入更多更大的资源对象。

• 在业务层缺少跨机房的容灾能力，当 ASI 不可用的时候，只能依赖 ASI 的恢复能力。

• 集群规模的持续扩大，离线任务的大量创建和删除对集群的造成更大压力。

这里面从两个大的角度可以去提高集群架构的可用性，除了在单集群进行架构优化以及性能突破外，还要通过多集群这样的横向扩展能力去支撑更大的规模。

?

• 一是通过联邦这样的多集群能力来解决单集群的横向扩展能力以及单地域跨集群容灾能力。

• 另外一个单集群本身的架构还可以从隔离和优先级策略的架构角度来进行差异化 SLO 保障。

[](()3. ASI 架构升级落地

[](()1）APIServer 多路架构升级

核心方案就是通过对 apiserver 进行分组，通过不同的优先级策略进行对待，从而对服务进行差异化 SLO 保障。

?

• 通过分流以降低主链路 apiserver 压力（核心诉求）

• P2 及以下组件接入旁路 apiserver，并可以在紧急情况（如自身稳定性收到影响）下，做整体限流。

• 旁路 apiserver 配合主链路做蓝绿、灰度（次级诉求）

• 旁路 apiserver 可以使用独立版本，增加新功能灰度维度，如使用独立的限流策略，如开启新的 feature 功能验证。

• SLB 灾备（次级诉求）

• 旁路 apiserver 可以在主 apiserver 发生异常时，对外提供服务（需 controller 自行切换目标地址）。

[](()2）ASI 多集群联邦架构升级

目前张北中心的一个机房就几万节点，如果不解决多集群的管理问题，带来的问题如下：

?

• 容灾层面：把核心交易应用的中心单元部署在一个集群的风险是很大的，最坏情况下集群不可用导致整个应用服务不可用。

• 性能层面：对于业务来说，如因核心应用在某一时点使用时极其敏感而设定各种单机最大限制、CPU 互斥独占保证，如果都部署在一个集群的话，会因为集群节点规模限制，导致应用发生堆叠，造成 cpu 热点，性能不满足要求；对于 ASI 管控 Master 来说，单集群无限制扩大，性能总会出现瓶颈，总有一天会无法支撑。

• 运维层面：当某个应用扩容发现没资源，SRE 还得考虑节点加到哪个集群，额外加大了 SRE 集群管理的工作。

因此 ASI 需要达成统一的多集群管理解决方案，帮助上层各个 Pass、SRE、应用研发等提供更好的多集群管理能力，通过它来屏蔽多集群的差异、方便的进行多方资源共享。

?

ASI 选择基于社区联邦 v2 版本来开发满足我们的需求。

?

[](()4. K8s 集群遭遇规模增长带来的极大性能挑战

在一个大规模的 K8s 集群中性能会遇到哪些问题呢？

?

• 首先是查询相关问题。在大集群中最重要的就是如何最大程度地减少 expensive request。对百万级别的对象数量来说，按标签、namespace 查询 Pod，获取所有 Node 等场景时，很容易造成 etcd 和 kube-apiserver OOM 和丢包，乃至雪崩等问题发生。

• 其次是写入相关问题。etcd 适用场景是读多写少，大量写请求可能会导致 db size 持续增长、写性能达到瓶颈被限速、影响读性能。如大量的离线作业需要频繁的创建和删除 pod，通过 ASI 链路对 pod 对象的写放大，最终对 etcd 的写压力会放大几十倍之大。

• 最后是大资源对象相关问题。etcd 适合存储较小的 key-value 数据，在大 value 下，性能急速下降。

[](()5. ASI 性能瓶颈突破

[](()ASI 性能优化的方向

ASI 的性能优化可以从 apiserver 客户端、apiserver 服务端、etcd 存储 3 个方面来进行优化。

?

• 客户端侧，可以做 cache 优化，让各个 client 优先访问本地 informer cache，也需要做负载均衡优化，主要包括对 apiserver,etcd 的负载均衡。同时针对客户端的各种优化，可以通过组件性能规范，在组件启用，准入的时候进行校验是否满足。

• APIServer 侧，可以从访问层，缓存层，存储层 3 个层次进行优化。在缓存层，我们重点建设了 cache 的索引优化以及 watch 优化，在存储层上重点通过 snappy 压缩算法对 pod 进行数据压缩，在访问层上重点建设了限流能力。

• etcd 存储侧的优化，我们也从几个方面做了很多工作，包括 etcd 内核层面各种算法优化工作，还有通过将不同资源拆分到不同 etcd 集群的能力实现了基本的水平拆分能力，同时也在 etcd server 层做 multi boltdb 的扩展能力提升。

[](()6. K8s 集群的预防能力薄弱

在 K8s 中，kube-apiserver 作为统一入口，所有的控制器/client 都围绕 kube-apiserver 在工作，尽管我们 SRE 通过组件的全生命周期进行规范约束卡点改进，比如通过在组件的启用和集群准入阶段进行了卡点审批，通过各个组件 owner 的全面配合改造后，大量的低级错误得到防范，但还是有部分控制器或部分行为并不可控。

?

除了基础设施层面的故障外，业务流量的变化，是造成 K8s 非常不稳定的因素，突发的 pod 创建和删除，如果不加以限制，很容易把 apiserver 打挂。

?

另外非法的操作或代码 Bug 有可能造成业务 pod 影响，如不合法的 pod 删除。

?

结合所有风险进行分层设计，逐层进行风险防控。

?

[](()7. ASI 单集群的预防能力加强

[](()1）支持 API 访问层的多维度（resource/verb/client）精细化限流

社区早期采用的限流方式主要通过 inflight 控制读写总体并发量，我们当时在 apf 没有出来之前就意识到限流能力的不足，没有能力去对请求来源做限流。而 apf 通过 User 来做限流（或者说要先经过 authn filter）存在一些不足，一方面因为 Authn 并不是廉价的，另外一方面它只是将 API Server 的能力按配置来做分配，并不是一种限流方案和应急预案。我们需要紧急提供一种限流能力，以应对紧急情况，自研了 ua limiter 限流能力，并基于 ua limiter 简单的配置方式实现了一套限流管理能力，能够很方便在几百个集群当中进行默认限流管理，以及完成应急限流预案。

?

下面是我们自研的 ua limiter 限流方案和其他限流方案的详细对比：

?

ua limiter、APF、sentinel 在限流上的侧重点是不一样的：

?

• ua limiter 是根据 ua 提供一个简单的 QPS hard limit。

• apf 更加侧重于并发度的控制，考虑的是流量的隔离和隔离后的公平性。

• sentinel 功能全面，但是对于公平性的支持并没有 APF 全面，同时复杂度有一些过高。

考虑我们现阶段的需求和场景，发现 ua limiter 落地最为合适，因为我们通过 user agent 的不同，来对于组件进行限流。当然后续进行更加精细的限流，还是可以考虑结合使用 APF 等方案进一步加强。

?

限流策略如何管理，数百套集群，每套集群规模都不太一样，集群节点数、pod 数都是不同的，内部组件有近百个，每个组件请求的资源平均有 4 种，对不同资源又有平均 3 个不同的动作，如果每个都做限流，那么规则将会爆炸式增长，即便做收敛后维护成本也非常的高。因此我们抓最核心的：核心资源 pod\node、核心动作（创建、删除、大查询）；最大规模的：daemonset 组件、PV/PVC 资源。并结合线上实际流量分析，梳理出二十条左右的通用限流策略，并将其纳入到集群交付流程中实现闭环。

?

当新的组件接入，我们也会对其做限流设计，如果比较特殊的，则绑定规则并在集群准入和部署环节自动下发策略，如果出现大量的限流情况，也会触发报警，由 SRE 和研发去跟进优化和解决。

?

[](()2）支持业务 POD 级别的精细化限流

所有 pod 相关的操作都会对接 Kube Defender 统一风控中心，进行秒级别、分钟级、小时级、天级别的流控。该全局风控限流组件，实行中心端部署，维护各场景下的接口调用限流功能。

?

defender 是站在整个 K8s 集群的视角，针对用户发起的或者系统自动发起的有风险的操作进行防护（流控、熔断、校验）和审计的风控系统。之所以做 defender，主要从以下几个方面考虑：

?

• 类似 kubelet/controller 这样的组件，在一个集群中存在多个进程，任一单一进程都无法看到全局的视图，无法进行准确的限流。

• 从运维视角，分散在各个组件中的限速规则难以配置与审计，当部分操作因为限流原因失败时，排查链路过长影响问题定位的效率。

• K8s 面向终态的分布式设计，每个组件都有决策的能力，那么就需要一个集中的服务对那些危险决策进行风控。

defender 的框架图如下所示：


• defender server 是 K8s 集群级的服务，可以部署多个，其中一个 active，其余 standby。

• 用户可以通过 kubectl 配置风控规则。

• K8s 中的组件，例如 controller，kubelet，extension-controller 等，都可以通过 defender sdk 接入 defender（改动很小），在进行危险操作前请求 defender 进行风控，根据风控结果决定是否继续该危险操作。defender 作为一个集群级的风控防护中心，为 K8s 集群的整体稳定性进行保驾护航。

[](()3）数字化容量治理

在只有几个 core 集群的场景下，依靠专家经验管理容量完全可以轻松搞定，但随着容器业务的快速发展，覆盖泛交易、中间件、新生态、新计算以及售卖区等业务在接入 ASI，短短几年时间就发展了几百个集群，再发展几年数以千计万计？如此多的集群依靠传统的人肉资源管理方式难以胜任，人力成本越来越高，特别是面临诸如以下问题，极易造成资源使用率低下，机器资源的严重浪费，最终造成部分集群容量不足导致线上风险。

?

• 组件变更不断，业务类型和压力也在变化，线上真实容量（到底能扛多少 qps）大家都不得而知，当业务需要增大流量时是否需要扩容？是否横向扩容也无法解决问题？

• 早期申请容器资源随意，造成资源成本浪费严重，需要基于容器成本耗费最小化明确指导应该合理申请多少资源（包括 cpu，内存及磁盘）。同一个地域，同一个元集群的业务集群，一个集群浪费了资源就会造成其他集群资源的紧张。

在 ASI 中，组件变化是常态，组件容量如何自适应这种变化也是一个非常大的挑战。而日常的运维及诊断须要有精准的容量数据来作为备容支撑。

?

因此我们决定通过数据化指导组件申请合理的（成本低，安全）容器资源。通过数据化提供日常运维所需要的容量相关数据，完成备容，在生产水位异常时，完成应急扩容。

?

目前我们完成了水位监控、全量风险播报、预调度、profile 性能数据定时抓取、进而通过组件规范中推进 CPU 内存以及 CPU 内存比例优化。正在做的包括自动化的规格建议，节点资源补充建议，以及自动化导入节点，结合 chatops 正在打造钉群“一键备容”闭环。另外还在结合全链路压测服务数据，得出各个组件的基线对比，通过风险决策，进行发布卡点，确保组件上线安全。同时未来会结合线上真实的变更，来持续回答真实环境的 SLO 表现，精准预测容量。

?

[](()全局高可用应急能力建设

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

高可用基础能力的建设可以为 ASI 提供强有力的抗风险保障，从而在各种风险隐患出现时，尽可能保证我们服务的可用性。但是在风险出现后，如何快速介入消灭隐患，或者在高可用能力无法覆盖的故障出现后，进行有序止损，就变成了一个非常具有技术深度和横向复杂度的工程难题，也让 ASI 的应急能力建设成为我们非常重要的投入方向。

?

在建设应急体系之初，我们的系统由于迅速的发展和变化，不断出现的事故和险情，明显的暴露出当时我们面临的几个严重的问题：

?

• 为什么客户总是早于我们发现问题？

• 为什么恢复需要这么长的时间？

• 为什么同样的问题会重复出现？

• 为什么只有几个人能处理线上的问题？

针对这些问题，我们也进行了充分的脑暴和探讨，并且总结出以下几个核心原因：

?

• 发现问题手段单一：只有 metrics 数据作为最基本暴露问题的手段。

• 定位问题能力缺乏：只有少数监控大盘，核心组件的可观测能力建设程度没有统一。

• 恢复手段缺乏体系：线上问题的修复需要临时敲命令，写脚本，效率低且风险大。

• 应急缺少体系规范：缺乏与业务方联动，工程师思维严重，不是以止损为第一目标，对问题严重度缺乏意识。

• 长期问题缺乏跟踪：线上发现的隐患，或者事故复盘的跟进项，缺乏持续跟进能力，导致重复踩坑。

• 缺乏能力保鲜机制：业务变化非常快速，导致一些能力在一段时间后，进入一个“不会用也不敢用，也不能保证一定能用”的尴尬境地。

[](()1. 应急能力建设顶层设计

针对这些亟待解决的问题，我们也做了应急能力的顶层设计，架构图如下：

?

应急能力建设整体可以分为几个部分：

?

• 1-5-10 应急体系：针对线上出现的任何突发风险，都能做到“一分钟发现，五分钟定位，十分钟恢复”的底层能力和机制。

• 问题追踪跟进：针对线上发现的所有风险隐患，无论严重与否，都能持续跟踪推进的能力。

• 能力保鲜机制：针对建设的 1-5-10 能力，鉴于其使用频率比较低的本质特性。

[](()2. 应急能力建设子模块建设

针对顶层设计中的每个子模块，我们都已经做出了一些阶段性的工作和成果。

?