服务器K8s集群Seldon Core排错：从Pod异常到推理服务恢复
Seldon Core 是跑在 Kubernetes 上的模型推理服务框架，排错时不要先改配置，而是按“看 Pod 状态 → 查事件 → 读容器日志 → 核对存储和资源 → 验证接口”的顺序推进。
下面步骤适用于已经用 Helm 或 YAML 部署过 Seldon Core、但推理服务没有正常就绪的 K8s 集群。
先确认集群和 Seldon 控制面是否正常
排错前先排除底层问题。
执行以下命令确认节点、Seldon 控制器和 webhook 都在运行：
kubectl get nodes
kubectl get pods -n seldon-system
kubectl get svc -n seldon-system如果 seldon-controller-manager 处于 CrashLoopBackOff 或 Pending，先解决控制器问题，否则后面创建的推理服务不会生效。
常见原因是命名空间资源不足或镜像拉取失败，可以用 kubectl describe pod -n seldon-system 查看 Events。
从推理 Pod 状态定位故障类型
假设你的推理服务部署在 default 命名空间，先看 Pod 处于什么状态：
kubectl get pods
kubectl describe pod <推理Pod名>
kubectl logs <推理Pod名> -c <容器名>不同状态对应不同方向：
Pending：通常是资源不足、节点选择器不匹配或 PVC 未绑定。ImagePullBackOff：镜像地址写错、私有仓库密钥缺失或网络无法访问镜像仓库。CrashLoopBackOff：模型文件缺失、启动命令错误或端口配置冲突。Running但READY 0/1：就绪探针失败，常见于模型加载慢或探针路径不对。
先根据状态缩小范围，不要一上来就重装 Seldon Core。
模型存储和挂载是最容易出问题的一环
Seldon Core 支持从 PVC、S3、GCS 等位置加载模型。
如果日志里出现 No such file or directory、Failed to download model 或 Permission denied，按下面顺序检查：
kubectl get pvc
kubectl describe pvc
kubectl exec -it <推理Pod名> -- ls -l /mnt/models 重点检查三件事：
- PVC 是否已经
Bound，如果一直是Pending，说明 StorageClass 或容量有问题。 - 模型路径是否和 SeldonDeployment 里
storageUri一致，大小写和斜杠都要对。 - 容器内运行用户是否有读权限，尤其是从 NFS 或 hostPath 挂载时。
如果是 S3 或 MinIO，确认 Secret 中的 access_key、secret_key、endpoint 没有多余空格，并且集群内 DNS 能解析到对象存储地址。
资源限制和探针配置要一起看
模型加载阶段 CPU 和内存占用会明显上升。
如果 Pod 被 OOMKilled，kubectl describe pod 里会看到 Reason: OOMKilled。
此时不要只加内存，还要检查 resources.requests 和 limits 是否合理：
resources:
requests:
memory: "1Gi"
cpu: "500m"
limits:
memory: "2Gi"
cpu: "1"就绪探针失败时，先确认探针路径和端口与容器实际监听一致。
Seldon Core 默认会暴露 HTTP 端口，如果你的模型服务启动较慢，可以适当调大 initialDelaySeconds，但不要盲目调到几分钟，否则会掩盖真实启动错误。
网络策略和 Service 访问验证
如果 Pod 已经 Running 且 Ready，但外部调用推理接口超时，检查 Service 和 Ingress：
kubectl get svc
kubectl get ingress
kubectl get networkpolicy确认 Service 的 targetPort 与容器端口一致，NetworkPolicy 没有拦截来自 ingress-controller 或调用方的流量。
可以在集群内临时起一个测试 Pod 验证连通性：
kubectl run curl-test --image=curlimages/curl -it --rm -- sh
curl http://.<命名空间>:<端口>/v1/models 如果集群内能通、集群外不通，问题多半在 Ingress 或负载均衡层，而不是 Seldon Core 本身。
改完配置后如何确认恢复
每次修改 SeldonDeployment 或相关 Secret 后，先看 rollout 状态：
kubectl get seldondeployment
kubectl rollout status deployment <推理Deployment名>
kubectl get pods -w等到 Pod 显示 READY 1/1 后，再调用一次推理接口，确认返回状态码和响应内容正常。
如果仍然失败，回到 kubectl logs 和 kubectl describe pod，重点看最近一次 Events 和容器退出码。
常见疑问
Seldon Core 排错时最先看什么？
先看 kubectl get pods 和 kubectl describe pod，确认 Pod 状态和 Events，再决定查日志还是查存储。
模型加载慢导致就绪探针失败怎么办？
先确认模型确实在加载而不是卡死，再适当调大探针的 initialDelaySeconds 和 failureThreshold，同时检查存储读取速度。
改了 SeldonDeployment 没有生效？
确认控制器 Pod 正常运行，并且修改后的资源已经成功 apply。可以用 kubectl get seldondeployment -o yaml 核对实际生效的配置。
整体思路是先分层定位，再针对性修复。
服务器 K8s 集群 Seldon Core 排错的关键不是背命令，而是按 Pod 状态、事件、日志、存储、网络这个顺序逐层排除，最后用接口调用验证结果。
