新闻资讯

蚂蚁集团如何在大规模 Kubernetes 集群上实现高 SLO?

蚂蚁集团如何在大规模 Kubernetes 集群上实现高 SLO?

作者 | 田晓旭

随着 Kubernetes 逐渐成为云计算的标准,企业中的 Kubernetes 应用正成为主流。

根据 CNCF 2019 Kubernetes 使用调查报告的显示:目前 84% 的用户已经在生产环境中使用 Kubernetes,生产环境中容器部署规模超过 1000 的比例是 34%,其中超过 5000 的大规模应用比例是 19%。当集群越来越大、越来越复杂,集群可用性就会面临挑战。

  • 整体指标:集群是否健康,所有组件是否正常工作,集群中 Pod 创建的失败数量有多少等等;

  • 追踪能力:集群中发生了什么,是否有异常,用户做了什么事情等等;

  • 原因定位:出现异常之后,找到是哪个组件出了问题。

想要解决这些问题,比较好的一个方法就是 SLO,通过定义 SLO 来描述集群的可用性,追踪集群中 Pod 的生命周期,一旦出现失败 Pod,快速定位异常组件。本文采访了蚂蚁集团技术专家范康和姚菁华来分享蚂蚁集团 的 SLO 体系是如何建立的。

大家常会听到 SLA,其实 SLA 是 SLO 衍生出来的协议,SLA 协议会形成具有法律效力的合同,通常是服务供应商和外部客户之间签订的,而 SLO 是用于内部服务之间,定义服务所提供功能的一种期望状态。

1SLO 指标定义

如果我们要通过定义来描述集群的可用性,那么具体的描述指标就成为了需要解决的关键问题。在蚂蚁 集团 内部,集群可用性的关键指标包含五个:集群健康度、Pod 创建成功率、残留 Terminating Pod 的数量、服务在线率和故障机数量。

  • 集群健康度:通常使用 Healthy,Warning,Fatal 三个值来描述,其中 Warning 和 Fatal 对应告警体系,例如 P2 告警发生,那集群就是 Warning,而 P0 告警发生,那集群就是 Fatal,必须进行处理。

  • Pod 创建成功率:这是一个非常重要的指标,蚂蚁 集团 一周的 Pod 创建量在百万级别,如果成功率波动会造成大量 Pod 失败,同时 Pod 成功率下跌也是集群异常的最直观反映;

  • 残留 Terminating Pod 的数量:有人可能会好奇为什么使用残留 Terminating Pod 的数量,而不用删除成功率?这是因为当 Pod 数量达到百万级别后,即使删除成功率达到了 99.9%,Terminating Pod 的数量也有数千,残留这么多 Pod 占用应用容量,在生产环境中是不可接受的;

  • 服务在线率:这个指标是通过探针来衡量的,探针失败则意味着集群不可用;

  • 故障机数量:这是一个节点维度的指标,故障机通常是指无法正确交付 Pod 的物理机,集群故障机需要做到“快速发现,快速隔离,及时修复”,否则会对集群容量造成影响。

以上指标的阈值和 SLO 性能目标都是根据业务方的增长来定义的,随着业务的不断增长,这些指标的定义也可能需要跟着做调整。

以 Pod 创建成功率为例,蚂蚁集团 将 Pod 分为了普通 Pod 和 Job 类 Pob,普通 Pod 的 RestartPolicy 为 Never,Job 类 Pod 的 RestartPlicy 为 Never 或 OnFailure,两者的都设定有交付时间,普通 Pod 的交付标准是 1min 内 Pod 已经 Ready;Job 类 Pod 的交付标准是 1min 内 Pod 的状态已达 Running,Succeeded,或 Failed。最开始 Pod 创建成功率的定义是 成功创建的 Pod 和总 Pod 的比值,但是很快就发现在排查原因时,系统很难分辨,所以又将 Pod 失败原因调整成用户和系统两部分,创建成功率的定义就变成了创建成功的 Pod 和总的 Pod 减去用户失败 Pod 的比值。

2 蚂蚁集团的 SLO 体系

确定好 SLO 各项关键指标的定义之后,接下来就是构建 SLO 体系。

据范康介绍,蚂蚁集团 SLO 系统主要包括两个方面,一个方面用于向终端用户 / 运维人员展示当前集群各项指标状,另一方面是各个组件相互协作,分析当前集群状态,获取影响 SLO 的各项因素,为提升集群 pod 交付成功率提供数据支持。

蚂蚁集团如何在大规模 Kubernetes 集群上实现高 SLO?蚂蚁集团 SLO 体系架构图

自顶向下而看,蚂蚁集团 SLO 的分层架构包括 SLO、Trace system、Increase of SLO、Target 和 The unhealthy node。

其中,顶层组件主要面向各种指标数据, 如集群健康状态、pod 创建、删除、升级成功率、残留 pods 数量,不健康节点数量等指标。其中 Display Board 是指监控大盘,可能不会实时查看,为避免错过处理紧急事件的最佳时机,同时构建了 Alert 告警子系统,支持配置多种告警方式;Analysis System 通过分析指标历史数据以及采集到的节点 metrics 和 master 组件指标,给出更详细的集群运营报告;Weekly Report 子系统给出当前集群本周 pod 创建 / 删除 / 升级的数据统计,以及失败案例原因汇总;Terminating Pods Number 给出一段时间内集群内新增的无法通过 Kubernetes 机制删除的 Pods 列表和 Pods 残留原因;Unhealthy Nodes 则给出一个周期内集群所有节点的总可用时间占比,每个节点的可用时间、运维记录、以及不能自动恢复,需要人工介入恢复的节点列表。

为了支撑上述这些功能,蚂蚁 集团 还开发了 Trace System,用来分析展示单个 pod 创建 / 删除 / 升级失败的具体原因。其中包含日志和事件采集、数据分析、pod 生命周期展示三个模块。日志和事件采集模块采集各 master 组件以及节点组件的运行日志和 pod、node 事件,分别以 pod/node 为索引存储日志和事件;数据分析模块分析还原出 pod 生命周期中各阶段用时,判断 pod 失败原因,节点不可用原因。最后,由 Report 模块向终端用户暴露接口和 UI,向终端用户展示 pod 生命周期以及出错原因。

3 经验总结

目前蚂蚁集团 的 SLO 实践不仅提高了集群 pod 的交付成功率,同时通过构建 tracing 系统,分析到集群内 pod 交付关键链路的耗时,整理失败原因,实现了数据分析 / 诊断平台。对于如何实现高 SLO,范康也给出了自己的五点经验。

  • 在提升成功率的进程中, SLO 治理 团队面临最大的问题是 镜像下载 。Pod 必须在规定时间内交付,而镜像下载通常需要非常多的时间。所以, 团队 通过计算镜像下载时间,专门设置了一个 ImagePullCostTime 的错误,即镜像下载时间太长,导致 Pod 无法按时交付。另外,阿里镜像分发平台蜻蜓支持了 Image lazyload 技术,在 Kubelet 创建容器时,不用再下载镜像,大大加速了 Pod 的交付速度。

  • 提升单个 Pod 成功率 :随着成功率的提升,再提升的难度会越来越大,这是可以引入 workload 进行重试。蚂蚁 集团 内部的 PaaS 平台会不断重试,直到 Pod 成功交付或者超时。需要注意的是,重试时要先排除之前的失败节点。

  • 检查关键 Daemonset :如果关键 Daemonset 缺失,把 Pod 调度上去是很容易出问题的,甚至影响到创建 / 删除链路,这样可能就接入故障机体系。

  • 很多 Plugin 是需要向 Kubelet 注册的,如 CNI Plugin,可能存在节点上一切正常,但向 Kubelet 注册时失败的情况,那么这个节点同样无法提供 Pod 交付的服务,需要接入故障机体系。

  • 由于集群中的用户数量非常多,所以 隔离 很重要。在权限隔离的基础上,还需要做到 QPS 隔离、容量隔离,防止一个用户的 Pod 把集群能力耗尽,影响其他用户的利益。

InfoQ 读者交流群上线啦!各位小伙伴可以扫描下方二维码,添加 InfoQ 小助手,回复关键字“ 进群 ”申请入群。大家可以和 InfoQ 读者一起畅所欲言,和编辑们零距离接触,超值的技术礼包等你领取 ,还有超值活动等你参加,快来加入我们吧!

蚂蚁集团如何在大规模 Kubernetes 集群上实现高 SLO?

蚂蚁集团如何在大规模 Kubernetes 集群上实现高 SLO?

点个在看少个 bug 👇

来源链接:mp.weixin.qq.com