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

如果无法正常显示，请先停止浏览器的去广告插件。

1. 万级规模K8s高可用实践陈杰（花名：韩堂）阿里巴巴高级专家

2. • 问题和挑战 • 全局高可用基础能力建设 • 全局高可用应急体系建设 • 保鲜和验收能力建设

3. 问题和挑战

4. 阿里经济体云原生实践历程图通过VPC直接使用公有云资源计算存储分离，占47.6% 一路向北混部支持12w交易量级，占24% 专有云阶段：集团把公共云的服务器搬到集团弹内，然后搭建云的基础设施深圳云支持1.2w交易 2017年全网云支持18w交易 2017年混部支持4w交易量级 2020+ 2019 2018 2017 2016 Alidocker富容器 + AliSwarm 单富容器Pod +Sigma3.1 Pouch富容器 + Sigma2.0 阿里巴巴经济体全站云化 20年核心系统 100% 以云原生的方式上云，完美支撑了 54.48w 峰值流量以及2648亿的成交量全面迁移统一调度单集群规模 4000节点单富容器 & SideCar Pod + ASI 单集群规模 8000节点轻量级容器 & SideCar Pod + ASI on ACK 单集群规模 10000-12000节点

5. 问题和挑战 —— 业务及基础设施层

6. 问题和挑战 —运维体系层 • 如何在架构和能力上去提升我们的可用性，降低故障的概率和影响面？ • 如何在核心链路性能和架构上做一些突破，支撑复杂多变的业务场景和业务增⻓的通用需求？ • 如何让问题不再追身，做好预防工作，避免应急？ • 如何在应急发生时，能够快速发现，快速诊断，快速止损？

7. 问题和挑战 —k8s架构技术层 • 对 ApiServer 的掌控能力不够，应急能力不足，我们自己的经历，历次单集群一周内Master 出现异常的次数超过20 +，历次恢复时间最⻓超过 1 小时 • 单集群规模大， Apiserver 内存水位比较高，压力来源于频繁的查询，写入更多更大的资源对象 • 在业务层缺少跨机房的容灾能力，当 ASI 不可用的时候，只能依赖 ASI 的恢复能力 • 集群规模的持续扩大，任务的大量创建和删除对集群的造成更大压力

8. 云原生基础设施研发/SRE团队的最佳实践

9. 全局高可用基础能力建设

10. 单集群规模带来的SLO问题

11. 单集群节点规模优化 n APIServer多路架构优化 n etcd compact算法优化 n qps限流管理和容量管理优化 n apiserver客户端优先访问本地cache n apiserver客户端负载均衡 n apiserver服务端watch优化和cache索引优化 n etcd单资源对象存储拆分 n 组件规范全生命周期落地 n 客户端的规范约束降低apiserver/etcd n etcd 单节点多multi boltdb的架构优化 n apiserver的服务端数据压缩 n 通过组件治理降低etcd写放大等 n 常态化的压测服务能力的压力 n etcd内核上利用并发读提升单etcd集群读处理能力 n 基于hashmap的freelist新算法提高etcd 存储上限 8000 → 12000 nodes n 基于raft learner技术来提高多备能力 4000 → 8000 nodes 100 → 4000 nodes

12. K8s组件性能优化 • 客户端侧， cache 优化，让各个 client 优先访问本地 informer cache，也需要做负载均衡优化，主要包括对 apiserver,etcd 的负载均衡。同时针对客户端的各种优化，可以通过组件性能规范，在组件启用，准入的时候进行校验是否满足 • APIServer 侧，访问层，缓存层，存储层 3 个层次进行优化。在缓存层，我们重点建设了 cache 的索引优化以及 watch 优化，在存储层上重点通过 snappy 压缩算法对 pod 进行数据压缩，在访问层上重点建设了限流能力 • etcd 存储侧的优化，我们也从几个方面做了很多工作，包括 etcd 内核层面各种算法优化工作，还有通过将不同资源拆分到不同 etcd 集群的能力实现了基本的水平拆分能力，同时也在 etcd server 层做 multi boltdb 的扩展能力提升

13. APIServer 多路架构升级 • 通过分流以降低主链路 apiserver 压力（核心诉求） • P2 及以下组件接入旁路 apiserver，并可以在紧急情况（如自身稳定性收到影响）下，做整体限流。 • 旁路 apiserver 配合主链路做蓝绿、灰度（次级诉求） • 旁路 apiserver 可以使用独立版本，增加新功能灰度维度，如使用独立的限流策略，如开启新的 feature 功能验证。 • KOK架构：etcd/cluster/machine operator SLB 灾备（次级诉求）：旁路 apiserver 可以在主 apiserver 发生异常时，对外提供服务

14. Etcd的高可用优化 • etcd集群生命周期管理 - 集群创建，销毁，停止，升级，故障恢复 - 集群状态监控，包括集群健康状态、member 健康状态，访问量，存储数据量 - etcd异常诊断、预案、黑盒探测，配置巡检 • etcd数据管理 - etcd数据备份及恢复，两种方式如下： - 脏数据清理 - 热点数据识别 - 数据迁移能力, 两种方式 - 数据水平拆分 • etcd内核架构升级更新 - 自适应历史数据清理compact技术（自研） - 基于raft learner的只读节点水平扩展能力（自研） - 基于raft learner的热备节点（自研） - 共享etcd集群限流熔断安全审计等能力（自研） - raft joint consensus （开源） - 性能增强，内存优化（开源）

15. 多维度（resource/verb/client）精细化限流方案 ua limiter 限流基础 QPS 限流结复杂程果度标量 QPS 低熔断否自适应限流否排队等待限流维度可调试使用场景否 user agent list-all 否少限流策略管理 • 数百套集群/内部组件有近百个，每个组件请求的资源平均有 4 种/ 3 个不同的动作 • 规则将会爆炸式增长、收敛后维护成本也非常的高 • APF Sentinel 并发度 QPS ，协程数权值分配并发度标量 QPS 中高否支持否支持支持（公平排队）支持（匀速排队） namespace、user、 verb、resource、 path 是 namespace、user、 verb、resource、精细化list、user agent 否社区APF机制(K8s v1.18 alpha) 阿里 ua limiter: 先于社区在内部大规模使用中 • • 高 • • 核心资源 pod\node、核心动作（创建、删除、大查询）；最大规模的：daemonset 组件、PV/PVC 资源。总结输出：20条左右的通用限流策略，并将其纳入到集群交付流程中实现闭环新组件接入，我们也会对其做限流设计，如果比较特殊的，则绑定规则并在集群准入和部署环节自动下发策略如果出现大量的限流情况，也会触发报警，由 SRE 和研发去跟进优化和解决。

16. POD 级别的精细化限流客户端流控 • kube-defender 是站在整个 K8s 集群的视角，针对用户发起的或者系统自动发起的有风险的操作进行防护（流控、熔断、校验）和审计的风控系统。之所以做 defender，主要从以下几个方面考虑：类似 kubelet/controller 这样的组件，在一个集群中存在多个进程，任一单一进程都无法看到全局的视图，无法进行准确的限流 • 从运维视角，分散在各个组件中的限速规则难以配置与审计，当部分操作因为限流原因失败时，排查链路过长影响问题定位的效率 • K8s 面向终态的分布式设计，每个组件都有决策的能力，那么就需要一个集中的服务对那些危险决策进行风控

17. 全局高可用应急体系建设

18. 顶层设计目标SLO量化（k8s管控可用性：99.99%，业务POD创建成功率：99.9%等） 1-5-10应急体系多级SLO体系 SLO运营体系 SLO数据建设 5分钟响应和定位 10分钟决策与恢复监控告警标准化与自动化值班长oncall应急制度应急预案系统化管理诊断SOP和自动诊断系统值班长决策与止损通用能力建设黑盒探测和定向巡检多级SLO定义防御能力 1分钟发现和通告 API QPS限流和熔断常态化故障演练权限标准化和收敛常态化性能压测故障自愈联邦多集群架构值班长制度稳定性培训组件自愈能力 pod自愈能力数据恢复能力节点自愈能力集群恢复能力多路APIServer架构持续改进变更阻断 Dedender业务层限流和熔断风险全生命周期管理基于ACK的KOK架构高可用架构组件规范全生命周期落地数字化备容故障学习复盘和 Action落地机制安全生产设计模板 BFSLO规范平台建设巡检平台监控平台压测平台告警平台故障演练平台日志平台数据平台风控平台预案平台全链路跟踪平台诊断平台变更管控平台

19. K8s 管控的运行时风险

20. K8s管控在⻛险应急上碰到的问题

21. 1分钟发现：主动发现能力 • 黑盒通道：基于黑盒思想，从客户视角把 ASI 整体当做黑盒，直接发出指令，探测正向功能；比如直接扩容一个 statefulset。 - kubeprobe，脱胎于社区 kuberhealthy 项目进行优化改造 • 白盒通道：基于白盒思想，借助系统内部暴露出来的各种维度的可观测性数据的异常波动来发现潜在问题；比如 APIServer 的内存异常上涨。 - metrics、日志、事件 3 个维度分别基于 SLS 建设 3 种数据通道。

22. 5分钟定位：问题根因自动定位黑盒：自闭环的根因定位系统，将问题排查的专家经验下沉进系统中，实现了快速和自动的问题定位功能。通过普通的根因分析树以及对失败巡检探测事件/日志的机器学习分类算法（持续开发投入中），为每一个 KubeProbe 的探测失败 Case 做根因定位，并通过 KubeProbe 内统一实现的问题严重性评估系统白盒：通过底层的 pipeline 引擎的编排能力，结合已经建设的数据平台中的多维度数据，实现了一个通用的根因诊断中心，将通过各种可观测数据从而排查问题根因的过程通过 yaml 编排的方式固化到系统中，形成一个根因诊断任务，并且在触发任务后形成一个问题的诊断结论。并且每种结论也会绑定对应的恢复手段，比如调用预案、自愈等等

23. 10分钟恢复：恢复止损能力建设预案中心；建设通用止损能力

24. 1-5-10：chatops

25. 风险自动化交互体验场景配置工单触发

26. 保鲜和验收能力建设

27. 全局风险分析风险影响面金字塔大规模POD 删除或停止大规模的容器出现运行时资源问题，如CPU等等业务发布不可用业务扩缩容不可用（不满足紧急扩容时效）风险来源分析全局高可用防护手段 • 宿主机批量自愈 • 容器自愈LivnessProbe造成批量重启 • 常态化故障演练 • Pod级别限流风控调度分配规则未满足，异常堆叠等 • 线上调度流量模拟器常态回放； • 编排SLO告警链路问题性能和容量不满足 • • • • 常态化压测和数字化备容常态化的故障演练发布成功率SLO告警 QPS限流和熔断链路问题性能和容量不满足 • • • • 常态化压测和数字化备容常态化的故障演练扩缩容成功率SLO告警 QPS限流和熔断

28. 常态化故障演练机制 • 建设故障场景库，将所有场景进行入库，分类，管理，保证场景的覆盖面够全面 • 基于ChaosBlade注入故障能力，将我们的设计场景逐个落地，并且配置为后台持续运行 • 我们还借助该平台灵活的插件丰富能力，将平台同我们的告警系统，预案系统进行 API 对接 • 在故障场景被触发注入后，可以完全通过后台自动调用的模式完整的针对这个场景的注入、检查、恢复都通过后台运行完成

29. 生产突袭常态化故障演练中的集群一般是没有生产流量的测试集群，于是我们还需要做生产突袭 • • 没有任何提前预警或通知，人为触发风险因子，检验10分钟恢复主站交易、钉钉消息收发送、盒马交易业务的能力。风险因子（高可用场景特指“跌零因子”）包含容灾、容错、安全三种类型，全面考察机房级别的容灾能力，应用级的容错能力和安全故障恢复能力。

30. 容量问题的利器-常态化压测

31. 常态化压测-约束和变量分析一、场景变量分析：进行容量性能评估的场景设计时，需要分析的信息主要分成如下几类： 1.Verb动线，即为：有性能风险的动作、接口链路场景分析 2.约束条件，例如：k8s节点规模、用户的pod/crd等资源数量前提 3.控制变量，即为：实际上是可变的，但是非首要分析信息。例如：单pod size等 4.被评估变量，例如：kubernetes大版本？etcd版本？scheduer开关等综合起来，一个整体评估场景举例为：在预期需要管控1w+节点，单节点pod数30w的前提下，控制pod类型和size和生产平均水平对齐，看新版调度器调度qps、端到端时延可以达到水位如何，和旧版相比是否有优化或衰退。二、约束条件模拟 1w+台ECS，1w+的volume，1w+IP资源

32. 常态化压测-可观测性的设计建设压测能力的同时，我们同时需要些能力指引排查分析、结合SLO指标来决策压测优化的动作 1) 自动采集压测阶段性能指标，判断是否满足SLO 2) 采集全链路各阶段时延latency，加速识别分析性能瓶颈 3) 基本信息：目标、场景、环境、压测结果是否满足SLO,不满足指标情况下自动采集profile文件供排查分析 4) 图表信息： POD拉起时延、吞吐QPS、API/Latency、Etcd时延，组件资源使用 5) 监控分析：依赖Grafana大盘压测实时数据分析; pprof工具辅助分析

33. 常态化压测-实现目标： 1. 压测服务平台目标能够满足多种的压测需求，沉淀丰富的压测场景 2. 压测能力提升扩展性、灵活性，丰富性，支持通过多样的压测模型 1）常态化的压测模式：使用基准压测数据进行常态化压测，探测集群当前性能，定期运行压测，产出压测报告，进而优化；压测基准数据，保证集群日常SLO进行压测，确认集群性能可以满足当前业务目标 2）摸高压测：基于基准数据，递增负载，摸出集群上限和链路短板缺陷 3）专项组件压测：各组件按照标准接入压测环境，对该组件” 单压“判断是否能够满足性能要求

34.