<p>I have searched many websites and articles but not found any perfect answer. I am using <strong>eks version 1.18</strong>. I can see a few of the pods are &quot;Evicted&quot;, but when trying to check the node I can see the error &quot;(combined from similar events): failed to garbage collect required amount of images. Wanted to free 6283487641 bytes, but freed 0 bytes&quot;.</p>
<p>Is there any way we can find the reason why it's failing? or how to fix this issue? Any suggestions are most welcome.</p>
<p><a href="https://i.stack.imgur.com/Z9gru.jpg" rel="noreferrer"><img src="https://i.stack.imgur.com/Z9gru.jpg" alt="enter image description here" /></a></p>
<p>I can see the disk &quot;overlays&quot; filesystem is almost full within a few hours. I am not sure what's going on. The below screenshot shows my memory utilization.</p>
<p><a href="https://i.stack.imgur.com/HpKPb.jpg" rel="noreferrer"><img src="https://i.stack.imgur.com/HpKPb.jpg" alt="enter image description here" /></a></p>

JDGuide
<p>So a workaround that can stabilize situation for a while (giving your time to mount a larger volume for storing images) is to to start using local images cache, by setting in your <code>Deployment</code> (or <code>Pod</code>) manifest:</p>
<pre><code>spec.containers.imagePullPolicy: &quot;ifNotPresent&quot;
</code></pre>
<hr />
<p>One situation I've encountered where such quick storage exhaustion can happen is when you set <code>imagePullPolicy</code> to <code>Always</code> and then the image fails to pull completely (one reason being that there is not enough space). <code>k8s</code> then enters into an image pull loop (not throttled sufficiently by the backoff mechanism) and those unique incomplete image parts with different checksums combined with the &quot;always pull&quot; request can quickly consume all available storage dedicated to docker images (on the partition where <code>containerd</code> is located).</p>
