模型评测 Job 卡住：从 PodGroup 到镜像预检的排查记录

这次问题发生在一套模型评测环境。目标很简单：提交一个 Indexed Job，4 个 worker 分别跑一组评测样本。集群已经开始验证 Kubernetes v1.36 的工作负载感知调度，理论上这类任务适合用 PodGroup 做成组调度。

结果 Job 没跑起来。第一眼看像 GPU 没分到，实际看事件才发现卡在镜像拉取。

现场现象

bash 复制代码

kubectl get pod -n ai-lab -owide

输出里 4 个 worker 都被调度到了 GPU 节点，但状态不一致：有的在 ContainerCreating，有的已经进入 ImagePullBackOff。

继续看事件：

bash 复制代码

kubectl get events -n ai-lab --sort-by=.lastTimestamp
kubectl describe pod -n ai-lab eval-worker-0

关键日志是：

text 复制代码

Failed to pull image "vllm/vllm-openai:latest"
context deadline exceeded
Back-off pulling image

这时就不要继续改 nvidia.com/gpu 了。GPU 是资源层，ImagePullBackOff 是运行前置层。

第一层：确认 PodGroup 没卡住

如果启用了 v1.36 相关 Alpha 特性，可以先看 PodGroup：

bash 复制代码

kubectl get podgroup -n ai-lab
kubectl describe podgroup -n ai-lab eval-workers-pg

我主要看三点：

minCount 是否满足。
PodGroup 是否有未满足的拓扑约束。
是否还有 ResourceClaim 相关事件。

这次 PodGroup 层没有继续报错。说明调度组基本过了，问题往下走。

第二层：把镜像按来源拆开

原始 Job 里只写了一个业务镜像，但实际启动链路不止它：

类型	示例	作用
业务镜像	`vllm/vllm-openai`	模型服务
CUDA 镜像	`nvidia/cuda`	运行时验证
K8s 基础镜像	`pause`	Pod 沙箱
监控组件	`prometheus/node-exporter`	指标采集

到节点上逐个测：

bash 复制代码

sudo crictl pull docker.1ms.run/vllm/vllm-openai:latest
sudo crictl pull nvcr.1ms.run/nvidia/cuda:12.4.1-runtime-ubuntu22.04
sudo crictl pull k8s.1ms.run/pause:3.10
sudo crictl pull quay.1ms.run/prometheus/node-exporter:v1.8.2

这样做的好处是，故障会从"Job 卡住了"变成"某个来源在某台节点上拉不通"。粒度一下就细了。

第三层：Job 里直接固定镜像入口

调整后的片段：

yaml 复制代码

apiVersion: batch/v1
kind: Job
metadata:
  name: eval-job
  namespace: ai-lab
spec:
  completionMode: Indexed
  parallelism: 4
  completions: 4
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: worker
          image: docker.1ms.run/vllm/vllm-openai:latest
          env:
            - name: MODEL_PATH
              value: /models/qwen
          resources:
            limits:
              nvidia.com/gpu: "1"

如果团队已经有私有仓库，这里可以替换成内部镜像地址。我的原则是：不要让同一个 Job 同时依赖一堆不稳定入口，至少发布前要预检。

第四层：验证容器内 GPU 和模型目录

镜像拉通之后，再看 GPU 和模型目录：

bash 复制代码

kubectl exec -n ai-lab eval-worker-0 -- nvidia-smi
kubectl exec -n ai-lab eval-worker-0 -- ls -lh /models/qwen
kubectl logs -n ai-lab eval-worker-0 --tail=80

如果 nvidia-smi 失败，再回到 GPU Operator、device plugin、runtime class。

如果模型目录为空，再查 PVC、挂载路径和 init container。

如果服务起来但探针失败，再看端口和 readinessProbe。

复盘

v1.36 的工作负载感知调度让一组 Pod 可以被更像"一个任务"那样处理，这对模型评测、分布式训练、批处理都很有用。但工程现场里，调度只是第一段。

我这次的结论是：

PodGroup 先确认整组能不能被放置。
镜像预检要在目标节点做，不要只在开发机验证。
多源镜像最好提前分组，不要等 Pod 事件里出现超时。
业务真正启动后，再看 GPU、模型目录和探针。

这样排下来，比直接在 YAML 里来回改资源声明清楚很多。