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

开课吧开课吧锤锤2021-03-05 16:20

点赞
有用
分享分享

   互联网的快速发展,衍生了许多编程语言。每个使用自己编程语言额程序员们,都认为自己现在所使用的编程语言才是当下主流语言,谁也不服谁。但在众多编程语言中随着Kubernetes逐渐成为云计算的标准,企业中的Kubernetes应用正成为主流。

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

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

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

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

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

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

    1SLO指标定义

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

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

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

    残留TerminatingPod的数量:有人可能会好奇为什么使用残留TerminatingPod的数量,而不用删除成功率?这是因为当Pod数量达到百万级别后,即使删除成功率达到了99.9%,TerminatingPod的数量也有数千,残留这么多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交付成功率提供数据支持。

Java

    蚂蚁集团SLO体系架构图

    自顶向下而看,蚂蚁集团SLO的分层架构包括SLO、Tracesystem、IncreaseofSLO、Target和Theunhealthynode。

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

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

    3经验总结

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

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

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

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

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

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

想要快速进入大厂,点击下方图片免费领取课程。

Java

这个课程,涵盖了各个大厂的面试题精华,一份面试题可以帮助您拿到很多心仪的offer,这种机会可不多,还在等什么快快点击领取吧。

有用
分享