Kubernetes kube-state-metrics中Prometheus重复容忍度指标问题解析

问题背景

在Kubernetes监控体系中，kube-state-metrics作为关键组件，负责将Kubernetes对象状态转换为Prometheus可抓取的指标。近期在Prometheus 2.52.0及以上版本中，用户报告了一个与Pod容忍度(toleration)指标相关的警告问题。

问题现象

当Pod定义中包含重复的容忍度配置时，Prometheus会在抓取kube-state-metrics生成的指标时产生警告日志。例如，对于以下包含重复容忍度的Deployment定义：

tolerations:
 - key: CriticalAddonsOnly
   operator: Exists
 - key: CriticalAddonsOnly
   operator: Exists

Prometheus会记录如下警告：

Duplicate sample for timestamp
Error on ingesting samples with different value but same timestamp

技术分析

根本原因

1. Prometheus变更：从2.52.0版本开始，Prometheus加强了重复时间序列的检测机制，当发现相同时间戳下存在重复指标时会发出警告。

2. kube-state-metrics行为：当前kube-state-metrics会原样处理Pod定义中的所有容忍度，包括重复项，为每个容忍度生成独立的指标。

3. Kubernetes API特性：虽然Kubernetes API允许容忍度数组中存在重复项，但这在实际场景中并不合理，因为重复的容忍度不会提供额外的调度优势。

影响范围

• 使用Prometheus 2.52.0+版本监控集群
• 集群中存在定义重复容忍度的工作负载
• 使用kube-state-metrics收集Pod相关指标

解决方案

社区已提出并通过PR修复此问题，主要思路是：

1. 容忍度去重：在处理Pod容忍度时，首先对容忍度数组进行去重处理，确保只保留唯一的容忍度配置。

2. 指标生成优化：基于去重后的容忍度列表生成指标，避免产生重复的时间序列。

最佳实践建议

1. 检查工作负载定义：审核现有工作负载的容忍度配置，移除不必要的重复项。

2. 版本升级：对于使用kube-state-metrics的用户，建议升级到包含此修复的版本。

3. 配置验证：考虑在CI/CD流水线中添加检查，防止部署包含重复容忍度的工作负载。

技术启示

这个案例展示了监控系统各组件间的微妙交互关系。Prometheus的严格校验机制暴露了上游配置的不规范问题，而kube-state-metrics作为中间层，需要兼顾数据准确性和系统健壮性。它也提醒我们，在Kubernetes资源配置中，即使API允许的配置，在实际生产环境中也可能不是最佳实践。