使用 Kubernetes 的 Sprint 云数据流:BackoffLimit

Sprint Cloud Dataflow with Kubernetes: BackoffLimit

Kubernetes Pod 回退失败策略

来自k8s documentation

There are situations where you want to fail a Job after some amount of retries due to a logical error in configuration etc. To do so, set .spec.backoffLimit to specify the number of retries before considering a Job as failed. The back-off limit is set by default to 6.

Spring云数据流:

当作业失败时,我们实际上不想重试。换句话说,我们想在我们的 Sprint Cloud Dataflow 配置文件中设置 backoffLimit: 1

我们试过这样设置:

deployer.kubernetes.spec.backoffLimit: 1

甚至

deployer.kubernetes.backoffLimit: 1

但是两者都没有传输到我们的 Kubernetes 集群。

6 次尝试后,我们看到以下消息:

status: conditions: - lastProbeTime: '2019-10-22T17:45:46Z' lastTransitionTime: '2019-10-22T17:45:46Z' message: Job has reached the specified backoff limit reason: BackoffLimitExceeded status: 'True' type: Failed failed: 6 startTime: '2019-10-22T17:33:01Z'

实际上我们想快速失败(最多尝试 1 或 2 次)

问题:我们如何正确设置这个属性,以便所有由 SCDF 触发的任务在 Kubernetes 上最多失败一次?

更新 (23.10.2019)

我们也试过 属性:

deployer:
   kubernetes:
      maxCrashLoopBackOffRestarts: Never # No retry for failed tasks

但是作业仍然失败了 6 次而不是 1 次。

更新 (26.10.2019)

为了完整起见:

  1. 我正在 SCDF 中安排任务
  2. 任务在 Kubernetes(更具体地说是 Openshift)上触发
  3. 当我检查 K8s 平台上的配置时,我发现它的 backoffLimit 仍然是 6,而不是 1:

取自 运行 pod 的 Yalm 配置片段:

  spec:
    backoffLimit: 6
    completions: 1
    parallelism: 1

官方documentation中说:

`maxCrashLoopBackOffRestarts` - Maximum allowed restarts for app that is in a CrashLoopBackOff. Values are `Always`, `IfNotPresent`, `Never`

但是maxCrashLoopBackOffRestarts需要一个整数。所以我猜文档不准确。

然后 pod 重新启动 6 次。

我尝试设置这些属性但未成功:

spring.cloud.dataflow.task.platform.kubernetes.accounts.defaults.maxCrashLoopBackOffRestarts: 0
spring.cloud.deployer.kubernetes.maxCrashLoopBackOffRestarts: 0
spring.cloud.scheduler.kubernetes.maxCrashLoopBackOffRestarts: 0

None 其中有效。

有什么想法吗?

要覆盖默认重启限制,您必须使用 SCDF 的 maxCrashLoopBackOffRestarts 部署程序 属性。 ref. guide.

中记录了所有支持的属性

您可以配置为在 SCDF 中覆盖此 属性 "globally" 或在每个 stream/task 部署级别单独覆盖它。更多信息 here.

多亏了 ilayaperumalg,它为什么不起作用更清楚了:

It looks like the property maxCrashLoopBackOffRestarts is applicable for determining the status of the runtime application instance while the property you refer to as backoffLimit is applicable to the JobSpec which is currently not being supported. We can add this as a feature to support your case.

Github Link