GKE私有集群Chronograf Chart启动探针失败：原因及解决方法

在全新的GKE私有集群中安装Chronograf Helm Chart后，出现启动探针失败的问题，事件日志如下：

Type Reason Age From Message

---

...
Normal Pulled 6m7s (x4 over 7m34s) kubelet Container image "chronograf:1.9.4" already present on machine
Normal Created 6m7s (x4 over 7m34s) kubelet Created container chronograf
Normal Killing 6m7s (x3 over 7m7s) kubelet Container chronograf failed startup probe, will be restarted
Normal Started 6m5s (x4 over 7m33s) kubelet Started container chronograf
Warning Unhealthy 5m57s (x10 over 7m27s) kubelet Startup probe failed: Get "http://172.17.0.132:8888/ping": dial tcp 172.17.0.132:8888: connect: connection refused
Warning BackOff 2m30s (x11 over 5m7s) kubelet Back-off restarting failed container

原因分析 #

• 探针配置过严：默认启动探针的初始等待时间、检测周期或失败阈值设置不合理，Chronograf在私有集群环境下启动较慢，未完全就绪就被判定失败。
• 网络访问受限：GKE私有集群的Pod网络策略或节点防火墙规则，可能阻止了kubelet访问Pod的8888端口。
• 服务启动异常：容器内Chronograf未正常启动，可能是缺少InfluxDB连接配置、资源分配不足导致启动卡住。

解决方法 #

1. 调整启动探针参数 #

修改Helm values.yaml，放宽启动探针的检测条件：

startupProbe:
  httpGet:
    path: /ping
    port: 8888
  initialDelaySeconds: 30  # 延长初始等待时间，给服务足够启动时间
  periodSeconds: 10        # 拉长每次检测的间隔
  failureThreshold: 10     # 允许更多次失败重试

执行Helm升级命令应用配置：

helm upgrade chronograf influxdata/chronograf -f values.yaml

2. 排查网络访问限制 #

• 检查集群的Pod网络策略，确保未限制kubelet到Pod的8888端口通信，若存在限制，添加允许规则。
• 确认节点防火墙规则，放行集群内部Pod与kubelet之间的通信流量。

3. 排查Chronograf启动异常 #

• 查看容器日志，确认服务启动状态：

kubectl logs -l app=chronograf

• 若日志显示缺少InfluxDB配置，在values.yaml中补充连接信息：

influxdb:
  url: "http://your-influxdb-service:8086"
  username: "admin"
  password: "your-password"

• 若资源不足导致启动缓慢，调整Pod的资源请求与限制：

resources:
  requests:
    cpu: "100m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

内容的提问来源于stack exchange，提问作者Dims