故障排除 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 在释放所有资源之前无法被删除。

故障排除 on Kueue

Job 故障排除

识别你的 Job 对应的 Workload

队列故障排除

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

Kueue 中的 Provisioning Request 故障排除

开始之前

识别你的作业对应的 Provisioning Request

Pod 故障排除

注意

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

删除 ClusterQueue 故障排除

理解 kubectl delete clusterqueue

为什么会发生这种情况？

理解 `kubectl delete clusterqueue`