Grafana Agent中Kubernetes服务发现配置问题排查指南

问题背景

在使用Grafana Agent收集Kubernetes集群日志时，开发人员遇到了kubernetes_sd_configs配置不生效的问题。具体表现为Agent无法通过Kubernetes服务发现机制获取Pod日志，且通过API查询targets时返回空列表。

配置分析

典型的Grafana Agent日志收集配置包含以下几个关键部分：

1. 服务发现配置：使用kubernetes_sd_configs定义Pod角色的服务发现
2. 日志路径映射：通过relabel_configs将Kubernetes元数据转换为日志文件路径
3. 标签重写：提取Pod标签和元数据作为日志标签

示例配置中正确设置了：

• Pod元数据到日志标签的映射
• 使用__meta_kubernetes_pod_uid构造容器日志路径
• 必要的标签转换规则

根本原因

经过深入排查，发现问题根源在于环境变量配置。Agent容器中设置了HTTP_PROXY和HTTPS_PROXY环境变量用于其他用途，但这些代理设置意外拦截了Agent与Kubernetes API Server（kubernetes.default.svc）之间的通信。

解决方案

1. 添加NO_PROXY设置：在容器环境变量中明确排除Kubernetes API Server的地址

   env:
   - name: NO_PROXY
     value: "kubernetes.default.svc,.svc,.svc.cluster.local"
   

2. 验证配置生效：通过以下方式确认服务发现正常工作

   • 检查Agent的/targets端点返回预期目标
   • 确认日志开始正常收集

最佳实践建议

1. 网络配置隔离：对于需要访问集群内部服务的组件，应明确排除代理设置
2. 权限验证：确保ServiceAccount具有足够的权限（get/list/watch pods等）
3. 调试技巧：
   • 使用Agent的调试接口验证配置加载
   • 检查Agent日志获取详细错误信息
   • 临时增加日志级别辅助排查

总结

Kubernetes环境中的网络代理配置可能对服务发现机制产生意外影响。通过合理配置NO_PROXY环境变量，可以确保Grafana Agent能够正常访问Kubernetes API进行服务发现。这个问题也提醒我们在配置复杂系统时，需要考虑各组件的网络访问需求及其相互影响。

对于生产环境部署，建议在配置代理时始终明确排除集群内部服务地址，并定期验证服务发现功能的正常工作状态。