Update job workload doc with backoff failure policy (#5319)

Add to the Jobs documentation how to use the new backoffLimit field that limit the number of Pod failure before considering the Job as failed.
2017-09-07 18:29:08 +02:00
parent 4807ff07cd
commit 9412bef9fe
2 changed files with 8 additions and 0 deletions
@@ -12,4 +12,5 @@ spec:
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
+      backoffLimit: 4

@@ -198,6 +198,12 @@ sometimes be started twice.
 If you do specify `.spec.parallelism` and `.spec.completions` both greater than 1, then there may be
 multiple pods running at once.  Therefore, your pods must also be tolerant of concurrency.

+### Pod Backoff failure policy
+
+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.template.spec.backoffLimit` to specify the number of retries before considering a Job as failed.
+The back-off limit is set by default to 6. Failed Pods associated with the Job are recreated by the Job controller with an exponential back-off delay (10s, 20s, 40s ...) capped at six minutes, The back-off limit is reset if no new failed Pods appear before the Job's next status check.
+
 ## Job Termination and Cleanup

 When a Job completes, no more Pods are created, but the Pods are not deleted either.  Since they are terminated,
@@ -232,6 +238,7 @@ spec:
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
+      backoffLimit: 5
 ```

 Note that both the Job Spec and the Pod Template Spec within the Job have a field with the same name.