Kubernetes kube-state-metrics 服务阻塞问题分析与解决方案

问题现象

在较大规模的 Kubernetes 集群中，kube-state-metrics 服务偶尔会出现无法被 Prometheus 或 Grafana Alloy 成功抓取指标的情况。当尝试通过 curl 访问 /metrics 端点时，请求会在处理到特定指标（通常是 Pod 干扰预算相关指标）时挂起。此时服务会进入不可用状态，唯一的恢复方法是重启受影响的 kube-state-metrics Pod。

问题根源

经过深入分析，发现问题源于服务端的并发控制机制存在缺陷。当多个客户端同时发起指标请求时，如果某些客户端未能正确关闭连接（例如网络中断或客户端异常），会导致服务端的 goroutine 持续堆积。这些未释放的 goroutine 最终会阻塞核心的指标更新操作，形成死锁状态。

通过 goroutine dump 分析可以观察到：

1. 大量 goroutine 阻塞在读取操作上
2. 关键指标更新操作被单个 goroutine 持有的写锁阻塞
3. 随着时间推移，goroutine 数量持续增长而不释放

技术细节

问题的核心在于 metrics_store 模块中的并发控制机制。当 MetricsStore 执行 Add/Update 操作时，会获取一个排他锁（RWMutex.Lock）。如果此时有大量未完成的 HTTP 请求占用着 goroutine，这些 goroutine 会阻塞后续的写操作，进而导致整个服务停止响应。

解决方案

针对这个问题，社区提出了以下改进方案：

1. 为指标服务器添加请求超时机制：确保客户端连接在超时后会被强制关闭，防止 goroutine 泄漏
2. 优化并发控制逻辑：减少关键路径上的锁竞争
3. 改进资源清理机制：确保异常情况下的资源及时释放

影响范围

这个问题在以下环境中表现尤为明显：

• 大规模 Kubernetes 集群（节点数多、Pod 数量大）
• 高频率指标抓取场景
• 网络不稳定的环境
• 使用 sharding 模式部署的 kube-state-metrics

最佳实践建议

对于生产环境用户，建议：

1. 及时升级到包含此修复的版本
2. 合理配置抓取间隔，避免过高频率的请求
3. 监控服务的 goroutine 数量，设置适当的告警阈值
4. 考虑使用 sharding 部署模式分散压力

总结

kube-state-metrics 的服务阻塞问题是一个典型的并发控制和资源管理问题。通过添加适当的超时机制和优化并发处理逻辑，可以有效避免服务因客户端异常而导致的不可用情况。这个问题也提醒我们在设计高性能服务时，需要特别注意资源清理和并发控制机制的健壮性。