如何在Kubernetes中对CnosDB进行健康检查？含API与最佳实践

CnosDB的健康检查API支持 #

CnosDB提供了专门的RESTful风格健康检查端点，用于Kubernetes的存活（liveness）和就绪（readiness）探测：

• 存活探测端点：/health/live，用于判断实例是否正常运行，返回非200状态码时，Kubernetes会触发实例重启
• 就绪探测端点：/health/ready，用于判断实例是否已准备好接收请求，返回非200状态码时，Kubernetes会将实例从服务端点池中移除

这些端点默认通过CnosDB的HTTP服务端口（通常为8902，可根据实际配置调整）提供服务，只需发送HTTP GET请求即可验证状态。

Kubernetes中的健康检查配置示例 #

在CnosDB的Deployment资源中，添加livenessProbe和readinessProbe配置即可完成健康检查设置，示例如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cnosdb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cnosdb
  template:
    metadata:
      labels:
        app: cnosdb
    spec:
      containers:
      - name: cnosdb
        image: cnosdb/cnosdb:latest
        ports:
        - containerPort: 8902
        # 存活探测：判断实例是否存活，异常则重启
        livenessProbe:
          httpGet:
            path: /health/live
            port: 8902
          initialDelaySeconds: 30  # 容器启动后延迟30s开始首次探测，适配启动耗时
          periodSeconds: 10        # 每10s探测一次
          failureThreshold: 3      # 连续3次失败触发重启
        # 就绪探测：判断实例是否可提供服务，异常则移除端点
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8902
          initialDelaySeconds: 10  # 启动后10s开始首次就绪探测
          periodSeconds: 5         # 每5s探测一次
          failureThreshold: 2      # 连续2次失败移除端点

健康检查最佳实践 #

• 严格区分存活与就绪探测：存活探测关注实例是否还在运行，就绪探测关注实例是否能正常处理请求，不要混用同一个端点，避免出现实例存活但无法提供服务时仍被流量命中的情况
• 适配探测参数：
  • initialDelaySeconds需根据CnosDB实际启动耗时调整，避免过早探测导致误判重启；集群模式下可适当延长该值
  • periodSeconds不要设置过短（不小于5s），避免给实例带来额外负载；也不要过长，保证能及时发现故障
• 结合日志与监控：健康检查失败时，优先查看CnosDB容器日志定位问题（比如磁盘满、内存不足、集群节点失联等），同时可配合Prometheus等监控工具跟踪实例状态
• 集群部署额外验证：如果是CnosDB集群模式，除了基础HTTP端点探测，还可以通过exec探测执行简单的集群状态查询命令，比如：

  readinessProbe:
    exec:
      command: ["cnosdb-cli", "-e", "SHOW CLUSTER"]
    initialDelaySeconds: 20
    periodSeconds: 8
  

• 避免过度依赖单一探测方式：HTTP端点是基础探测，结合exec命令做补充验证，能更全面地覆盖实例异常场景

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