K8s集群GPU算力与StorageOps：从挂载到验证的实操教程
在K8s集群里让GPU算力真正可用，关键不是装完驱动就结束，而是让节点、设备插件、容器运行时和存储卷形成一条可验证的链路。
本文面向刚接触GPU集群的运维人员，按准备、配置、验证、排错的顺序，把服务器K8s集群GPU算力StorageOps的落地过程拆成可照做的步骤。
先确认节点与驱动状态
GPU能否被调度，第一步取决于节点本身是否就绪。
登录每台GPU节点，执行以下检查：
nvidia-smi：确认能看到GPU型号、驱动版本和显存信息。如果命令不存在，先安装NVIDIA驱动。ls /dev/nvidia*：应看到/dev/nvidia0、/dev/nvidiactl等设备文件。kubectl get nodes -o wide：确认节点处于Ready状态，且kubelet版本与集群一致。
如果nvidia-smi正常但K8s里看不到GPU资源，问题通常不在驱动，而在设备插件或容器运行时配置。
安装GPU设备插件并声明算力
Kubernetes本身不识别GPU，需要通过设备插件把节点上的GPU暴露成可调度资源。
常用做法是部署NVIDIA设备插件：
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.14.5/nvidia-device-plugin.yml部署后检查DaemonSet是否在每个GPU节点上运行：
kubectl get pods -n kube-system -l name=nvidia-device-plugin-ds
kubectl describe node | grep nvidia.com/gpu 预期结果是节点资源里出现nvidia.com/gpu: 1或对应卡数。
如果显示为0，先看插件Pod日志：
kubectl logs -n kube-system 常见原因是containerd或Docker未配置NVIDIA运行时，或节点上存在旧版插件残留。
让Pod正确使用GPU与存储
声明GPU算力时，Pod的resources.limits必须写nvidia.com/gpu，且requests与limits保持一致。
示例片段：
resources:
limits:
nvidia.com/gpu: 1StorageOps在这里的作用是保证GPU任务能稳定读写数据。
GPU训练或推理常需要挂载数据集、模型目录和临时缓存：
- 数据集用PVC挂载到
/data，避免每次重建容器重复下载。 - 模型输出目录挂载到持久卷，防止Pod重启后结果丢失。
- 临时缓存可用emptyDir，但要评估容量，避免占满节点磁盘。
挂载后进入Pod验证：
kubectl exec -it -- nvidia-smi
kubectl exec -it -- df -h /data 两条命令分别确认GPU可见和存储卷可读写，缺一不可。
容易踩坑的几个地方
- 只给limits不给requests，或两者数值不一致，调度器可能无法正确分配。
- 节点驱动升级后没有重启kubelet或设备插件，导致资源声明失效。
- 多个Pod共享同一块GPU时未做显存隔离，容易出现OOM。
- 存储卷权限配置为root，而容器内以非root用户运行，导致写入失败。
遇到GPU任务Pending时，先执行kubectl describe pod查看事件，再结合节点资源kubectl describe node判断是算力不足还是存储卷未绑定。
验证整条链路是否通畅
完成配置后，用一个小任务做端到端验证：创建一个申请1块GPU并挂载PVC的Pod，确认它能正常启动、执行nvidia-smi、写入挂载目录，然后删除。
如果这四步都通过，说明服务器K8s集群GPU算力StorageOps的基本链路已经可用。
后续再根据业务调整GPU共享策略、存储性能和监控告警即可。
