首页
/ Grafana Helm Charts中Gateway API健康检查问题解决方案

Grafana Helm Charts中Gateway API健康检查问题解决方案

2025-07-08 03:37:44作者:凌朦慧Richard

问题背景

在使用kube-prometheus-stack部署Grafana并通过Kubernetes Gateway API暴露服务时,用户遇到了"no healthy upstream"错误。这个问题特别出现在使用Azure Application Gateway for Containers作为入口控制器时。虽然其他服务可以正常路由,但Grafana服务却无法正常工作。

问题分析

经过技术讨论和分析,发现问题的根源在于Grafana的健康检查机制。Grafana默认会将请求重定向到/login页面(返回302状态码),而大多数入口控制器期望的健康检查响应是2xx状态码。这种不匹配导致入口控制器认为服务不健康,从而拒绝路由流量。

解决方案

1. 创建自定义健康检查策略

正确的解决方案是为Grafana服务创建专门的健康检查策略,指定正确的健康检查端点。Grafana提供了一个专用的健康检查端点/api/health,这个端点会返回200状态码,非常适合用于健康检查。

apiVersion: alb.networking.azure.io/v1
kind: HealthCheckPolicy
metadata:
  name: grafana-health-check-policy
  namespace: monitoring
spec:
  targetRef:
    group: ""
    kind: Service
    name: centralhub-developer-tools-grafana
  default:
    http:
      path: /api/health
    useTLS: false

2. 关键配置说明

  • path: 必须设置为/api/health,这是Grafana的健康检查端点
  • namespace: 健康检查策略必须与目标服务位于同一命名空间
  • targetRef: 必须正确指向Grafana服务

3. 常见错误配置

  1. 错误的健康检查路径:使用根路径/会导致302重定向
  2. 跨命名空间问题:健康检查策略与服务不在同一命名空间
  3. 端口配置错误:未正确指定服务端口或Pod端口
  4. 不必要的host配置:可能导致健康检查失败

最佳实践建议

  1. 使用与就绪探针相同的路径:通常应用的健康检查端点与Kubernetes就绪探针使用的路径一致
  2. 简化配置:开始时使用最小配置,只指定必要的path参数
  3. 命名空间一致性:确保健康检查策略与目标服务位于同一命名空间
  4. 逐步调试:先验证健康检查端点是否可达,再配置入口控制器

总结

通过正确配置健康检查策略,指定Grafana的健康检查端点/api/health,可以解决"no healthy upstream"问题。这个问题不仅限于Grafana,其他会进行重定向的应用(如Keycloak)也可能遇到类似问题,都可以通过类似方法解决。理解入口控制器健康检查机制与应用程序行为的匹配关系,是解决这类问题的关键。

对于使用Azure Application Gateway for Containers的用户,还需要特别注意健康检查策略的API版本和字段名称与特定入口控制器的要求保持一致。

登录后查看全文
热门项目推荐
相关项目推荐