问题描述
在使用 Prometheus 监控他的 Kubernetes 集群时，频繁收到有关 CPU 限制的报警信息（CPUThrottlingHigh）。他在 Prometheus 报警规则中看到以下内容：
alert: CPUThrottlingHigh
expr: 100 * sum by(container_name, pod_name, namespace) (increase(container_cpu_cfs_throttled_periods_total{container_name!=""}[5m])) / sum by(container_name, pod_name, namespace) (increase(container_cpu_cfs_periods_total[5m])) > 25
for: 15m
然而，当用户查看与此报警相关的某个容器时，该容器似乎没有出现需要进行 CPU 限制的情况：
$ kubectl top pod -n monitoring my-pod
NAME CPU(cores) MEMORY(bytes)
my-pod 0m 6Mi
该 pod 包含一个容器，并使用以下资源配置：
Limits:
cpu: 100m
memory: 128Mi
Requests:
cpu: 25m
memory: 64Mi
此外，托管该 pod 的节点的 CPU 使用率也未达到重负载状态：
$ kubectl -n monitoring top node aks-agentpool-node-1
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
aks-agentpool-node-1 853m 21% 11668Mi 101%
在 Grafana 中，查看与该 pod 相关的图表，CPU 使用率从未超过 0.000022。
用户想知道为什么会出现 CPU 限制的情况。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
用户提到的问题涉及到 Prometheus 报警规则以及 Kubernetes 集群的 CPU 限制问题。以下是解决该问题的几种方法：
方案1：了解问题来源
该报警规则来自于名为 CPUThrottlingHigh 的报警规则库。这个问题已经被开发者讨论过，你可以查看 #108 这个 GitHub 问题以更好地理解问题的根本原因。简单来说，问题在于在低 CPU 限制情况下，尖峰负载可能导致低平均负载，但仍然会出现限制情况。
另外，Kubernetes 项目中也有一个相关的讨论 #67577，涉及到 CFS 限额中的内核问题，可能导致不必要的 CPU 限制。目前，这个讨论仍在进行中，Kubernetes 项目甚至考虑在 Guaranteed QoS 中禁用 CFS 限额。你可以参考 #70585 了解详情。
针对这个问题，你可以考虑以下几个解决方案：
– 增加（甚至是移除）容器的 CPU 限制
– 完全禁用 Kubernetes 的 CFS 限额（通过 kubelet 的 --cpu-cfs-quota=false 参数）
– 使用包含这个修复的内核版本（torvalds/linux 512ac99）
方案2：调整报警规则
你也可以尝试根据实际情况调整报警规则。有用户提到可以在配置文件中找到 CPUThrottlingPercent 配置项，你可以尝试修改这个配置项的值以达到你期望的报警条件。
方案3：升级内核版本
根据上述讨论，内核版本可能会影响到 CPU 限制的问题。你可以考虑升级集群中的节点的内核版本，看看是否有相关的修复已经包含在其中。
请注意，采取这些措施前，请务必备份你的环境，并在生产环境中慎重操作。
结论
Prometheus 报警规则中的 CPUThrottlingHigh 报警可能是由于低 CPU 限制和尖峰负载造成的。你可以根据实际情况采取相应的解决方案来调整报警规则、调整资源配置或升级内核版本，以解决这个问题。当然，在采取任何操作之前，务必在非生产环境中进行测试以及做好充分的备份。