K8s集群里Databend查询失败怎么排查：从Pod状态到日志定位

Databend 跑在 K8s 集群里出问题时，最直接的排查入口不是数据库本身，而是先用 kubectl 确认 Pod 到底处于什么状态。
如果 Pod 反复重启或卡在 Pending，后面查 SQL 日志意义不大；
如果 Pod 正常但查询超时，才需要往网络、资源和服务发现方向查。

先确认 Databend 组件的运行状态

Databend 在 K8s 中通常拆成 meta、query、storage 三类角色（按实际部署方式命名可能不同），排查前先拿到准确的 Pod 列表和命名空间。

kubectl get pods -n databend -o wide

重点看三个字段：

• STATUS：Running 才继续往下查；CrashLoopBackOff、Pending、Error 都对应不同处理路径。
• RESTARTS：次数持续增长说明容器启动后立刻退出，优先看上一次崩溃日志。
• READY：1/1 才算就绪，0/1 常是探针或端口未监听。

如果 Pod 处于 CrashLoopBackOff，直接看上一次退出前的日志：

kubectl logs  -n databend --previous

如果 Pod 处于 Pending，问题一般在调度层，看事件更快：

kubectl describe pod  -n databend | tail -30

常见事件是 Insufficient cpu、Insufficient memory 或 PVC 未绑定，对应扩容节点或检查 StorageClass。

日志里优先抓这几类错误

Pod 状态正常时，日志是定位 Databend 自身问题的主要依据。
不要一上来就翻全部输出，先过滤关键词：

kubectl logs  -n databend | grep -iE "error|panic|timeout|refused|denied"

几个典型现象和处理方向：

• 连接 meta 超时或拒绝：检查 meta 服务是否 Ready，Service 名称和端口是否与 query 配置一致。
• 存储层报权限或 403：确认对象存储的 AccessKey、SecretKey、Bucket 和 Endpoint 配置没有写错，尤其注意 Secret 是否已正确挂载。
• 内存不足被 OOMKilled：kubectl describe pod 里看到 Reason: OOMKilled，需要调大 resources.limits.memory 或降低并发查询量。
• 端口监听失败：确认容器端口与 Service 的 targetPort 一致，常见错误是改了配置但没同步改 Service。

如果日志量太大，可以只看最近一段时间：

kubectl logs  -n databend --since=10m

网络与服务发现的验证方法

很多“查不出结果”其实是集群内网络问题，而不是 Databend 本身。
推荐按下面顺序验证。

先在集群内起一个临时 Pod 测试连通性：

kubectl run nettest --rm -it --image=busybox -n databend -- sh

进入后依次测试：

nslookup databend-meta.databend.svc.cluster.local
nc -zv databend-meta 9191
nc -zv databend-query 8000

如果 DNS 解析失败，检查 CoreDNS 是否正常；
如果端口不通，检查 Service 的 selector 是否匹配到 Pod 标签。
用下面命令对比：

kubectl get svc -n databend -o wide
kubectl get pods -n databend --show-labels

Service 的 Endpoints 为空，说明标签没对上，这是很常见的配置遗漏。

资源和配置的常见坑

Databend 对内存和磁盘 IO 比较敏感，K8s 里最容易踩的坑集中在三处：

• 内存 limit 设得太低：查询稍大就 OOMKilled，表现为 Pod 反复重启。建议先给 query 角色留出足够余量，再观察实际峰值。
• PVC 容量或性能不足：meta 或缓存盘写满会导致启动失败，用 kubectl exec 进去 df -h 确认。
• 探针配置过严：livenessProbe 的 initialDelaySeconds 太短，服务还没起来就被判定失败并重启，形成循环。适当放宽启动探针。

修改资源配置后，用滚动更新并观察：

kubectl rollout status statefulset/ -n databend
kubectl get pods -n databend -w

修复后怎么确认真的恢复了

不要只看 Pod 变成 Running 就结束，至少做两步验证：

1. 用客户端连接 query 端口，执行一条简单查询，例如 SELECT 1;，确认能返回结果。
2. 观察 5 到 10 分钟内 RESTARTS 是否还在增长，若稳定不再增加，说明启动循环已解除。

如果查询仍然超时，回到日志和网络部分，重点看是否还有连接 meta 或存储层失败的记录。

几个容易被问到的问题

Pod 是 Running 但查询一直超时，先查什么？
先查 Service 的 Endpoints 是否为空，再在集群内用临时 Pod 测试端口连通性，排除网络层后再看 Databend 日志。

Databend 频繁 OOMKilled 怎么处理？
先调大 query 角色的内存 limit，同时检查是否有异常大查询或并发过高，必要时限制单次查询资源。

改了配置后 Pod 起不来怎么办？
用 kubectl describe pod 看事件，再用 --previous 看崩溃前日志，多数情况是配置项拼写错误或 Secret 未挂载。

整体思路可以记成一句话：先看 Pod 状态，再看日志关键词，然后验证网络和 Service，最后检查资源和探针配置。
按这个顺序走，大多数 K8s 集群里 Databend 的排错都能在较短时间内定位到具体环节。