<p>Assuming I have a Kubernetes Deployment object with the <code>Recreate</code> strategy and I update the Deployment with a new container image version. Kubernetes will:</p>
<ol>
<li>scale down/kill the existing Pods of the Deployment,</li>
<li>create the new Pods,</li>
<li>which will pull the new container images</li>
<li>so the new containers can finally run.</li>
</ol>
<p>Of course, the <code>Recreate</code> strategy is exepected to cause a downtime between steps 1 and 4, where no Pod is actually running. However, step 3 can take a lot of time if the container images in question are or the container registry connection is slow, or both. In a test setup (Azure Kubernetes Services pulling a Windows container image from Docker Hub), I see it taking 5 minutes and more, which makes for a really long downtime.</p>
<p>So, what is a good option to reduce that downtime? Can I somehow get Kubernetes to pull the new images before killing the Pods in step 1 above? (Note that the solution should work with Windows containers, which are notoriously large, in case that is relevant.)</p>
<p>On the Internet, I have found <a href="https://codefresh.io/kubernetes-tutorial/single-use-daemonset-pattern-pre-pulling-images-kubernetes/" rel="nofollow noreferrer">this Codefresh article using a DaemonSet and Docker in Docker</a>, but I guess <a href="https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/#so-why-the-confusion-and-what-is-everyone-freaking-out-about" rel="nofollow noreferrer">Docker in Docker is no longer compatible with containerd</a>.</p>
<p>I've also found <a href="https://stackoverflow.com/a/59588935/62838">this StackOverflow answer</a> that suggests using an Azure Container Registry with Project Teleport, but that is in private preview and doesn't support Windows containers yet. Also, it's specific to Azure Kubernetes Services, and I'm looking for a more general solution.</p>
<p>Surely, this is a common problem that has a &quot;standard&quot; answer?</p>
<p><strong>Update 2021-12-21:</strong> Because I've got a corresponding answer, I'll clarify that I cannot easily change the deployment strategy. The application in question does not support running Pods of different versions at the same time because it uses a database that needs to be migrated to the corresponding application version, without forwards or backwards compatibility.</p>

<p>Implement a &quot;blue-green&quot; deployment strategy.  For instance, the service might be running and active in the &quot;blue&quot; state.  A new deployment is created with a new container image, which deploys the &quot;green&quot; pods with the new container image. When all of the &quot;green&quot; pods are ready, the &quot;switch live&quot; step is run, which switches the active color.  Very little downtime.</p>
<p>Obviously, this has tradeoffs. Your cluster will need more memory to run the additional transitional pods.  The deployment process will be more complex.</p>
