<p>I was running this to see how job restart works in k8s.</p>

<pre><code>kubectl run alpine --image=alpine --restart=OnFailure -- exit 1
</code></pre>

<p>The alpine image was already there. The first failure happened almost within a second. k8s takes 5 minutes to do 5 restarts! why does it not try immediately? Is there any way reduce the time between 2 restarts?</p>

<p><a href="https://i.stack.imgur.com/fImXZ.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/fImXZ.png" alt="enter image description here"></a></p>

<p>Take a look at the <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy" rel="nofollow noreferrer">Pod Lifecycle</a> docs:</p>

<blockquote>
  <p>Exited Containers that are restarted by the kubelet are restarted with an <strong>exponential back-off delay</strong> (10s, 20s, 40s …) capped at five minutes, and is reset after ten minutes of successful execution. </p>
</blockquote>

<p>I think that there is no way to configure the back-off delay time.<br>
<em>EDIT: There is an <a href="https://github.com/kubernetes/kubernetes/issues/57291" rel="nofollow noreferrer">open issue</a> requesting this feature.</em></p>

<p>Also, note that using <code>kubectl run</code> <strong>you are not simulating "job restarts"</strong>. Jobs are managed by <a href="https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#handling-pod-and-container-failures" rel="nofollow noreferrer">Job Controllers</a>, which behaves a little bit different when handling pod/containers errors, as it takes into account the combination of <code>restartPolicy</code>, <code>parallelism</code>, <code>completions</code> and the <code>backoffLimit</code> configs:</p>

<blockquote>
  <p>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. 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.</p>
</blockquote>
