Job 故障排除

Job 状态的故障排除

本文档介绍如何排除挂起的 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

我的 Job 使用什么 ResourceFlavors？

一旦你识别了你的 Job 对应的 Workload，运行以下命令来获取你的 Workload 的所有详细信息：

kubectl describe workload -n my-namespace job-my-job-19797

输出应该类似于以下内容：

apiVersion: kueue.x-k8s.io/v1beta2
kind: Workload
...
status:
  admission:
    clusterQueue: cluster-queue
    podSetAssignments:
    - count: 3
      flavors:
        cpu: default-flavor
        memory: default-flavor
      name: main
      resourceUsage:
        cpu: "3"
        memory: 600Mi
  ...

现在你可以清楚地看到你的 Job 使用什么 ResourceFlavors。

我的 Job 是否被暂停？

要知道你的 Job 是否被暂停，查看 .spec.suspend 字段的值，运行以下命令：

kubectl get job -n my-namespace my-job -o jsonpath='{.spec.suspend}'

当作业被暂停时，Kubernetes 不会为该 Job 创建任何 Pods。如果 Job 已经有 Pod 在运行，Kubernetes 会终止并删除这些 Pod。

Job 在 Kueue 尚未准入它或当它被抢占以容纳另一个作业时会被暂停。要了解为什么你的 Job 被暂停，请检查相应的 Workload 对象。

我的 Job 是否被准入？

如果你的 Job 没有运行，请检查 Kueue 是否已准入该 Workload。

了解 Job 是否被准入、正在等待或尚未尝试准入的起点是查看 Workload 状态。

运行以下命令获取 Workload 的完整状态：

kubectl get workload -n my-namespace my-workload -o yaml

已准入的 Workload

如果你的 Job 被准入，Workload 应该有类似以下的状态：

apiVersion: kueue.x-k8s.io/v1beta2
kind: Workload
...
status:
  ...
  conditions:
  - lastTransitionTime: "2024-03-19T20:49:17Z"
    message: Quota reserved in ClusterQueue cluster-queue
    reason: QuotaReserved
    status: "True"
    type: QuotaReserved
  - lastTransitionTime: "2024-03-19T20:49:17Z"
    message: The workload is admitted
    reason: Admitted
    status: "True"
    type: Admitted

等待中的 Workload

如果 Kueue 尝试准入 Workload，但由于缺乏配额而失败， Workload 应该有类似以下的状态：

status:
  conditions:
  - lastTransitionTime: "2024-03-21T13:43:00Z"
    message: 'couldn''t assign flavors to pod set main: insufficient quota for cpu
      in flavor default-flavor in ClusterQueue'
    reason: Pending
    status: "False"
    type: QuotaReserved
  resourceRequests:
    name: main
    resources:
      cpu:    3
      Memory: 600Mi

我的 ClusterQueue 是否具有作业所需的资源请求？

当你提交具有资源请求的作业时，例如：

kubectl get jobs job-0-9-size-6 -o json | jq -r .spec.template.spec.containers[0].resources

输出：

{
  "limits": {
    "cpu": "2"
  },
  "requests": {
    "cpu": "2"
  }
}

如果你的 ClusterQueue 没有对 requests 的定义，Kueue 无法准入该作业。对于上述作业，你应该在 resourceGroups 下定义 cpu 配额。定义 cpu 配额的 ClusterQueue 如下所示：

apiVersion: kueue.x-k8s.io/v1beta2
kind: ClusterQueue
metadata:
  name: "cluster-queue"
spec:
  namespaceSelector: {}
  resourceGroups:
  - coveredResources: ["cpu"]
    flavors:
    - name: "default-flavor"
      resources:
      - name: "cpu"
        nominalQuota: 40

有关更多信息，请参阅资源组。

等待准入检查

当 ClusterQueue 配置了准入检查时，例如 ProvisioningRequest 或 MultiKueue， Workload 可能会保持类似以下的状态，直到准入检查通过：

status:
  admission:
    clusterQueue: dws-cluster-queue
    podSetAssignments:
      ...
  admissionChecks:
  - lastTransitionTime: "2024-05-03T20:01:59Z"
    message: ""
    name: dws-prov
    state: Pending
  conditions:
  - lastTransitionTime: "2024-05-03T20:01:59Z"
    message: Quota reserved in ClusterQueue dws-cluster-queue
    reason: QuotaReserved
    status: "True"
    type: QuotaReserved

未尝试的 Workload

当使用具有 StrictFIFO queueingStrategy 的 ClusterQueue 时，Kueue 只尝试准入每个 ClusterQueue 的头部。因此，如果 Kueue 没有尝试准入 Workload，Workload 状态可能不包含任何条件。

配置错误的 LocalQueue 或 ClusterQueue

如果你的 Job 引用了不存在的 LocalQueue，或者它引用的 LocalQueue 或 ClusterQueue 配置错误，Workload 状态将如下所示：

status:
  conditions:
  - lastTransitionTime: "2024-03-21T13:55:21Z"
    message: LocalQueue user-queue doesn't exist
    reason: Inadmissible
    status: "False"
    type: QuotaReserved

请参阅队列故障排除了解为什么 ClusterQueue 或 LocalQueue 不活跃。

我的 Job 是否被抢占？

如果你的 Job 没有运行，并且你的 ClusterQueue 启用了抢占，你应该检查 Kueue 是否抢占了 Workload。

status:
  conditions:
  - lastTransitionTime: "2024-03-21T15:49:56Z"
    message: 'couldn''t assign flavors to pod set main: insufficient unused quota
      for cpu in flavor default-flavor, 9 more needed'
    reason: Pending
    status: "False"
    type: QuotaReserved
  - lastTransitionTime: "2024-03-21T15:49:55Z"
    message: Preempted to accommodate a higher priority Workload
    reason: Preempted
    status: "True"
    type: Evicted
  - lastTransitionTime: "2024-03-21T15:49:56Z"
    message: The workload has no reservation
    reason: NoReservation
    status: "False"
    type: Admitted

Evicted 条件显示 Workload 被抢占，状态为 status: "True" 的 QuotaReserved 条件显示 Kueue 已经尝试再次准入它，在这种情况下不成功。

我的 Job 的 Pod 是否在运行？

当 Job 没有被暂停时，Kubernetes 为此 Job 创建 Pod。要检查有多少这些 Pod 被调度和运行，请检查 Job 状态。

运行以下命令获取 Job 的完整状态：

kubectl get job -n my-namespace my-job -o yaml

输出将类似于以下内容：

...
status:
  active: 5
  ready: 4
  succeeded: 1
  ...

active 字段显示 Job 存在多少 Pod，ready 字段显示其中有多少正在运行。

要列出 Job 的所有 Pod，运行以下命令：

kubectl get pods -n my-namespace -l batch.kubernetes.io/job-name=my-job

输出将类似于以下内容：

NAME             READY   STATUS    RESTARTS   AGE
my-job-0-nxmpx   1/1     Running   0          3m20s
my-job-1-vgms2   1/1     Running   0          3m20s
my-job-2-74gw7   1/1     Running   0          3m20s
my-job-3-d4559   1/1     Running   0          3m20s
my-job-4-pg75n   0/1     Pending   0          3m20s

如果一个或多个 Pod 卡在 Pending 状态，通过运行以下命令检查为 Pod 发出的最新事件：

kubectl describe pod -n my-namespace my-job-0-pg75n

如果 Pod 无法调度，输出将类似于以下内容：

Events:
  Type     Reason             Age                From                Message
  ----     ------             ----               ----                -------
  Warning  FailedScheduling   13s (x2 over 15s)  default-scheduler   0/9 nodes are available: 9 node(s) didn't match Pod's node affinity/selector. preemption: 0/9 nodes are available: 9 Preemption is not helpful for scheduling.
  Normal   NotTriggerScaleUp  13s                cluster-autoscaler  pod didn't trigger scale-up:

反馈

这个页面有帮助吗？

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.

最后修改 October 27, 2025: update documentation to use v1beta2 (#7409) (ff23fd123)