<div id="readability-page-1" class="page"><div><div><a href="https://rkttu.com/?source=post_page-----b1b8ed96f383--------------------------------" rel="noopener"><div><p><img alt="Jung-Hyun Nam" src="https://miro.medium.com/fit/c/96/96/2*P1z-D515GRYQ6WaumcAxVQ.png" width="48" height="48"></p></div></a></div><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/2000/0*DtcZH1_ZnUcOTy0i" width="1000" height="663" role="presentation"></p></div><figcaption>Photo by <a href="https://unsplash.com/@nbabrams?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="noopener">Nick Abrams</a> on <a href="https://unsplash.com/s/photos/slow?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="noopener">Unsplash</a></figcaption></figure><p id="99ed"><span>Y</span>ou may wonder why the Windows Container starts up so slowly. Because you never pinned your exact base image version of your container image. In this article, I’ll explain what was going on under the hood and how you can handle it correctly.</p><h2 id="d703">Understanding Base Image Publish Rule</h2><p id="be6e">Microsoft regularly publishes newer Windows Server container images when they roll out the more recent Windows Server security patches and hotfixes. For example, when Microsoft releases KB4598242 for 20H2, the container base image also released.</p><p id="4929">When the new base image rolled out to the mcr.microsoft.com, the new image consisted of two parts. The first part is the base image of the Windows Server container, which will never change. And the moving part is the latter part, which includes the hotfix.</p><h2 id="27c8">What’s going on?</h2><p id="dcf0">If you build your image with a tag like “2004”, as you may guess, it will choose the latest version of the 20H1 server container image. But this is a relative option, so there will mismatch.</p><p id="4089">From the developer’s perspective, every time you build an image, a different base image is chosen. Three months ago, your choice could be <code>10.0.19041.264-amd64</code>, but at this time, your choice will <code>10.0.19042.746-amd64</code> because <code>2004</code> will regularly change. As you may know, this is a practice for existing Docker users why you should not use the abbreviation tag.</p><p id="d0d8">Then, let’s move our sight to the server. Let’s assume that you are an administrator of the Windows Kubernetes node. Most managed Kubernetes providers do not specify specific base image versions of the Windows container into the node. Whether you want it or not, you should pull the matching base image of your Windows node for faster startup time.</p><p id="6730">But there’s a catch. Even you cached a base image of the Windows Server core image, each hotfix of the Windows server image has a different layer, which consumes about 300~400MiB. If you are not specifying the exact version of the image, each Windows node will consume additional disk space, network traffic, and startup time.</p><p id="9401">Let’s take a closer look. You can pre-pull to your node for image tag <code>10.0.19041.264-amd64</code>. But the developer did not build the app container image with that image. He or she used the <code>2004</code> tag, and the image tag pointed to the <code>10.0.19042.746-amd64</code> image tag, so when the image deployed to the node, about 300~400MiB additional disk space, network traffic will consume, plus startup time simply expanding two or three minutes. (Excepting 3~4GiB of <code>10.0.19042</code>.)</p><h2 id="f6b5">Solution — Make Explicit As Possible Everywhere</h2><p id="04c1">The solution is straightforward. From beginning to end, announce the exact container base image version you want to use for all other teams.</p><p id="b3e4">As long as you are using process isolation, the container version tag likely not to affect your container runtime. So you can choose the oldest public image tag to build your application container image and pre-deploy to your node, respectively.</p><p id="0803">For example, if you manage the Windows Server version 20H1 for the Kubernetes cluster, you can fix the required container version tag as <code>10.0.18363.476-amd64</code>, the oldest image tag. (For future proof, it’s better to specify the exact architecture name.)</p><p id="a7ab">But if you are using Hyper-V isolation, you need additional costs to change and spread the tag version regularly. Even with this in mind, Hyper-V container isolation is not recommended because operation costs is simply high.</p><p id="c5cd">If you choose the correct and fixed image tag, you can ensure that your node will pull the small part of your application layer, not the entire base image. In my experience, this kind of tune makes our cold boot time from 7 minutes to 1 minute.</p><h2 id="9f15">Conclusion</h2><p id="0555">Due to the operating system’s architecture, you should consider what your choices meaning and how it affects your workload in the Windows container world. For almost all of the workload, you are likely to use process isolation so that this solution will work fine. Make your image tag choice as explicit as possible to save your money and time.</p></div></div>

Stories by Jung-Hyun Nam on Medium

Who blames your Windows container app is slow?
Continue reading on Dev Genius »

Make Faster Pull for Windows Container

댓글