作者 | 田晓旭
随着 Kubernetes 逐步成为云计算的规范，企业中的 Kubernetes 利用正成为支流。
依据 CNCF 2019 Kubernetes 应用调查报告的显示：目前 84% 的用户曾经在生产环境中应用 Kubernetes，生产环境中容器部署规模超过 1000 的比例是 34%，其中超过 5000 的大规模利用比例是 19%。当集群越来越大、越来越简单，集群可用性就会面临挑战。
- 整体指标：集群是否衰弱，所有组件是否失常工作，集群中 Pod 创立的失败数量有多少等等；
- 追踪能力：集群中产生了什么，是否有异样，用户做了什么事件等等；
- 起因定位：出现异常之后，找到是哪个组件出了问题；
想要解决这些问题，比拟好的一个办法就是 SLO，通过定义 SLO 来形容集群的可用性，追踪集群中 Pod 的生命周期，一旦呈现失败 Pod，疾速定位异样组件。本文采访了蚂蚁团体技术专家范康和姚菁华来分享蚂蚁团体的 SLO 体系是如何建设的。
大家常会听到 SLA，其实 SLA 是 SLO 衍生进去的协定，SLA 协定会造成具备法律效力的合同，通常是服务供应商和内部客户之间签订的，而 SLO 是用于外部服务之间，定义服务所提供性能的一种冀望状态。
1 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 的比值。
2 蚂蚁团体的 SLO 体系
确定好 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 生命周期以及出错起因。
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 把集群能力耗尽，影响其余用户的利益；