Kubernetes 稳定性保障手册（极简版）

作者 | 悟鹏

来源 | 阿里巴巴云原生

头图 | 下载于视觉中国

Kubernetes 在生产环境中的采用率越来越高，复杂度越来越高，由此带来的稳定性保障的挑战越来越大。

对于基于 Kubernetes 的云产品，稳定性保障已成为基本诉求，稳定性缺陷会给产品带来巨大的损失，如用户流失、用户信心下降、产品迭代速度变慢等。

虽然基于 Kubernetes 的稳定性保障很重要，但业界缺少基于实践的标准化稳定性保障方案，导致同样的问题在同一产品或不同的产品中重复出现，最佳实践不能应用在更多相同技术栈的产品中，不同产品形成的稳定性保障最佳实践也不能互补。

为此，基于过去的开发实践以及基于 Kubernetes 的稳定性保障经验，尝试形成《Kuberentes 稳定性保障手册》，将稳定性保障最佳实践进行沉淀，使得人人对 Kubenretes 稳定性保障的理论形成全面的理解，相应的工具和服务成为基础设施，复用在类似技术栈的产品中，加速稳定性保障最佳实践的传播、迭代和应用。

本篇文章作为《Kubernetes 稳定性保障手册》第一篇文章，以抽象稳定性保障中的核心内容，作为稳定性保障最简使用手册。

极简手册目标

• 1min 理解稳定性保障目标

• 3min 把握稳定性保障全局视图

• 一站查找稳定性保障推荐工具或服务

稳定性保障目标

• 满足服务或产品对稳定性的诉求

• 加速服务或产品的迭代

稳定性保障检查项

维度	检查项
可观测	是否提供了 Prometheus metrics API？ 是否将日志进行了持久化？ 是否配置了监控？ 是否有对跌零因子的监控？ 是否有服务降级的监控？ 是否有限流的监控？ 是否配置了对关键依赖方的可用性监控？ 监控是否分级？ 是否配置了告警？ 是否有对跌零因子的告警？ 是否有服务降级的告警？ 是否有限流的告警？ 是否配置了对关键依赖方的可用性告警？ 告警是否分级？ 是否配置了巡检？ 是否使用了 structured log 便于进行 log 的查询、分析？ 服务自身及服务间交互，是否有唯一识别身份
可灰度	是否使用了具有灰度能力的 workload？ 是否具有业务维度的灰度能力？ feature 是否具有灰度能力？ feature 是否具有可控灰度 (按百分比或指定群体) 能力？
可回滚	是否使用了均有回滚能力的 workload？ 组件是否进行了版本控制？ 配置是否进行了版本控制？
可保护	是否有限流措施？ 是否有降级措施？ 是否配置了探针？ 是否配置了 livenessProbe？ 可被访问时，是否配置了 readinessProbe？ 初始化耗时时，是否配置了 startupProbe？ 是否有快速失败的能力？ 是否有超时结束能力？ 依赖方不可用时: 是否会持续对依赖方带来日常或更高压力？ 是否会对上游带来反向压力？(如连接数、处理延时) 己方不可用时： 对上游的影响是否可控？ 恢复时是否可以控制请求压力？ 是否可以无损重建？ 是否多副本部署？ 是否需要配置 PodDisruptionBudget？ 是否配置了非亲和性？ 是否跨 AZ 部署？ 是否有处理预案 是否均有访问管理？ 服务是否稳定性运行，是否会影响数据资产？ 服务是否稳定性运行，是否会泄露敏感信息？ 是否区分组件处于关键链路还是旁路？ 是否有「爆炸半径」的整理？ 是否有「跌零因子」的整理？ 是否具有功能开关，便于一键开启、关闭指定功能？
可控成本	是否配置了 limit resources？ request resources 是否表征了平均使用资源量？ 变更是增加还是降低用户成本？ 变更是增加还是降低平台成本？
易于运维	是否可以做到变更配置时无需重建实例？ 是否有白屏化运维途径？ 是否有「端到端管控链路」流程图？ 是否有「端到端数据链路」流程图？ 是否有链路重要程度分析？ 是否有爆炸半径、跌零因子分析？ 是否枚举总结了交付的能力？ 是否枚举总结了依赖的能力？ 是否枚举了组件、依赖方团队和接口人？

稳定性保障级别

级别	标准
L0	可观测、可灰度、可回滚 均不满足
L1	可观测、可灰度、可回滚 满足 50% 以上要求
L2	可观测、可灰度、可回滚 满足 90% 以上要求
L3	可观测、可灰度、可回滚 满足 90% 以上要求 可保护、可控成本 满足 50% 以上要求
L4	可观测、可灰度、可回滚、可保护、可控成本 满足 90% 以上要求 易于运维满足 50% 以上要求
L5	可观测、可灰度、可回滚、可保护、可控成本、易于运维 满足 90% 以上要求

实践

1. 方法论

1）全局视图

实践流程：

1. 整理运行链路图，标记链路是否是关键链路

2. 基于运行链路图，进行可观测性配置

3. 基于链路重要程度，进行可控性治理

为了降低实践的成本，需要把握云产品中的元素及交互关系，从基础的元素和交互方面解构复杂系统：

• 元素 (2 类)

• • 云产品组件

  • 云产品

• 交互 (2 类，共 3 种场景)

• • 云产品内部

  • • 组件自身

    • 组件与组件之间

  • 云产品之间

  • • 云产品与云产品之间

如下图：

随着元素数量和交互关系的增多，系统会逐步变得复杂，稳定性保障面临的挑战也会越来越大，要避免引入非必要的复杂性。

因此，需要先梳理清楚当前的运行链路图，进行链路重要性分析，并整理组件大图，判断组件的爆炸半径。在此基础上，还需要进行参与人员的 review，避免在人员的投入方面存在单点风险。

运行链路图示例：

链路重要性示例：

云产品间交互示例：

基于上述对系统复杂度、运行链路的分析，面对稳定性保障的问题域，可以有效提出、落地解决方案。

2）问题处理

实践流程：

1. 长期维护角色列表、功能流程图、运行链路图

2. 在多个分级的「告警群」中感知问题的发生和恢复

3. 在唯一的「问题处理群」中处理问题和复盘问题

对于复杂的系统，通常会有如下的角色关系：

梳理清楚每层的角色，并使得参与同学可以方便查找目标同学，会缩短问题处理时间。

2. 问题域

1）概述

2）推荐

维度	项目	推荐
目标管理	业务 SLA	业务相关，可参考： 阿里云 ECS SLA: link 阿里云 SLB SLA: link
	技术 SLI / SLO	K8s 社区： Kubernetes scalability and performance SLIs/SLOs: link
可观测性	日志	开发阶段： 使用 structured logging (KEP) golang 开发者可以使用：https://github.com/kubernetes/klog 使用方法可参见：Structured Logging migration instructions 运行阶段： 采集、查询、分析、告警配置，可使用阿里云 SLS 产品：产品官网
	Metrics	开发阶段： 使用 Prometheus 标准，对外提供 http metrics API metrics API 编写可参考：Instrumenting A Go Application For Prometheus metric 名称最佳实践： 第一部分要起到 namespace 的作用 最后一部分起到表征单位的作用 运行阶段： 采集、可视化、告警配置，可使用阿里云 ARMS Prometheus 产品：产品官网
	巡检	后续推出
	告警	基于日志、metrics、巡检系统配置告警，配置每条告警时，可通过如下问题列表达到举一反三效果： 告警是否是集群级别？ 告警是否是组件级别？ 异常信息源是什么？ 精确异常特征是什么？ 模糊异常特征是什么？ 异常爆炸半径多大？ 告警级别是什么？ 该告警已覆盖的范围 (集群/组件) 多大？
可控性	发布管理	后续推出
	恢复管理	实践： 枚举异常场景 线下模拟异常 通过预案固化处理方案 挑战： 灾备链路 神龙安全容器 VK+ECI 集群逃生 单集群多套管控链路 单 region 多套集群 (联邦或主备模式) 跨 region 多套集群 (联邦或主备模式)
	混沌工程	实践： 可控故障演练 应用在导致跌零因子和有巨大爆炸半径的场景 随机故障演练
	定期体检	实践： 系统在不断演进，需要定期从业务视角进行审视
专项治理	复杂度治理	梳理： 业务流程图 运行链路图 链路重要性图 组件列表 依赖关系图 如非必要，勿增实体。
	爆炸半径治理	实践： 基于运行链路图和链路重要性图，整理链路和组件的爆炸半径 进行链路和组建的可观测性和可控性治理 关注： 异常是否会随着时间变长，导致影响规模扩大
	跌零因子治理	实践： 爆炸半径的极端情况 最高优先级进行可观测性和可控性治理 线下演练

后续

对于《Kubernetes 稳定性保障手册》，接下来会进行如下的章节细化，分别从方法论和工具/服务的角度进行总结，形成初版后与大家分享，敬请期待~

更多阅读推荐

• 无法恢复，欧洲云服务巨头数据中心起火
  

• CPU 空闲时在干嘛？
  

• 低代码，让人人都可以是开发者
  

• 三探云原生全景图，这次聊聊运行时层
  

• 一眼看尽5G江湖，Gartner发布5G网络基础设施魔力象限报告
  

• 冯诺依曼架构的 IO 鸿沟，谁能来填补？