先判断：卡在准入，还是调度？
提交 Job 后迟迟没有应用日志，甚至找不到 Pod，不应直接归因于节点资源不足。在由 Kueue 管理的集群中，Job 可能仍处于挂起状态，等待对应 Workload 获准运行。
这篇长勺智库技术笔记聚焦一个排查顺序：先确认 Kueue 准入，再检查 Kubernetes 调度。
这两层机制的职责不同：
- Kueue 决定工作负载现在能否启动：涉及队列策略、配额、资源风味（ResourceFlavor）、准入检查，以及其他等待任务。
- Kubernetes 调度器决定 Pod 放在哪些节点上：这发生在准入通过、Job 恢复之后。
因此，第一步应该问“Workload 是否已经准入”，而不是直接问“Pod 为什么 Pending”。
从 Workload 沿关联对象排查
Headlamp 的 Kueue 插件提供了一条可视化排查路径：从 Workload 入手，查看状态条件及其消息，再沿关联关系检查 LocalQueue、ClusterQueue、ResourceFlavor 和 Cohort。
这样可以先建立上下文，避免一开始就在多个对象的 YAML 之间反复切换。
根据准入状态，可以把排查分成两条路径：
| 当前状态 | 下一步检查什么 |
|---|---|
| Workload 尚未准入 | 继续检查 Kueue 对象，根据状态消息定位队列、配额或准入检查环节的等待原因 |
| Workload 已经准入，但 Pod 仍为 Pending | 转到常规 Job、Pod 页面，查看调度事件 |
关键是不要混淆两层问题：尚未准入时，优先查 Kueue；已经准入且 Pod Pending 时，再查 Pod 调度。
注意插件的能力边界
使用这条可视化路径，需要满足以下前提：
- 集群已安装 Kueue。
- 已部署 Headlamp。
- 当前用户具备相关资源的读取权限。
这里介绍的 Kueue 插件版本为 0.1.0-alpha，提供相关资源的只读视图，不自带创建、编辑、停止、恢复或删除流程。
因此，应把“看清状态”和“执行变更”分开考虑：插件可以帮助定位等待发生在哪一层，但后续操作仍需使用相应的管理流程。
