关于kubernetes:蚂蚁集团如何在大规模-Kubernetes-集群上实现高-SLO

1次阅读

共计 2947 个字符，预计需要花费 8 分钟才能阅读完成。

作者 | 田晓旭

随着 Kubernetes 逐步成为云计算的规范，企业中的 Kubernetes 利用正成为支流。

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

整体指标：集群是否衰弱，所有组件是否失常工作，集群中 Pod 创立的失败数量有多少等等；
追踪能力：集群中产生了什么，是否有异样，用户做了什么事件等等；
起因定位：出现异常之后，找到是哪个组件出了问题；

想要解决这些问题，比拟好的一个办法就是 SLO，通过定义 SLO 来形容集群的可用性，追踪集群中 Pod 的生命周期，一旦呈现失败 Pod，疾速定位异样组件。本文采访了蚂蚁团体技术专家范康和姚菁华来分享蚂蚁团体的 SLO 体系是如何建设的。

大家常会听到 SLA，其实 SLA 是 SLO 衍生进去的协定，SLA 协定会造成具备法律效力的合同，通常是服务供应商和内部客户之间签订的，而 SLO 是用于外部服务之间，定义服务所提供性能的一种冀望状态。

如果咱们要通过定义来形容集群的可用性，那么具体的形容指标就成为了须要解决的关键问题。在蚂蚁团体外部，集群可用性的要害指标蕴含五个：集群衰弱度、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 的比值。

确定好 SLO 各项要害指标的定义之后，接下来就是构建 SLO 体系。

据范康介绍，蚂蚁团体 SLO 零碎次要包含两个方面，一个方面用于向终端用户 / 运维人员展现以后集群各项指标状，另一方面是各个组件相互协作，剖析以后集群状态，获取影响 SLO 的各项因素，为晋升集群 pod 交付成功率提供数据反对。

蚂蚁团体 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 生命周期以及出错起因。

目前蚂蚁团体的 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 把集群能力耗尽，影响其余用户的利益；

正文完