作者 | 悟鹏
Kubernetes 在生产环境中的采用率越来越高,复杂度越来越高,由此带来的稳定性保障的挑战越来越大。
对于基于 Kubernetes 的云产品,稳定性保障已成为基本诉求,稳定性缺陷会给产品带来巨大的损失,如用户流失、用户信心下降、产品迭代速度变慢等。
虽然基于 Kubernetes 的稳定性保障很重要,但业界缺少基于实践的标准化稳定性保障方案,导致同样的问题在同一产品或不同的产品中重复出现,最佳实践不能应用在更多相同技术栈的产品中,不同产品形成的稳定性保障最佳实践也不能互补。
为此,基于过去的开发实践以及基于 Kubernetes 的稳定性保障经验,尝试形成《Kuberentes 稳定性保障手册》,将稳定性保障最佳实践进行沉淀,使得人人对 Kubenretes 稳定性保障的理论形成全面的理解,相应的工具和服务成为基础设施,复用在类似技术栈的产品中,加速稳定性保障最佳实践的传播、迭代和应用。
本篇文章作为《Kubernetes 稳定性保障手册》第一篇文章,抽象稳定性保障中的核心内容,作为稳定性保障最简使用手册。
极简手册目标
稳定性保障目标
稳定性保障检查项
维度 | 检查项 |
---|---|
可观测 | 是否提供了 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% 以上要求 |
L1
L2
L3
L4
L5
实践
实践流程:
为了降低实践的成本,需要把握云产品中的元素及交互关系,从基础的元素和交互方面解构复杂系统:
如下图:
随着元素数量和交互关系的增多,系统会逐步变得复杂,稳定性保障面临的挑战也会越来越大,要避免引入非必要的复杂性。
因此,需要先梳理清楚当前的运行链路图,进行链路重要性分析,并整理组件大图,判断组件的爆炸半径。在此基础上,还需要进行参与人员的 review,避免在人员的投入方面存在单点风险。
运行链路图示例:
链路重要性示例:
云产品间交互示例:
基于上述对系统复杂度、运行链路的分析,面对稳定性保障的问题域,可以有效提出、落地解决方案。
实践流程:
对于复杂的系统,通常会有如下的角色关系:
梳理清楚每层的角色,并使得参与同学可以方便查找目标同学,会缩短问题处理时间。
维度 | 项目 | 推荐 |
---|---|---|
目标管理 | 业务 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 APImetrics API 编写可参考:Instrumenting A Go Application For Prometheusmetric 名称最佳实践:第一部分要起到 namespace 的作用最后一部分起到表征单位的作用运行阶段:采集、可视化、告警配置,可使用阿里云 ARMS Prometheus 产品:产品官网 | |
巡检 | 后续推出 | |
告警 | 基于日志、metrics、巡检系统配置告警,配置每条告警时,可通过如下问题列表达到举一反三效果:告警是否是集群级别?告警是否是组件级别?异常信息源是什么?精确异常特征是什么?模糊异常特征是什么?异常爆炸半径多大?告警级别是什么?该告警已覆盖的范围 (集群/组件) 多大? | |
可控性 | 发布管理 | 后续推出 |
恢复管理 | 实践:枚举异常场景线下模拟异常通过预案固化处理方案挑战:灾备链路神龙安全容器VK+ECI集群逃生单集群多套管控链路单 region 多套集群 (联邦或主备模式)跨 region 多套集群 (联邦或主备模式) | |
混沌工程 | 实践:可控故障演练应用在导致跌零因子和有巨大爆炸半径的场景随机故障演练 | |
定期体检 | 实践:系统在不断演进,需要定期从业务视角进行审视 | |
专项治理 | 复杂度治理 | 梳理:业务流程图运行链路图链路重要性图组件列表依赖关系图如非必要,勿增实体。 |
爆炸半径治理 | 实践:基于运行链路图和链路重要性图,整理链路和组件的爆炸半径进行链路和组建的可观测性和可控性治理关注:异常是否会随着时间变长,导致影响规模扩大 | |
跌零因子治理 | 实践:爆炸半径的极端情况最高优先级进行可观测性和可控性治理线下演练 |
技术 SLI / SLOK8s 社区:
可观测性日志开发阶段:
运行阶段:
Metrics开发阶段:
运行阶段:
巡检后续推出 告警基于日志、metrics、巡检系统配置告警,配置每条告警时,可通过如下问题列表达到举一反三效果:
可控性发布管理后续推出恢复管理实践:
挑战:
混沌工程实践:
定期体检实践:
专项治理复杂度治理梳理:
如非必要,勿增实体。爆炸半径治理实践:
关注:
跌零因子治理实践:
后续
对于《Kubernetes 稳定性保障手册》,接下来会进行如下的章节细化,分别从方法论和工具/服务的角度进行总结,形成初版后与大家分享: