Grafana Kubernetes 仪表板优化：过滤已下线节点的最佳实践

在 Kubernetes 集群监控中，Grafana 仪表板是运维团队的重要工具。本文将深入探讨如何优化 dotdc/grafana-dashboards-kubernetes 项目中的节点视图仪表板，特别是针对动态伸缩环境下的节点过滤问题。

问题背景

在 AWS EKS 配合 Karpenter 的动态环境中，工作节点会频繁地被替换和回收。当前 Kubernetes/Views/Nodes 仪表板中的节点变量查询使用的是 kube_node_info 指标的标签值查询，这种方法会返回所有历史节点记录，包括已经下线的节点。

这种设计会导致两个主要问题：

1. 节点下拉框中包含大量已不存在的节点
2. 影响用户体验和查询效率

技术分析

核心问题在于当前的变量查询方式没有考虑时间范围过滤。仪表板使用的是 Label values 查询类型，它会返回指标的所有历史标签值，而不考虑所选时间范围内这些节点是否活跃。

解决方案

经过社区讨论，提出了一种改进方案：

1. 将变量查询类型从"Label values"改为"Query result"
2. 使用 Prometheus 查询表达式：kube_node_info{cluster="$cluster"}
3. 配合正则表达式过滤：/node="(?<value>[^"]+)/

这种改进有以下优势：

• 只返回在选定时间范围内有活动指标的节点
• 完全兼容现有仪表板功能
• 不会显著影响查询性能

实现细节

在技术实现上，需要注意以下几点：

1. 标签映射问题：Kubernetes 监控中 node 和 instance 标签之间存在特殊映射关系，这是为了支持通过节点名称而非IP地址进行查询。

2. 兼容性考虑：虽然方案在 VictoriaMetrics 中测试通过，但在原生 Prometheus 环境中仍需验证。

3. 性能影响：新的查询方式可能会增加少量查询负载，但在实际测试中这种影响可以忽略不计。

最佳实践建议

对于类似动态环境，建议：

1. 定期审查和更新仪表板配置
2. 考虑节点生命周期管理策略
3. 监控查询性能指标
4. 在测试环境充分验证变更

总结

通过优化节点过滤机制，可以显著提升 Kubernetes 监控仪表板在动态环境中的实用性和用户体验。这一改进不仅解决了已下线节点显示的问题，也为类似场景提供了可参考的解决方案模式。

对于使用 Karpenter 或其他自动伸缩方案的用户，这一优化尤为重要。它确保了监控视图始终反映集群的真实状态，避免了历史节点数据造成的干扰。