Kubernetes kube-state-metrics中Endpoint地址重复问题深度解析

问题背景

在Kubernetes监控体系中，kube-state-metrics作为关键组件，负责将Kubernetes对象状态转换为Prometheus可采集的指标。近期在Prometheus 2.52版本环境中，用户频繁遇到指标重复的告警问题，特别是kube_endpoint_address指标出现完全相同的时序数据被重复采集的情况。

问题现象

典型的问题表现包括：

1. Prometheus日志中出现"Error on ingesting samples with different value but same timestamp"警告
2. 调试日志显示kube_endpoint_address指标的完全相同的标签组合被重复采集
3. 问题端点通常具有多个端口配置，例如同时暴露9090和10901端口的Prometheus实例

根本原因分析

经过深入分析，发现问题的核心在于kube-state-metrics对Endpoint对象的处理逻辑存在缺陷：

1. Kubernetes的Endpoint对象允许同一个IP地址出现在不同子集(subset)中，每个子集可以定义不同的端口组合
2. 当前kube_endpoint_address指标仅包含namespace、endpoint、ip和ready标签，没有考虑子集和端口的区分
3. 当同一IP地址服务于多个端口时（如主服务端口和监控端口），就会生成完全相同的指标标签组合

技术影响

这种设计缺陷导致多个严重后果：

1. 指标重复导致Prometheus存储膨胀
2. 可能影响基于这些指标的告警规则准确性
3. 资源使用量统计出现偏差
4. 违反了Prometheus指标唯一性的基本原则

解决方案探讨

社区目前提出了几种改进方向：

1. 增加子集索引标签：为kube_endpoint_address添加subset标签，标识地址所属的子集序号
2. 合并指标设计：将kube_endpoint_address和kube_endpoint_ports合并为kube_endpoint_subsets统一指标
3. 添加端口标签：在地址指标中增加port标签，同时标记原有端口指标为弃用

从Kubernetes的Endpoint验证逻辑来看，方案1和3更具可行性，因为Kubernetes本身允许不同子集中存在相同的IP/端口组合。

临时解决方案

在官方修复发布前，可以考虑：

1. 调整Endpoint配置，避免同一IP服务多个端口
2. 在Prometheus配置中使用metric_relabel_configs过滤重复指标
3. 对告警规则增加容错处理

最佳实践建议

基于此问题的经验，建议：

1. 设计自定义指标时充分考虑Kubernetes对象的完整状态表示
2. 指标标签应足够区分所有可能的业务场景
3. 新功能上线前进行充分的边界条件测试
4. 监控系统升级时关注指标兼容性说明

这个问题凸显了Kubernetes监控体系中组件间协同工作的重要性，也提醒我们在设计指标时需要考虑实际业务场景的所有可能性。随着云原生监控体系的不断发展，这类问题将推动监控组件向更健壮的方向演进。