UDS Core项目中Prometheus监控节点容器指标缺失问题解析
项目地址: https://gitcode.com/gh_mirrors/ud/uds-core 问题背景
在UDS Core项目的实际部署中，我们发现了一个关于Prometheus监控功能的重要问题：当Kubernetes集群中存在多个节点时，Prometheus只能采集到控制平面节点上的容器指标（如CPU和内存使用率），而无法获取工作节点上的容器指标数据。这个问题在k3d多节点集群环境中得到了复现和验证。
问题现象
通过Prometheus查询container_cpu_usage_seconds等容器指标时，指标数据仅来自控制平面节点上的Pod。当尝试过滤掉控制平面节点后，查询结果为空，表明工作节点上的容器指标完全缺失。
根本原因分析
经过深入排查，发现问题出在monitoring命名空间下的网络策略(NetworkPolicy)配置上。具体来说，allow-prometheus-stack-egress-metrics-scraping这个由operator生成的网络策略存在配置不足的问题。该策略中remoteNamespace: ""的配置过于严格，导致Prometheus无法与工作节点上的prometheus-node-exporter守护进程Pod建立连接。
临时解决方案
在问题定位过程中，我们发现了一个临时解决方案：移除monitoring命名空间中的所有网络策略后，Prometheus能够正常采集所有节点上的指标数据。这进一步验证了问题确实与网络策略配置相关。
技术实现方案
针对这个问题，项目团队提出了一个更为完善的解决方案：
-
构建AllNodes目标集合：创建一个新的
AllNodes生成目标，类似于现有的KubeAPI目标实现方式。这个目标集合将通过Pepr监控Kubernetes节点列表动态构建。 -
动态节点IP管理：利用Pepr的watch机制实时跟踪节点状态变化，自动维护所有节点IP地址列表。这种动态管理方式能够适应集群规模变化，确保新加入的节点也能被及时纳入监控范围。
-
网络策略优化：将生成的
AllNodes目标应用到Prometheus的网络策略中，替代原有的过于严格的配置，确保Prometheus能够访问所有节点上的指标暴露端点。
解决方案优势
这一解决方案不仅解决了当前的监控数据缺失问题，还具有以下优势：
- 自动化管理：节点IP列表自动维护，无需人工干预
- 安全性保持：仍然通过网络策略实施必要的访问控制
- 扩展性强：该机制可复用于其他需要访问所有节点的服务（如metrics-server）
- 稳定性高：动态调整能力确保集群变更时监控不中断
实施效果
该解决方案实施后，Prometheus能够稳定可靠地采集集群中所有节点（包括控制平面节点和工作节点）上的容器指标数据，为集群监控提供了完整的数据支持。同时，必要的网络安全策略仍然得到保持，不会降低集群的安全性水平。
经验总结
这个案例展示了在Kubernetes环境中实施细粒度网络策略时需要考虑的全面性。特别是在监控系统这类需要跨节点访问的组件配置上，必须确保网络策略既提供必要的安全隔离，又不会过度限制系统核心功能的正常运行。动态目标生成机制为解决这类问题提供了优雅的方案。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
