服务器K8s集群AntDB排错：从Pod异常到服务恢复的完整流程

知识分享

2026-10-16 00:40

6 阅读

在K8s集群里跑AntDB，报错往往不会直接告诉你根因。
可能是Pod调度失败、存储挂载超时、Service转发异常，也可能是AntDB自身的主从同步或连接数打满。
下面按“先定位层级，再逐层收窄”的顺序，给出可执行的排查步骤。

先判断问题出在K8s层还是AntDB层

不要一上来就翻数据库日志。
先用几条命令确认Pod本身是否正常：

kubectl get pods -n <命名空间> -o wide
kubectl describe pod  -n <命名空间>
kubectl logs  -n <命名空间> --tail=100

看三个关键点：

STATUS：Running不代表服务可用，CrashLoopBackOff、Pending、Error才是明确异常。
describe 的 Events：如果出现FailedMount、Insufficient cpu、ImagePullBackOff，问题在K8s侧，先解决调度或存储，不用翻AntDB日志。
logs：如果Pod能稳定运行但连接失败，再看AntDB进程日志，通常位于容器内/var/log/antdb/或数据目录下的log文件夹。

一个快速判断方法：kubectl exec -it -n <命名空间> -- bash进入容器，执行ps -ef | grep antdb。
如果进程不在，说明容器启动脚本或AntDB自身启动失败；
如果进程在但端口不通，问题更可能在网络或认证配置。

AntDB默认端口常见为5432或自定义端口，先确认Service和Endpoints：

kubectl get svc -n <命名空间>
kubectl get endpoints  -n <命名空间>
kubectl exec -it <任意pod> -n <命名空间> -- nc -zv  <端口>

Endpoints为空通常意味着Pod的readinessProbe没通过。
检查探针配置：

readinessProbe:
  tcpSocket:
    port: 5432
  initialDelaySeconds: 10
  periodSeconds: 5

如果探针端口和AntDB实际监听端口不一致，Pod会一直处于未就绪状态，Service自然没有后端。
改完探针后执行kubectl apply -f <配置文件>，再观察kubectl get endpoints是否出现Pod IP。

容器内验证监听状态：

kubectl exec -it  -n <命名空间> -- netstat -tlnp | grep <端口>

没有输出说明AntDB没有监听成功，需要回到AntDB日志看是否因配置错误退出。

AntDB对数据目录持久化要求高，PVC挂载失败是高频问题。
执行：

kubectl get pvc -n <命名空间>
kubectl describe pvc  -n <命名空间>

重点关注Status是否为Bound，以及Events中是否有waiting for a volume to be created或mount failed。
如果PVC一直Pending，先确认StorageClass是否存在：

kubectl get storageclass

没有可用StorageClass时，需要先部署存储插件或改用已有PV手动绑定。
挂载失败时不要直接删除PVC，先确认数据是否需要保留，再决定重建顺序。

集群模式下AntDB常见主从复制中断。
进入主库执行：

SELECT * FROM pg_stat_replication;

如果state不是streaming，或replay_lag持续增大，说明从库同步异常。
再到从库检查：

SELECT * FROM pg_stat_wal_receiver;

常见原因包括：

网络策略阻断了主从端口，用kubectl get networkpolicy -n <命名空间>确认是否有策略限制了Pod间通信。
从库数据目录被重新挂载导致时间线不一致，此时需要按AntDB文档重建从库，不要直接强制启动。
主库max_wal_senders或max_replication_slots不足，检查postgresql.conf中相关参数是否被容器启动脚本覆盖。

修复后观察pg_stat_replication的state恢复为streaming，并持续观察几分钟确认延迟不再增长。

不要直接删Pod了事：StatefulSet管理的AntDB Pod删除后会重建，但PVC和配置问题不解决，新Pod会再次失败。
修改配置前先备份：涉及postgresql.conf、pg_hba.conf或StatefulSet模板的改动，建议先kubectl get statefulset <名称> -n <命名空间> -o yaml > backup.yaml。
日志级别不要长期开debug：排错时临时调高可以，排查完记得恢复，否则日志量会快速占满存储。
资源限制要看实际使用：kubectl top pod可以看当前CPU和内存，如果接近limits，OOMKilled会表现为Pod反复重启，但日志里未必有AntDB错误。

完成修复后，按下面顺序确认服务真正恢复：

如果以上都通过但业务仍报错，问题可能已经不在数据库层，需要检查应用侧连接串、密码或防火墙规则。

排查AntDB在K8s中的问题，核心思路是先确认Pod和存储是否正常，再进入数据库层看进程、端口和复制状态。
每一步都有对应的命令和观察点，按顺序执行能避免在无关日志里浪费时间。