【问题标题】:Understanding backoffLimit in Kubernetes Job了解 Kubernetes Job 中的 backoffLimit
【发布时间】:2019-02-22 11:02:30
【问题描述】:

我在 kubernetes 中使用 schedule(8 * * * *) 创建了一个 Cronjob,作业的 backoffLimit 默认为 6,pod 的 RestartPolicyNever,pod 被故意配置为 FAIL。据我了解,(对于带有restartPolicy : Never 的 podSpec)作业控制器将尝试创建 backoffLimit 数量的 pod,然后将作业标记为 Failed,因此,我预计在 Error 状态下会有 6 个 pod .

这是作业的实际状态:

status:
  conditions:
  - lastProbeTime: 2019-02-20T05:11:58Z
    lastTransitionTime: 2019-02-20T05:11:58Z
    message: Job has reached the specified backoff limit
    reason: BackoffLimitExceeded
    status: "True"
    type: Failed
  failed: 5

为什么只有 5 个失败的 pod 而不是 6 个?还是我对backoffLimit 的理解不正确?

【问题讨论】:

    标签: kubernetes


    【解决方案1】:

    简而言之:您可能看不到所有创建的 pod,因为 cronjob 中的计划周期太短。

    documentation中所述:

    与 Job 关联的失败 Pod 由 Job 重新创建 具有指数回退延迟(10 秒、20 秒、40 秒……)上限的控制器 在六分钟。如果没有新的失败 Pod,则重置回退计数 出现在作业的下一次状态检查之前。

    如果在作业控制器有机会重新创建 pod 之前安排了新作业(考虑到上次失败后的延迟),作业控制器会重新从一个开始计数。

    我使用以下.yaml 在 GKE 中复制了您的问题:

    apiVersion: batch/v1beta1
    kind: CronJob
    metadata:
      name: hellocron
    spec:
      schedule: "*/3 * * * *" #Runs every 3 minutes
      jobTemplate:
        spec:
          template:
            spec:
              containers:
              - name: hellocron
                image: busybox
                args:
                - /bin/cat
                - /etc/os
              restartPolicy: Never
          backoffLimit: 6
      suspend: false
    

    此作业将失败,因为文件 /etc/os 不存在。

    以下是其中一项工作的kubectl describe 输出:

    Name:           hellocron-1551194280
    Namespace:      default
    Selector:       controller-uid=b81cdfb8-39d9-11e9-9eb7-42010a9c00d0
    Labels:         controller-uid=b81cdfb8-39d9-11e9-9eb7-42010a9c00d0
                    job-name=hellocron-1551194280
    Annotations:    <none>
    Controlled By:  CronJob/hellocron
    Parallelism:    1
    Completions:    1
    Start Time:     Tue, 26 Feb 2019 16:18:07 +0100
    Pods Statuses:  0 Running / 0 Succeeded / 6 Failed
    Pod Template:
      Labels:  controller-uid=b81cdfb8-39d9-11e9-9eb7-42010a9c00d0
               job-name=hellocron-1551194280
      Containers:
       hellocron:
        Image:      busybox
        Port:       <none>
        Host Port:  <none>
        Args:
          /bin/cat
          /etc/os
        Environment:  <none>
        Mounts:       <none>
      Volumes:        <none>
    Events:
      Type     Reason                Age   From            Message
      ----     ------                ----  ----            -------
      Normal   SuccessfulCreate      26m   job-controller  Created pod: hellocron-1551194280-4lf6h
      Normal   SuccessfulCreate      26m   job-controller  Created pod: hellocron-1551194280-85khk
      Normal   SuccessfulCreate      26m   job-controller  Created pod: hellocron-1551194280-wrktb
      Normal   SuccessfulCreate      26m   job-controller  Created pod: hellocron-1551194280-6942s
      Normal   SuccessfulCreate      25m   job-controller  Created pod: hellocron-1551194280-662zv
      Normal   SuccessfulCreate      22m   job-controller  Created pod: hellocron-1551194280-6c6rh
      Warning  BackoffLimitExceeded  17m   job-controller  Job has reached the specified backoff limit
    

    注意创建 pod hellocron-1551194280-662zvhellocron-1551194280-6c6rh 之间的延迟。

    【讨论】:

    • 已编辑问题以包括时间表,只是对 backoffLimit 的说明,因此 backoffLimit 指定了作业控制器将执行的持续时间而不是 pod/restarts 的数量。我创建了一个小gist,我的理解正确吗?
    • backoffLimit 指定作业控制器放弃之前的重试次数。
    • @MZW 我在 GKE 中重现了您的问题 我看到您的 yaml 创建了 6 个 pod,在我的情况下只创建了 5 个 pod,我错过了什么吗?
    【解决方案2】:

    使用spec.backoffLimit 指定在将作业视为失败之前的重试次数。默认情况下,回退限制设置为 6。

    【讨论】:

    • 这 6 次重试之间的间隔是多少?
    • 是否有任何值将限制设置为无限制?
    • 您必须提供一些限制
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-12-01
    • 2022-12-10
    • 2020-07-13
    • 1970-01-01
    • 1970-01-01
    • 2018-08-11
    • 1970-01-01
    相关资源
    最近更新 更多