在大规模 Kubernetes 集群上实现高 SLO 的方法

做者 | 蚂蚁金服技术专家 姚菁华；蚂蚁金服高级开发工程师 范康

导读：随着 Kubernetes 集群规模和复杂性的增长，集群愈来愈难以保证高效率、低延迟的交付 pod。本文将分享蚂蚁金服在设计 SLO 架构和实现高 SLO 的方法和经验。

Why SLO?

Gartner 对 SLO 的定义：在 SLA 框架下，SLO 是系统必需要达到的目标；须要尽量地保障调用方的成功。有些人可能会对 SLI/SLO/SLA 有困惑，能够先来看下三者的关系：

• SLI 定义一个指标，来描述一个服务有多好算达到好的标准。好比 Pod 在 1min 内交付。咱们一般从迟延、可用性、吞吐率及成功率这些角度来制定 SLI。

• SLO 定义了一个小目标，来衡量一个 SLI 指标在一段时间内达到好的标准的比例。好比说，99% 的 Pod 在 1min 内交付。当一项服务公布了其 SLO 的之后，用户方就会对该服务的质量有了指望。

• **SLA **是 SLO 衍生出来的协议，经常使用于 SLO 定义的目标比例没有完成时，服务方要赔多少钱。一般来讲，SLA 的协议会具体白纸黑字造成有法律效率的合同，经常使用于服务供应商和外部客户之间（例如阿里云和阿里云的使用者）。通常来讲对于内部服务之间的 SLO 被打破，一般不会是经济上的赔偿，可能更多的是职责上的认定。

因此，咱们在系统内部更多关注的是 SLO。

What we concern about Larger K8s Cluster?

随着生产环境不断发展、K8s 集群愈来愈复杂、集群规模不断增大。如何保障大规模环境 K8s 集群的可用性？是摆在众多厂家面前的一个难题。对于 K8s 集群，咱们一般关心如下几个问题：

• 第一个问题就是集群是否健康，全部组件是否正常工做，集群中 Pod 建立的失败数量有多少，这是一个总体指标的问题。

• 第二个问题就是集群中发生了什么，集群中是否有异常发生了，用户在集群中作了些什么事情，这是一个追踪能力的问题。

• 第三个问题就是有了异常后，是哪一个组件出了问题致使成功率下降，这是一个缘由定位的问题。

那么，咱们该如何解决上面的问题呢？

• 首先，咱们要定义一套 SLO，来描述集群的可用性。

• 接着，咱们必须有能力对集群中 Pod 的生命周期进行追踪；对于失败的 Pod，还须要分析出失败缘由，以快速定位异常组件。

• 最后，咱们要经过优化手段，消除集群的异常。

SLls on Large K8s Cluster

咱们先来看下集群的一些指标。

• 第一项指标：集群健康度。目前有 Healthy/Warning/Fatal 三个值来描述，Warning 和 Fatal 对应着告警体系，好比 P2 告警发生，那集群就是 Warning；若是 P0 告警发生，那集群就是 Fatal，必须进行处理。

• 第二项指标：成功率。这里的成功率是指 Pod 的建立成功率。Pod 成功率是一个很是重要的指标，蚂蚁一周 Pod 建立量是百万级的，成功率的波动会形成大量 Pod 的失败；并且 Pod 成功率的下跌，是集群异常的最直观反应。

• 第三项指标：残留 Terminating Pod 的数量。为何不用删除成功率呢？由于在百万级别的时候，即便 Pod 删除成功率达到 99.9%，那么 Terminating Pod 的数量也是千级别的。残留如此多的 Pod，会占着应用的容量，在生产环境中是不可接受的。

• 第四项指标：服务在线率。服务在线率是经过探针来衡量的，探针失败，意味着集群不可用。服务在线率是会对 Master 组件来设计的。

• 最后一项指标：故障机数量，这是一个节点维度的指标。故障机一般是指那些没法正确交付 Pod 的物理机，多是磁盘满了，多是 load 过高了。集群故障机并须作到“快速发现，快速隔离，及时修复”，毕竟故障机会对集群容量形成影响。

The success standard and reason classification

有了集群的指标后，咱们须要把这些指标进行细化，定义出成功的标准。

先来看 Pod 建立成功率指标。咱们把 Pod 分为了普通 Pod 和 Job 类 Pob。普通 Pod 的 RestartPolicy 为 Always，Job 类 Pod 的 RestartPlicy 为 Never 或 OnFailure。二者都设定有交付时间，好比必须在 1 分钟之内完成交付。普通 Pod 的交付标准是 1min 内 Pod 已经 Ready；Job 类 Pod 的交付标准是 1min 内 Pod 的状态已达 Running、Succeeded 或 Failed。固然建立的时间须要把 PostStartHook 执行时间排除。

对于 Pod 的删除，成功的标准为：在规定时间内，Pod 从 ETCD 内删除。固然，删除的时间须要把 PreStopHookPeriod 时间排除。

对于故障机，要尽快的发现并进行隔离和降级。好比物理机磁盘只读，那必须在 1min 内完成对该 Pod 打 taint。至于故障机的恢复时间，须要按不一样的故障缘由，制定不一样的恢复时间。好比系统故障须要重要安装系统，那恢复时间就会长些。

有了这些标准后，咱们也对 Pod 失败的缘由进行了整理，有些失败缘由是系统引发的，是咱们须要关心的；有些失败缘由是用户引起的，是咱们不须要关心的。

好比 RuntimeError，就是一个系统错误，底层 Runtime 有问题了；ImagePullFailed，Kubelet 下载镜像失败，因为蚂蚁有 Webhook 对镜像准入作了校验，全部镜像下载失败通常都是系统缘由形成的。

对于用户缘由，在系统侧没法解决，咱们只把这些失败缘由以接口查询的方式提供给用户，让用户本身解决。好比 ContainerCrashLoopBackOff，一般是由用户容器退出引发的。

The infrastructure

围绕 SLO 目标，咱们构建了一整套体系，一方面用于向终端用户、运维人员展现当前集群各项指标状；另外一方面，各个组件相互协做，经过分析当前集群状态，获得影响 SLO 的各项因素，为提高集群 pod 交付成功率提供数据支持。

自顶向下而看，顶层组件主要面向各类指标数据， 如集群健康状态、pod 建立、删除、升级成功率，残留 pods 数量、不健康节点数量等指标。其中 Display Board 就是咱们常说的监控大盘。

咱们一样构建了 Alert 告警子系统，支持灵活的配置方式，能够为不一样的指标，根据指标的下跌百分比，指标下跌绝对值等配置多种告警方式，如电话，短信，邮件等。

Analysis System 经过分析指标历史数据，以及采集到的节点 metrics 和 master 组件指标，给出更详细的集群运营报告。其中：

• Weekly Report 子系统给出当前集群本周 pod 建立/删除/升级的数据统计，以及失败案例缘由汇总。

• Terminating Pods Number 给出一段时间内集群内新增的没法经过 K8s 机制删除的 pods 列表和 pods 残留缘由。

• Unhealthy Nodes 则给出一个周期内集群全部节点的总可用时间占比，每一个节点的可用时间，运维记录，以及不能自动恢复，须要人工介入恢复的节点列表。

为了支撑上述这些功能，咱们开发了 Trace System，用来分析展现单个 pod 建立/删除/升级失败的具体缘由。其中包含日志和事件采集、数据分析和 pod 生命周期展现三个模块：

• 日志和事件采集模块采集各 master 组件以及节点组件的运行日志和 pod/node 事件，分别以 pod/node 为索引存储日志和事件。

• 数据分析模块分析还原出 pod 生命周期中各阶段用时，以及判断 pod 失败缘由及节点不可用缘由。

• 最后，由 Report 模块向终端用户暴露接口和 UI，向终端用户展现 pod 生命周期以及出错缘由。

The trace system

接下来，以一个 pod 建立失败案例为例，向你们展现下 tracing 系统的工做流程。

用户输入 pod uid 以后，tracing system 经过 pod 索引，查找到 pod 对应生命周期分析记录、交付成功与否断定结果。固然，storage 存储的数据不只为终端用户提供基础数据，更重要的是经过对集群内 pods 生命周期，分析出周期内集群的运营情况及每一个节点的运营情况。好比说集群内太多 pods 调度到热点节点，不一样 pods 的交付引发节点上资源竞争，致使节点负载过高，而交付能力却在降低，最终表现为节点上 pods 交付超时。

再举个例子，经过历史统计数据，分析出 pods 生命周期中各阶段的执行时间基线，以基线为评估标准，比较组件不一样版本的平均用时、用时分布，给出组件改进建议。另外，经过总体的 pods 生命周期中各组件负责的步骤时间占比，找出占比较多的步骤，为后续优化 pod 交付时间提供数据支持。

Node Metrics

一个运行情况良好的集群，不只须要 master 组件保持高可用，节点稳定性也不容忽视。

若是把 pod 建立比做是 rpc 调用，则每一个节点就是一个 rpc 服务提供者，集群的总容量等于每一个节点能处理的 pod 建立请求的总和。每多一个不可用的节点，都表明着集群交付能力的降低，也表明着集群可用资源的降低，这就要求尽可能保证集群内节点高可用；每一次 pod 交付/删除/升级失败，也意味着用户使用成本上升，体验降低，这就要求集群节点只有保证良好的健康度，调度到节点上的 pods 才能成功交付。

换句话说，不只要尽早发现节点异常，也要尽快修复节点。经过分析各组件在 pod 交付链路上的功能，咱们补充了各类不一样类型的组件的 metrics，以及将 host 运行状态转换为 metrics，一并采集到数据库以后，结合每一个节点上 pod 交付结果，能够构建模型预测节点可用性，分析节点是否存在不可恢复异常，适当调整节点在调度器中比重，从而提高 pod 交付成功率。

Pod 建立/升级失败，用户能够经过重试来解决，但 pod 删除失败，虽然有着 K8s 面向终态的理念，组件会不断重试，但终究也会存在脏数据，如 pod 在 etcd 上删除，可是节点上还残留着脏数据。咱们设计实现了一个巡检系统，经过查询 apiserver 获取调度到当前节点上的 pods，经过对比，找到节点上残留的进程/容器/volumes 目录/cgroup /网络设备等，经过其余途径尝试释放残留资源。

Unhealthy node

接下来描述故障机的处理流程。

故障机判断的数据来源有不少，主要有节点的监控指标，好比：

• 某类 Volume 挂载失败

• NPD(Node Problem Detector)，这是社区的一个框架

• Trace 系统，好比某个节点上 Pod 建立持续报镜像下载失败

• SLO，好比单机上残留大量 Pod

咱们开发了多个 Controller 对这些某类故障进行巡检，造成故障机列表。一个故障机能够有好几项故障。对于故障机，会按照故障进行不一样的操做。主要的操做有：打 Taint，防止 Pod 调度上去；下降 Node 的优先级；直接自动处理进行恢复。对于一些特殊缘由，好比磁盘满，那就须要人工介入排查。

故障机系统天天都会产生一个日报，来代表故障机系统今天作了哪些事情。开发人员能够经过不断地添加 Controller 和处理规则完善整个故障机处理系统。

Tips on increasing SLO

接下来，咱们来分享下达到高 SLO 的一些方法。

• 第一点，在提高成功率的进程中，咱们面临的最大问题就是镜像下载的问题。要知道，Pod 必须在规定时间内交付，而镜像下载一般须要很是多的时间。为此，咱们经过计算镜像下载时间，还专门设置了一个 ImagePullCostTime 的错误，即镜像下载时间太长，致使 Pod 没法按时交付。

还好，阿里镜像分发平台 Dragonfly 支持了 Image lazyload 技术，也就是支持远程镜像，在 Kubelet 建立容器时，不用再下载镜像。因此，这大大加速了 Pod 的交付速度。有关 Image lazyload 技术，你们能够看下阿里 Dragonfly 的分享。

• 第二点，对于提高单个 Pod 成功率，随着成功率的提高，难度也愈来愈难。能够引入一些 workload 进行重试。在蚂蚁，paas 平台会不断重试，直到 Pod 成功交付或者超时。固然，在重试时，以前的失败的节点须要排除。

• 第三点，关键的 Daemonset 必定要进行检查，若是关键 Daemonset 缺失，而把 Pod 调度上去，就很是容易出问题，从而影响建立/删除链路。这须要接入故障机体系。

• 第四点，不少 Plugin，如 CSI Plugin，是须要向 Kubelet 注册的。可能存在节点上一切正常，但向 Kubelet 注册的时候失败，这个节点一样没法提供 Pod 交付的服务，须要接入故障机体系。

• 最后一点，因为集群中的用户数量是很是多的，因此隔离很是重要。在权限隔离的基础上，还须要作到 QPS 隔离，及容量的隔离，防止一个用户的 Pod 把集群能力耗尽，从而保障其余用户的利益。

阿里云首场 Serverless 开发者线下沙龙亮相北京

本次线下活动将邀请来自阿里云、淘宝、闲鱼、百富旅行等国内一线 Serverless 技术专家，为开发者带来:

• 淘宝/天猫应对 双11 流量洪峰如何规模化实践 Serverless。
• 切中开发者痛点，讲述闲鱼、百富旅行等中国企业的 Serverless 落地及“踩坑”经验。
• 首次披露阿里云最新开源工具链 Serverless Devs 设计详情及将来走向。

点击连接当即报名：https://www.huodongxing.com/event/9570184556300

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”