为什么我的 Kubernetes Job 仍然处于 Pending 状态？使用 Headlamp 追踪 Kueue 准入
内容提要
Kueue 管理的 Job 可能因未获准入而挂起。Headlamp 的 Kueue 插件（0.1.0-alpha，只读）可查看 Workload、LocalQueue、ClusterQueue、ResourceFlavor 和 Cohort。排查时先看 Workload 的 Admitted 与 QuotaReserved 条件：未准入则检查队列配额；已准入但 Pod 仍 Pending，则转查调度事件。
延伸解读
Kueue 准入与 Pod 调度的分界
文章强调 Kueue 准入和 Kubernetes 调度器解决不同问题：Kueue 决定 Workload 是否应开始，考虑队列策略、配额、ResourceFlavor 等；调度器决定准入后 Pod 运行在哪个节点。因此排查时，若 Workload 未准入，应留在 Kueue 相关视图；若已准入但 Pod 仍 Pending，则转向 Job、Pod 和调度器事件。这一分界是高效定位问题的关键。
从 Workload 条件入手排查
排查挂起 Job 时，应首先查看 Workload 的 QuotaReserved 和 Admitted 条件。Admitted=True 表示已准入，Job 可恢复；QuotaReserved=False 且原因为 Pending 表示配额未预留，条件消息会解释原因。Inadmissible 状态则表明 Workload 无法适应当前队列配置。同时检查 Events 部分，了解近期变化或 Kueue 的尝试。
沿队列链路定位配额瓶颈
通过 Headlamp 可沿 Workload → LocalQueue → ClusterQueue → ResourceFlavor/Cohort 链路排查。LocalQueue 显示命名空间入口和连接状态；ClusterQueue 展示集群级配额、预留和使用情况；ResourceFlavor 和 Cohort 帮助理解硬件类别和共享配额。例如，若 ClusterQueue 仅提供 2 个 CPU 和 2 个 Pod 槽位，而 Workload 请求 3 个，则因配额不足无法准入。
插件能力与使用限制
Headlamp 的 Kueue 插件 0.1.0-alpha 为只读视图，支持查看 Kueue v1beta2 的 Cohort、ClusterQueue、LocalQueue、ResourceFlavor 和 Workload，但不提供创建、编辑、暂停、恢复或删除操作。Workload 的 owner 引用显示为文本且不可点击。插件依赖 Headlamp 身份对 Kueue 资源的读取权限，权限不足时会显示访问消息。它不替代 kubectl 或 kueuectl 用于脚本和精确输出。
Q&A
Kubernetes Job 一直处于 Pending 状态，怎么判断是不是 Kueue 没有准入？
在 Headlamp 中打开 Kueue → Workloads，找到该 Job 对应的 Workload，查看其 Admitted 和 QuotaReserved 条件。如果 Admitted=True，说明 Kueue 已准入，Pod 仍 Pending 应转查调度事件；如果 QuotaReserved=False 且原因为 Pending，则 Kueue 尚未预留配额，需继续检查队列配额。
Headlamp 的 Kueue 插件 0.1.0-alpha 能查看哪些资源？
该插件提供只读视图，可查看 Kueue v1beta2 的 Cohorts、ClusterQueues、LocalQueues、ResourceFlavors 和 Workloads。它不添加自己的创建、编辑、停止、恢复或删除工作流，但 Headlamp 仍提供标准的 YAML 和资源操作（取决于权限）。
Workload 显示 QuotaReserved=False 且原因为 Pending，应该检查哪些 Kueue 资源？
应依次检查：Workload 的 PodSets 和资源请求；LocalQueue 的状态和连接的 ClusterQueue；ClusterQueue 的配额、预留、使用和策略；以及 ResourceFlavor 或 Cohort 详情（如果消息指向 flavor 选择或共享配额）。
Workload 已准入但 Pod 仍然 Pending，接下来该查什么？
应转到 Headlamp 的标准 Kubernetes 视图：打开 Workloads → Jobs 检查 Job 状态和事件；打开 Workloads → Pods 按 Job 名称或命名空间过滤；选择 Pending Pod 查看 Events，关注节点容量不足、节点亲和性、污点与容忍、拓扑约束、持久卷绑定或镜像拉取失败等调度问题。
Kueue 的 LocalQueue 和 ClusterQueue 分别是什么？在 Headlamp 中如何查看？
LocalQueue 是命名空间级别的入口，将 Workload 连接到集群级别的 ClusterQueue。在 Headlamp 中，从 Workload 详情页点击 LocalQueue 链接可查看其命名空间、连接的 ClusterQueue、停止策略、状态以及 pending/reserving/admitted 的 Workload 数量；再点击 ClusterQueue 链接可查看覆盖资源、名义配额、当前预留和使用、借用/借出限制、排队策略和停止策略等。
为什么我的 Job 请求 3 个 Pod 但 ClusterQueue 只有 2 个 CPU 配额，会导致 Pending 吗？
会。Kueue 会评估整个 Workload 的总请求。如果 Job 的 parallelism 为 3 且每个 Pod 请求 1 CPU，则总请求为 3 CPU 和 3 个 Pod 槽位。若 ClusterQueue 名义配额只有 2 CPU 和 2 个 Pod 槽位，Workload 无法适配，Kueue 会保持 Job 挂起，直到配额可用或队列配置更改。
Headlamp 的 Kueue 插件能替代 kubectl 或 kueuectl 吗？
不能。该插件不替代 kubectl 或 kueuectl 用于脚本、精确对象输出或更改操作。它替代的是交互式调查中重复的无界面导航，帮助更快地阅读准入状态和资源关系。对于脚本和 GitOps 工作流，命令行仍是正确工具。
