<p>I'm wondering whether using <code>imagePullPolicy: ifNotPresent</code> would provide any resiliency to the temporary loss of our private registry.. </p>

<h2>Background</h2>

<p>I have a multi-master, multi-worker bare-metal cluster, and all my pods are using images pulled from a local private registry, running outside the cluster on a single node. The cluster is therefore a lot more fault-tolerant than the registry itself.</p>

<p>What would happen if I set my workloads to <code>imagePullPolicy: Always</code>, and the registry failed? I wouldn't be able to (for example) scale up/down my pods, since I wouldn't be able to pull the image from the registry.</p>

<p>If I used <code>imagePullPolicy: IfNotPresent</code>, then provided the image existed on the nodes already, I could happily scale up/down, even in the absence of the registry.</p>

<h2>The question</h2>

<p>The question is, if a pod couldn't start because the image couldn't be pulled, would Kubernetes ever try to reschedule that pod on a different node (which may have the image cached), or once it's scheduled (and failing) to one node, will it remain there until deleted/drained?</p>

<p>Cheers!
D</p>

Funky Penguin
<p>That is correct! If you have the registry down, and <code>imagePullPolicy: Always</code>, any new pod would fail to create timing out.</p>

<p>And no, it wouldn't reschedule the pod. It would stay there in state <code>ImagePullBackOff</code> until the registry comes up.</p>

<p>You could trick it to re-schedule the pod (not based on the registry availability though), but most probably the scheduler will decide to schedule it on the same node, unless resource wise something has changed.</p>
