<p>I  have cronjob where the pod it starts ends up in <code>ImagePullBackOff</code> and the cronjob never scheduled another pod , though it has to per schedule. Is there a way to force the cron controller to schedule another pod even though the previous one ended in ImagePullBackOff.</p>
<p>I don't want multiple pods running at the same time so use <code>concurrencyPolicy: Forbid</code> , Is there anyway to get CronJob to still schedule another pod ?</p>

<p>You don't really want the scheduler to schedule another pod. Doing that would lead to a resource leak as mentioned explained in <a href="https://github.com/kubernetes/kubernetes/issues/76570" rel="nofollow noreferrer">Infinite ImagePullBackOff CronJob results in resource leak</a>, which @VonC mentioned in his answer.</p>
<p>Instead you should focus on fixing the root cause to why the pod is in <code>ImagePullBackOff</code>. Once that is done Kubernetes will automatically pull the image, run the pod and a new one will be scheduled once the cron schedule is fullfilled.</p>
<p><code>ImagePullBackoff</code> means that the container could not start because the image could not be retrieved. The reason could be for example an invalid image id or tag, a missing or invalid <code>imagePullSecret</code> or network connectivity issues.</p>
<p>When a pod is in <code>ImagePullBackoff</code> kubernetes will periodically retry to pull the image, and once the image is successfully pulled the pod starts.</p>
<p>The delay between pull attempts will increase with each attempt (a <em>BackOff</em>), as explained in the <a href="https://Kubernetes%20raises%20the%20delay%20between%20each%20attempt%20until%20it%20reaches%20a%20compiled-in%20limit,%20which%20is%20300%20seconds%20(5%20minutes)." rel="nofollow noreferrer">docs</a></p>
<blockquote>
<p>Kubernetes raises the delay between each attempt until it reaches a compiled-in limit, which is 300 seconds (5 minutes).</p>
</blockquote>
