故障排除 on Kueue

Job 故障排除

Thu, 21 Mar 2024 00:00:00 +0000

本文档介绍如何排除挂起的 Kubernetes Jobs 的故障，但大多数想法可以推广到其他支持的作业类型。

请参阅 Kueue 概览以可视化协作运行 Job 的组件。

在本文档中，假设你的 Job 名为 my-job，位于 my-namespace 命名空间中。

识别你的 Job 对应的 Workload

对于每个 Job，Kueue 创建一个 Workload 对象来保存 Job 准入的详细信息，无论它是否被准入。

要找到 Job 对应的 Workload，你可以使用以下任一步骤：

你可以通过运行以下命令从 Job 事件中获取 Workload 名称：

kubectl describe job -n my-namespace my-job

队列故障排除

Thu, 21 Mar 2024 00:00:00 +0000

为什么 LocalQueue 中没有 workload 被准入？

LocalQueue 的状态包含 LocalQueue 上任何配置问题的详细信息，作为 Active 条件的一部分。

运行以下命令查看 LocalQueue 的状态：

kubectl get localqueue -n my-namespace my-local-queue -o yaml

LocalQueue 的状态将类似于以下内容：

status:
 admittedWorkloads: 0
 conditions:
 - lastTransitionTime: "2024-05-03T18:57:32Z"
 message: Can't submit new workloads to clusterQueue
 reason: ClusterQueueIsInactive
 status: "False"
 type: Active

在上面的示例中，Active 条件的状态为 False，因为 ClusterQueue 不活跃。

Kueue 中的 Provisioning Request 故障排除

Mon, 20 May 2024 00:00:00 +0000

本文档帮助你排除 ProvisioningRequest 的故障，这是由 ClusterAutoscaler 定义的 API。

Kueue 通过 Provisioning Admission Check Controller 创建 ProvisioningRequest，并将其视为准入检查。为了让 Kueue 准入 Workload，为其创建的 ProvisioningRequest 需要成功。

开始之前

在开始故障排除之前，请确保你的集群满足以下要求：

你的集群已启用 ClusterAutoscaler，且 ClusterAutoscaler 支持 ProvisioningRequest API。检查你的云提供商文档以确定支持 ProvisioningRequest 的最低版本。如果你使用 GKE，你的集群应该运行版本 1.28.3-gke.1098000 或更新版本。
你使用支持 ProvisioningRequest 的节点类型。这可能因云提供商而异。
Kueue 的版本是 v0.5.3 或更新版本。
你已在特性门控配置中启用了 ProvisioningACC。对于 Kueue v0.7.0 或更新版本，此特性门控默认启用。

识别你的作业对应的 Provisioning Request

请参阅 Job 故障排除指南，了解如何识别你的作业对应的 Workload。

Pod 故障排除

Thu, 21 Mar 2024 00:00:00 +0000

本文档介绍如何排除由 Kueue 直接管理的普通 Pod 的故障，换句话说，就是不由 Kubernetes Job 或支持的 CRD 管理的 Pod。

注意

本文档重点介绍 Kueue 管理 Pod 时与其他作业集成不同的行为。你可以阅读 Job 故障排除了解更多通用的故障排除步骤。

我的 Pod 是否由 Kueue 直接管理？

Kueue 向其管理的 Pod 添加标签 kueue.x-k8s.io/managed，值为 true。如果 Pod 上没有此标签，意味着 Kueue 不会直接准入或统计此 Pod 的资源使用情况。

Pod 可能没有 kueue.x-k8s.io/managed 标签的原因如下：

删除 ClusterQueue 故障排除

Wed, 28 Aug 2024 00:00:00 +0000

当 ClusterQueue 有活跃的 Workload 时，删除它可能需要额外的步骤。

本指南提供了安全删除 ClusterQueue 的清晰方法，解释了删除过程并提供了处理特定场景的替代方法。

在本示例中，假设你的 ClusterQueue 名为 my-cq。

理解 `kubectl delete clusterqueue`

当你运行以下命令时：

kubectl delete clusterqueue my-cq

你正在启动删除 ClusterQueue 对象的操作。但是，如果仍有 Workload 在使用该 ClusterQueue，命令可能会挂起或需要一些时间才能完成。

为什么会发生这种情况？

Kueue 为每个 Job 创建一个 Workload 对象来跟踪其准入状态。如果 Workload 被准入，它会与特定的 ClusterQueue 关联。 Kueue 使用名为 kueue.x-k8s.io/resource-in-use 的 finalizer 来防止在资源仍在使用时删除 ClusterQueue。因此，具有此 finalizer 的 ClusterQueue 在释放所有资源之前无法被删除。

使用 Agent Skills 进行故障排除

Wed, 29 Apr 2026 00:00:00 +0000

Kueue 包含实验性的 agent skills，可帮助 AI agent 按照可重复的 runbook 排查常见的 Workload 问题。这些 skills 位于 cmd/experimental/skills，面向能够读取 AGENTS.md 等仓库说明的 agent。

实验性能力

Agent skills 和 AGENTS.md 支持仍是实验性的。它们不是 Kueue API、CLI 命令或发布二进制，也不提供向后或向前兼容性保证。 Agent 的行为具有非确定性，因此必须由人工监督排查过程，并在采取操作前验证结果。

开始之前

使用这些 skills 前，请确认：

已在你的 agent 配置文件中添加 @AGENTS.md 引用。
Agent 能够理解 AGENTS.md 以及 cmd/experimental/skills 下的文件。
你有一份包含这些 skills 的 Kueue 仓库本地副本。
kubectl 已配置到要排查的集群。
你的 Kubernetes RBAC 权限允许读取排查所需的 Workload、父级 Job、Pod、事件和命名空间。

RBAC 会影响结果。例如，agent 可能能够追踪某个命名空间内的资源，但无法解析位于其他命名空间的 preemptor Workload。

故障排除 on Kueue

Job 故障排除

识别你的 Job 对应的 Workload

队列故障排除

为什么 LocalQueue 中没有 workload 被准入？

Kueue 中的 Provisioning Request 故障排除

开始之前

识别你的作业对应的 Provisioning Request

Pod 故障排除

注意

我的 Pod 是否由 Kueue 直接管理？

删除 ClusterQueue 故障排除

理解 kubectl delete clusterqueue

为什么会发生这种情况？

使用 Agent Skills 进行故障排除

实验性能力

开始之前

理解 `kubectl delete clusterqueue`