K8s集群里跑OpenLLM总报错？按这套流程排查更快定位
在K8s集群里跑OpenLLM，最常见的现象是Pod一直处于Pending、CrashLoopBackOff，或者模型服务起来了但外部访问超时。
排查顺序建议固定为：先看Pod状态和事件，再看容器日志，然后检查资源和调度，最后验证Service和网络。
确认故障现象和排查入口
先执行以下命令拿到全局状态，不要一上来就改配置：
kubectl get pods -n <命名空间> -o wide
kubectl describe pod -n <命名空间>
kubectl logs -n <命名空间> --previous describe输出里的Events段通常直接给出原因，比如镜像拉取失败、节点资源不足、探针失败。--previous用于查看上一次崩溃容器的日志，Pod反复重启时非常关键。
如果Pod状态是Pending，重点看Events里的调度失败信息；
如果是CrashLoopBackOff，重点看容器日志最后几十行；
如果是Running但服务不通，问题通常在Service、探针或端口配置。
镜像、资源和调度相关报错
镜像拉取失败时，Events里会出现ErrImagePull或ImagePullBackOff。
检查镜像地址是否完整、私有仓库Secret是否配置正确：
kubectl get secret -n <命名空间>
kubectl describe pod -n <命名空间> | grep -A3 Events 如果使用私有镜像仓库，需要确认imagePullSecrets在Deployment的Pod模板里已声明。
缺少这一项时，节点无法拉取镜像。
显存不足或GPU不可用是OpenLLM部署中的高频问题。
先确认节点是否暴露了GPU资源：
kubectl describe node <节点名> | grep -i nvidia如果看不到nvidia.com/gpu资源，说明节点上的GPU设备插件没有正常工作，需要先修好设备插件，再调整OpenLLM的资源请求。
资源请求写得太小会导致调度到无GPU节点，写得太大则会一直Pending。
探针和启动参数导致的反复重启
OpenLLM加载模型需要时间，
如果readinessProbe或livenessProbe的initialDelaySeconds设得太短，
容器还没加载完就被判定为失败，
进而被杀掉重启。
readinessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 60
periodSeconds: 10
livenessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 120
periodSeconds: 20模型越大，首次加载时间越长。
建议先临时去掉livenessProbe，只保留readinessProbe，确认服务能正常启动后再逐步收紧参数。
同时检查容器启动命令里的模型名称、路径和端口是否与探针、Service保持一致。
Service和访问链路验证
Pod Running且日志无报错，但外部访问失败时，按下面的链路逐层验证：
kubectl get svc -n <命名空间>
kubectl get endpoints <服务名> -n <命名空间>
kubectl exec -it -n <命名空间> -- curl localhost:3000/health 如果Endpoints为空，说明Service的selector和Pod标签不匹配，检查Deployment里的labels与Service的selector是否一致。
Ingress访问异常时，再检查Ingress的serviceName、servicePort和后端端口是否对应。
常见疑问
Pod一直Pending，但节点资源看起来够用？
检查是否有节点亲和性、污点容忍或资源请求过大导致无法调度。kubectl describe pod的Events里会写明具体原因。
日志没有明显报错，但服务响应很慢？
可能是模型加载后显存接近上限，或请求排队。
查看nvidia-smi输出和Pod的CPU、内存使用情况，确认是否需要调整副本数或资源限制。
修改Deployment后没有生效？
确认是否执行了kubectl apply，以及镜像标签是否使用了固定版本而不是latest。
使用latest时节点可能不会重新拉取镜像。
排查完成后，建议把Pod状态、Events关键行、日志报错和修复动作记录下来，方便下次同类问题快速对照。
如果集群里同时跑多个模型服务，优先统一探针参数和资源模板，能减少重复排错成本。
