服务器K8s集群NVIDIA Triton排错：从Pod启动失败到推理验证全流程

知识分享

2026-10-16 08:40

6 阅读

在K8s集群里跑NVIDIA Triton，报错往往不在Triton本身，而在GPU调度、驱动版本、模型仓库挂载或端口配置这几层。
下面按排错顺序把最常见的问题和对应命令讲清楚，照着做基本能定位到具体环节。

先确认GPU节点和调度是否正常

Triton Pod起不来，第一步不是看Triton日志，而是确认Pod到底有没有拿到GPU。

登录集群管理节点，检查节点GPU资源是否被K8s识别：

kubectl get nodes -o custom-columns=NAME:.metadata.name,GPU:.status.allocatable.'nvidia\.com/gpu'

如果GPU列显示或0，说明NVIDIA设备插件没有正常工作。
继续检查插件Pod：

kubectl get pods -n kube-system | grep nvidia

正常情况下应该看到nvidia-device-plugin-daemonset处于Running状态。
如果它本身在CrashLoopBackOff，先解决插件问题，Triton排错才有意义。

确认节点有GPU资源后，再看Triton Pod的事件：

kubectl describe pod  -n

重点看Events区域。
出现Insufficient nvidia.com/gpu说明资源不够或被其他Pod占用；
出现FailedScheduling且提示节点亲和性，说明调度约束写错了。

Pod能调度到节点但容器起不来，通常是镜像、驱动或模型仓库的问题。

先看容器日志：

kubectl logs  -n  --previous

加--previous是为了看崩溃前的日志，容器反复重启时这一步很关键。

几个高频报错及处理方向：

CUDA driver version is insufficient for CUDA runtime version：节点驱动版本低于Triton镜像要求的CUDA版本。用nvidia-smi查看节点驱动，再对照Triton镜像文档确认支持的CUDA范围。不要盲目升级驱动，先确认集群里其他GPU任务是否依赖当前版本。
libcuda.so not found：容器没有正确挂载宿主机的NVIDIA驱动库。检查Pod是否通过runtimeClassName: nvidia或nvidia-container-runtime运行，而不是默认runc。
failed to load model repository：模型仓库路径不存在或权限不足。Triton默认从/models读取，确认这个目录在容器内可访问。

Triton的模型仓库结构必须是/models/<模型名>/<版本号>/，版本号目录名只能是数字。
挂载方式常见两种，排查点不同。

用hostPath挂载时，确认节点上路径真实存在且权限可读：

volumes:
  - name: models
    hostPath:
      path: /data/triton-models
      type: Directory

用PVC挂载时，先确认PVC处于Bound状态：

kubectl get pvc -n 
kubectl exec -it  -n  -- ls /models

如果ls报Permission denied，说明容器内运行用户没有读权限。
Triton镜像默认以非root用户运行，需要调整宿主机目录权限或在Pod的securityContext中指定合适的runAsUser。
修改权限前先备份模型文件，避免误操作导致数据丢失。

模型加载成功后，还需要验证服务真的能响应请求。
先检查Service和端口：

kubectl get svc -n 
kubectl get endpoints  -n

Endpoints为空说明Service没有选中任何Pod，检查Service的selector是否和Pod标签一致。
Triton默认HTTP端口是8000，gRPC是8001，metrics是8002。

在集群内做一次健康检查：

kubectl exec -it  -n  -- curl -v http://:8000/v2/health/ready

返回HTTP/1.1 200 OK说明服务就绪。
如果连接被拒绝，检查Pod是否处于Running且Readiness探针通过：

kubectl get pod  -n  -o jsonpath='{.status.conditions}'

从集群外访问时，还要确认Ingress或NodePort配置正确，以及防火墙是否放行了对应端口。
改防火墙规则前记录当前规则，方便回滚。

GPU显存被占满：Triton加载大模型时显存不足会导致进程被杀。先用nvidia-smi查看节点显存占用，再调整instance_group的数量或模型精度。
模型版本目录命名错误：版本目录不是纯数字，Triton会直接忽略该模型，日志里可能只有一行warning，容易漏看。
Config文件路径拼写：config.pbtxt必须放在模型目录下，文件名固定，大小写敏感。
镜像拉取失败：私有仓库需要配置imagePullSecrets，否则Pod会卡在ImagePullBackOff，事件里能看到具体原因。

修复后按这个顺序复查：Pod状态为Running且重启次数为0，Readiness探针通过，/v2/health/ready返回200，再用实际推理请求验证模型输出。
如果只是Pod起来了但推理结果异常，重点检查输入张量的名称、形状和数据类型是否与config.pbtxt中定义一致。

整个排错链路的核心思路是：先确认GPU资源可用，再看容器启动日志，然后检查模型仓库，最后验证服务请求。
每一层都有对应的命令和预期结果，不要跳步。