一次 KubeCPUOvercommit 告警排查过程小记

问题现象#

在配置好 Prometheus Operator Chart 一段时间后，我们决定开启由 kubernetes-mixin 项目提供的 alert rules，并将 AlertManager 和 Opsgenie 集成。在其后的几天里，每到傍晚六点钟左右就会出现 KubeCPUOvercommit 的告警：

排查过程#

最初的猜测#

根据报警信息，我们第一反应打开了 Grafana，开始查看 Compute Resources / Cluster dashboard 的数据，其中一个 panel 为 CPU Requests Commmitment，此时的数据确实超过了 100%。

但我们集群内安装了 Cluster Autoscaler，理论上不会出现 CPU Resource Requests 超量的情况，我们也在收到报警的时刻做了确认，当时并没有发现 unscheduled Pods。

难道是误报？我们打开了 panel 详情，提取了其中的表达式：

sum(kube_pod_container_resource_requests_cpu_cores{cluster="$cluster"})
/
sum(kube_node_status_allocatable_cpu_cores{cluster="$cluster"})Copy

随后通过 Grafana Explore 面板查看 kube_pod_container_resource_requests_cpu_cores metric，发现它并不包含任何关于 Pod status 的 label，于是我们开始怀疑：是否是此 metric 包含了 failed 和 completed 的 Pod 导致的？

验证猜测#

我们手动删除了一部分 failed 和 completed Pods 后 alert closed，Grafana dashboard 上的显示也降到了 100% 以下。我们以为找到了问题的原因，正当我们修复了 panel 的表达式，准备调整 alert rule 的时候，发现该报警规则的表达式（来源）是：

sum(namespace:kube_pod_container_resource_requests_cpu_cores:sum)
  /
sum(kube_node_status_allocatable_cpu_cores)
  >
(count(kube_node_status_allocatable_cpu_cores)-1) / count(kube_node_status_allocatable_cpu_cores)Copy

它的含义为：Pod所需要的CPU核心总数 / 可分配的核心总数 > (node数量 - 1) / node数量 则报警。

此处使用的是 namespacesum，并非 kube_pod_container_resource_requests_cpu_cores，因此之前的猜想错误。

再次 debug#

研究发现，namespacesum 是 Prometheus Operator Chart 自定义的 recording rule。

Recording rule 主要用于预先计算那些使用率高或是计算量较大的表达式，并将其结果保存为一组新的时间序列，这样不仅能够提高报警规则的计算速度，同时可以达到复用复杂表达式的效果。

leveloperations 是官方推荐的 recording rules 命名协定。

经过一番查找，该 recording rule 的表达式为（来源）：

sum by (namespace) (
    sum by (namespace, pod) (
        max by (namespace, pod, container) (
            kube_pod_container_resource_requests_cpu_cores{job="kube-state-metrics"}
        ) * on(namespace, pod) group_left() max by (namespace, pod) (
          kube_pod_status_phase{phase=~"Pending|Running"} == 1
        )
    )
)Copy

稍微有点长，我们简化一下，先看内层。

max by (namespace, pod, container) (
    kube_pod_container_resource_requests_cpu_cores{job="kube-state-metrics"}
)

* on(namespace, pod) group_left()

max by (namespace, pod) (
  kube_pod_status_phase{phase=~"Pending|Running"} == 1
)Copy

on(namespace, pod) group_left() 是 PromQL 的语法之一，直译为 向量匹配。本例的含义为：依次查找运算符（*）左侧样本中 namespace 和 Pod 相匹配的右侧样本，若有匹配则参与运算并形成新的时间序列，若未找到则直接丢弃样本。

另外此处的条件 kube_pod_status_phase{phase=~"Pending|Running"} == 1，表示 Pod 的状态必须是 pending 或 running，否则样本会被丢弃。

最后，在外层再进行一些聚合运算，recording rule namespacesum 就计算完成了：

sum by (namespace) (
    sum by (namespace, pod) (
        ...
    )
)Copy

经过排查，否定了我们的猜想，因为该时间序列已经排除了非 pending 或 running 状态的 Pod，它们的 resource requests 数值不会纳入到最终的样本中。

新的猜测和证实#

确定 namespacesum 没有问题后，我们仔细阅读告警的描述：

Cluster has overcommitted CPU resource requests for Pods and cannot tolerate node failure.

恍然发现它表述的意思是：集群已承受超量的 Pod CPU 资源请求，无法容忍 node 失效（例如节点崩溃、drain/taint 造成的 eviction 等）。

这么说来就可以解释为何 CPU 核心数的利用率 要与 (node数量 - 1) / node数量 做比较了。可简单地理解为：目前集群中的工作负载已不容许出现 Node 数量减少 1，一旦有 node 失效，Pod 所需要的 CPU 资源就超出集群的资源总量了。

问题解释#

综上所述，该 alert 属于「预警」，并非「报警」。它的出现是为了提示我们，为了保证高可用性应该扩容集群了。而不是已经出现了 unscheduled Pod。

因为有 Cluster Autoscaler 的存在，扩容操作不需要我们手动执行，因此文章开头提到的「手动删除一部分 failed Pod 后恢复正常」实际上是一个「迷惑行为」，此时刚好碰上新的 node 启动完成而已。

解决方案#

为了能够保证集群的超高可用（至少可以容忍一台 node 失效），我们需要 overprovisioning。虽然 Cluster Autoscaler 并没有直接提供参数实现，但我们在 FAQ 发现了一个小技巧：How can I configure overprovisioning with Cluster Autoscaler。

大致思路如下：

1. 创建较低的 PriorityClass，例如名为 overprovisioning 值为 -1。
2. 创建 Deployment 作为「占位」，将 spec.template.spec.priorityClassName 设置为 overprovisioning，同时配置 containers 的 resource requests 为预留的资源数量。
3. Cluster Autoscaler 将会 overprovisioned 一部分 node 以满足占位 Pods 的 resource requests。
4. 因为占位 Pods 优先级较低，在其它优先级较高的 Pods 需要资源时，占位 Pods 将会被驱逐，将预留的资源提供给其它 Pods。
5. 此时占位 Pods 无法被调度，Cluster Autoscaler 将会再次 overprovision 新的 node。

最终，在 kubernetes-mixin 项目中，修改告警规则的 ignoringOverprovisionedWorkloadSelector 配置。使用 Selectors 忽略 overprovisioned 的 Pods，使其不纳入工作负载的计算，即可让 Cluster Autoscaler 始终让我们的服务器保证多出当前的需求一台，来保证高可用性。

结语#

以上就是我们透过一次「误报」，排查后发现集群可用性存在的问题，并最终做出解决方案提高了可用性的经历。如果你有更好的实践，欢迎通过通过留言与我们交流。

本作品采用《CC 协议》，转载必须注明作者和本文链接