【问题标题】:Kubernetes jobs and back-off limit values: is the value a number of retries or minutes?Kubernetes 作业和回退限制值:该值是重试次数还是分钟数?
【发布时间】:2019-12-16 10:14:06
【问题描述】:

我是reading the Kubernetes documentation about jobs and retries。我发现了这个:

在某些情况下,您希望在经过一定数量的工作后使作业失败 由于配置中的逻辑错误等重试。为此,请设置 .spec.backoffLimit 指定考虑前的重试次数 一个作业失败。回退限制默认设置为 6。失败 与 Job 关联的 Pod 由 Job 控制器重新创建 指数回退延迟(10 秒、20 秒、40 秒……)上限为 6 分钟。 如果在之前没有出现新的失败 Pod,则将重置回退计数 作业的下一个状态检查。

我对上述引用有两个问题:

  1. 回退限制值是分钟还是重试次数?使用值 6 (six) 的文档示例令人困惑,因为他最初确认该值是重试次数,但之后说“上限为 6 分钟”。
  2. 有没有办法定义回退延迟时间?据我了解,这种行为(10 秒、20 秒、40 秒……)是默认行为,无法更改。

【问题讨论】:

    标签: kubernetes jobs kubernetes-cronjob


    【解决方案1】:

    不要混淆.spec.backoffLimit 是重试次数。

    Job 控制器以指数延迟(10 秒、20 秒、40 秒、...、360 秒)重新创建失败的 Pod(与作业相关联)。当然,这个延迟时间是由 Job 控制器设置的。

    • 如果 Pod 失败,10 秒后会创建新的 Pod
    • 如果再次失败,20s 后会创建一个新的
    • 如果再次失败,40s 后会出现新的
    • 如果再次失败,则下一个在 80s (1m 20s) 之后出现
    • 如果再次失败,下一个会在 160s (2m 40s) 之后出现
    • 如果再次失败,320s(5m 20s)后,新的 Pod 来了
    • 如果再次失败,在360s(不是640s,因为它大于360s或6m)之后你会看到下一个

    【讨论】:

      猜你喜欢
      • 2016-05-10
      • 2012-04-05
      • 2014-07-14
      • 2022-11-20
      • 2011-01-03
      • 2011-09-06
      • 1970-01-01
      • 1970-01-01
      • 2017-06-11
      相关资源
      最近更新 更多