K8s集群OceanBase排错：Pod起不来、连不上、OBServer异常排查

在K8s集群里跑OceanBase，出问题一般集中在三类：Pod起不来、OBServer进程异常、客户端连不上。
排查顺序建议从外到内——先看Pod状态和事件，再进容器看OBServer日志，最后检查网络和存储。
下面按这个顺序展开。

先确认故障范围：Pod还是OBServer

OceanBase在K8s上通常由OceanBase Operator或Helm Chart部署，每个OBServer对应一个Pod。
先看Pod整体状态：

kubectl get pods -n oceanbase -o wide

重点看STATUS和RESTARTS。
常见状态含义：

• Pending：调度失败，多半是资源不足、节点亲和性冲突或PVC未绑定。
• CrashLoopBackOff：容器启动后反复退出，需要看容器日志。
• Running但未Ready：OBServer进程活着但没通过就绪探针，通常是内部初始化或端口问题。

同时查看事件，事件里往往直接给出原因：

kubectl describe pod  -n oceanbase | tail -30
kubectl get events -n oceanbase --sort-by=.lastTimestamp

如果Pod是Pending，重点看describe输出里Events段的FailedScheduling信息；
如果是CrashLoopBackOff，先看容器日志。

进容器看OBServer日志

Pod状态异常时，日志是最直接的线索：

kubectl logs  -n oceanbase --tail=200
kubectl logs  -n oceanbase -c  --previous

--previous用于查看上一次崩溃的日志。
OceanBase的observer日志通常落在容器内/home/admin/oceanbase/log目录，可以进容器直接看：

kubectl exec -it  -n oceanbase -- bash
cd /home/admin/oceanbase/log
ls -lt observer.log*
tail -n 200 observer.log

关注日志里的错误级别和关键词，比如ERROR、WARN、fail to、timeout。
常见原因包括：

• 数据目录权限不对，OBServer无法写入。
• 配置项里指定的IP、端口与K8s Service不一致。
• 内存不足，OBServer启动时检测到可用内存低于最低要求。
• 时钟偏移过大，导致选举或事务异常。

检查资源配置与存储挂载

OceanBase对内存和磁盘有明确要求，K8s里如果requests/limits设得太小，OBServer可能启动失败或频繁重启。
查看Pod的资源定义：

kubectl get pod  -n oceanbase -o yaml | grep -A 10 resources

确认memory和cpu是否满足OceanBase的最低要求。
如果用的是本地PV或NFS，检查挂载是否成功：

kubectl exec -it  -n oceanbase -- df -h
kubectl exec -it  -n oceanbase -- ls -ld /home/admin/oceanbase/store

如果PVC一直Pending，查看PVC和StorageClass：

kubectl get pvc -n oceanbase
kubectl describe pvc  -n oceanbase

存储问题在K8s上很常见，尤其是多节点集群里节点亲和性和PV节点不匹配的情况。

网络与连接问题排查

客户端连不上OceanBase时，先确认Pod之间和Pod到Service的连通性。

从集群内另一个Pod测试端口：

kubectl run -it --rm debug --image=busybox -n oceanbase -- sh
telnet  2881
telnet  2881

2881是OceanBase的SQL端口，2882是RPC端口。
如果Pod IP通但Service不通，检查Service的selector和Endpoints：

kubectl get svc -n oceanbase
kubectl get endpoints -n oceanbase
kubectl describe svc  -n oceanbase

Endpoints为空说明Service没有匹配到Pod，通常是label不一致。
如果集群外访问，检查NodePort或LoadBalancer配置，以及节点防火墙是否放行对应端口。

另外注意OceanBase的obshell或rootservice相关端口是否在NetworkPolicy中被拦截。

避坑提醒

• 不要直接删除OBServer的Pod来“重启”，在OceanBase集群里可能触发不必要的副本迁移，先确认副本状态和Leader分布。
• 修改配置项后不要只重启Pod，部分参数需要走OceanBase的ALTER SYSTEM SET或obshell命令生效，具体以当前版本支持的方式为准。
• 如果集群本身处于不可用状态，先保证多数派副本在线，再处理单个异常节点。
• 时间同步要在所有节点保持一致，K8s节点和容器内时间偏移过大会导致OceanBase选举异常。

验证恢复

修复后按以下顺序确认：

1. kubectl get pods -n oceanbase 所有OBServer Pod为Running且Ready。
2. 进入任一Pod，用obclient或mysql连接2881端口，执行SELECT 1;。
3. 查看OceanBase内部视图确认副本和Zone状态正常，例如查询DBA_OB_SERVERS或GV$OB_SERVERS，具体视图名以当前版本为准。
4. 观察一段时间内Pod没有再次重启，日志中不再出现同类ERROR。

如果问题反复出现，建议把Pod事件、OBServer日志和资源配置一起保留，方便对比分析。