K8s 集群里 Weaviate 起不来或连不上怎么排错

Weaviate 跑在 K8s 里出问题，通常先看 Pod 状态，再顺着事件、日志、探针和 Service 逐层查。
本文按零基础也能照做的顺序，讲清部署在 Kubernetes 集群中的 Weaviate 出现启动失败、健康检查不过、外部连不上时该怎么排。

先确认现象和基础环境

在动手改配置之前，先把现象说清楚，不同现象对应不同排查方向：

• Pod 一直 Pending：多半是资源不足、节点选择或存储卷没绑定。
• Pod 反复重启，状态显示 CrashLoopBackOff：容器进程启动后退出，重点看容器日志。
• Pod 是 Running 但 READY 为 0/1：readinessProbe 没通过，通常是端口、路径或启动时间问题。
• 集群内能访问、外部访问失败：问题在 Service 类型、端口映射或入口配置。

先确认你能操作目标集群，并且 kubectl 上下文正确：

kubectl config current-context
kubectl get nodes
kubectl get pods -n <你的命名空间> -o wide

如果命名空间里根本没有 Weaviate 相关 Pod，先检查部署清单是否已应用，而不是直接怀疑 Weaviate 本身。

按顺序排查 Pod 层问题

Pod 卡在 Pending

用 describe 看调度事件，这是最直接的入口：

kubectl describe pod  -n <命名空间>

重点看 Events 段落：

• 出现 Insufficient cpu 或 Insufficient memory：节点资源不足，需要降低 resources.requests 或扩容节点。
• 出现 node(s) didn't match node selector：检查部署里的 nodeSelector、affinity 是否写死了不存在的标签。
• 出现 pod has unbound immediate PersistentVolumeClaims：存储卷没绑定，检查 StorageClass 名称和 PVC 状态。

查看 PVC 状态：

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

Pod 反复重启

先看日志，不要只看状态：

kubectl logs  -n <命名空间> --previous

--previous 用来查看上一次崩溃前的日志。
常见原因包括：

• 配置文件字段写错，Weaviate 启动时解析失败。
• 数据目录权限不对，容器内进程无法写入。
• 内存限制过低，进程被 OOMKilled。用 kubectl describe pod 查看 Last State 里是否出现 OOMKilled。

如果是 OOMKilled，适当调高 resources.limits.memory，同时确认节点本身还有可用内存。

Running 但 Readiness 不通过

Weaviate 默认会暴露健康检查端口。
探针配置错误是新手最常见的问题之一。
检查部署清单里的探针部分：

readinessProbe:
  httpGet:
    path: /v1/.well-known/ready
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

要核对三件事：

• path 是否和当前 Weaviate 版本提供的健康路径一致。
• port 是否和容器实际监听端口一致。
• initialDelaySeconds 是否太短，导致容器还没启动完就被判定失败。

验证容器内端口是否真的在监听：

kubectl exec -it  -n <命名空间> -- sh
# 进入容器后
wget -qO- http://localhost:8080/v1/.well-known/ready

如果容器内访问正常、探针却失败，优先检查探针的 port 和 path，而不是重装。

服务访问不通时查什么

Pod 正常但连不上，按“集群内 → 集群外”的顺序查。

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

kubectl run curl-test --rm -it --image=curlimages/curl -- sh
# 进入后访问 Service 名
curl http://.<命名空间>.svc.cluster.local:8080/v1/.well-known/ready

如果集群内能通、集群外不通，检查：

• Service 的 type 是 ClusterIP 还是 NodePort/LoadBalancer。
• Service 的 targetPort 是否等于容器实际监听端口，而不是想当然写的端口。
• Ingress 或网关的路径、后端 Service 名、命名空间是否正确。

查看 Service 和 Endpoints：

kubectl get svc -n <命名空间>
kubectl get endpoints  -n <命名空间>

如果 Endpoints 为空，
说明 Service 没有选中任何就绪的 Pod，
回到探针和标签选择器排查，
重点核对 Service 的 selector 和 Pod 的 labels 是否一致。

几个容易踩的坑

• 只改 Deployment 不改 Service，端口对不上，外部一直连不通。
• 探针 initialDelaySeconds 设成 0，启动稍慢就反复重启。
• 存储卷权限没设置，容器以非 root 运行却写不进数据目录。
• 命名空间写错，kubectl 默认操作 default，实际部署在别的命名空间。
• 把 ClusterIP 当成公网可访问地址，误判为网络故障。

怎么确认已经修好

不要只看 Pod 变成 Running 就收工。
按下面几项复查：

• kubectl get pods 中 READY 为 1/1，且重启次数不再增长。
• kubectl get endpoints 中 Service 已有对应 Pod 地址。
• 集群内 curl 健康检查路径返回成功。
• 集群外通过你配置的入口访问时，能拿到正常响应。

如果这几项都通过，再观察一段时间，确认没有再次重启或探针抖动。

常见疑问

Weaviate Pod 一直重启，但日志没有明显报错怎么办？
先看 kubectl describe pod 里的 Last State 是否显示 OOMKilled，这类情况日志往往来不及输出。同时用 --previous 查看上一次容器日志。

改完探针配置后 Pod 还是没就绪？
确认改动已生效，可以 kubectl get pod -o yaml 查看实际生效的配置，避免编辑了错误的清单文件或命名空间。

集群内能访问，外部死活连不上，一定是网络问题吗？
不一定。优先核对 Service 的 type、targetPort 和入口配置，这类配置错误比底层网络故障更常见。

如果你正在处理服务器 K8s 集群 Weaviate 排错，
建议先按“Pod 状态 → 事件 → 日志 → 探针 → Service”的顺序走一遍，
再针对具体报错做微调，
多数问题能在这几步内定位。