<h1>Suspending &amp; resuming my virtual-machine does break the k8s deployment</h1>
<p>When I suspend with <code>minikube stop</code> and then resume the Virtual Machine with <code>minikube start</code>, Minikube re-deploys my app from scratch.</p>
<p>I see this behaviour with newer versions of Minikube higher than <em>v1.18</em> (I run on <em>v1.19</em>).</p>
<hr />
<h1>The setup:</h1>
<ul>
<li>The <em>Kubernetes</em> deployment mounts a volume with the source code from my host machine, via <code>hostPath</code>.\</li>
<li>Also I have a container of <code>initContainers</code> that setups the application.</li>
</ul>
<p>Since the new <em>&quot;redeploy behaviour on resume&quot;</em> happens, the init-container <strong>breaks my deploy, <em>if</em> I have work-in-progress code on my host machine</strong>..</p>
<h1>The issue:</h1>
<p>Now, if I have temporary/non-perfectly-running code, I cannot suspend the machine with unfinished work anymore, between working days; because every time I resume it <strong>Minikube will try to deploy again but with broken code</strong> and fail with an <code>Init:CrashLoopBackOff</code>.</p>
<h1>The workaround:</h1>
<p>For now, each time I resume the machine I need to</p>
<ol>
<li>stash/commit my WIP code</li>
<li>checkout the last commit with working deployment</li>
<li>run the deployment &amp; wait for it to complete the initialization (minutes...)</li>
<li>checkout/stash-pop the code saved at point <em>1)</em>.</li>
</ol>
<p>I can survive, but the workflow is terrible.</p>
<h1>How do I restore the old behaviour?</h1>
<ul>
<li><em>How do I make my deploys to stay untouched, as expected when suspending the VM, instead of being re-deployed every time I resume?</em></li>
</ul>

Kamafeather
<p>In short words there are two ways to achieve what you want:</p>
<ul>
<li>On current versions of <code>minikube</code> and <code>virtualbox</code> you can use <code>save state</code> option in Virtual box directly.</li>
<li>Move initContianer's code to a separate <code>job</code>.</li>
</ul>
<p><strong>More details about minikube + virtual box</strong></p>
<p>I have an environment with minikube version 1.20, virtual box 6.1.22 (from yesterday) and MacOS. Also minikube driver is set to <code>virtualbox</code>.</p>
<p>First with <code>minikube</code> + <code>VirtualBox</code>. Different scenarios:</p>
<p><code>minikube stop</code> does following:</p>
<blockquote>
<p>Stops a local Kubernetes cluster. This command stops the underlying VM
or container, but keeps user data intact.</p>
</blockquote>
<p>What happens is virtual machine where minikube is set up stops entirely. <code>minikube start</code> starts the VM and all processes in it. All containers are started as well, so if your pod has an init-container, it will run first anyway.</p>
<p><code>minikube pause</code> pauses all processes and free up CPU resourses while memory will still be allocated. <code>minikube unpause</code> brings back CPU resources and continues executing containers from a state when they were paused.</p>
<p>Based on different scenarios I tried with <code>minikube</code> it's not achievable using only minikube commands. To avoid any state loss on your <code>minikube</code> environment due to host restart or necessity to stop a VM to get more resources, you can use <code>save state</code> feature in VirtualBox in UI or cli. Below what it does:</p>
<blockquote>
<p><strong>VBoxManage controlvm  savestate</strong>: Saves the current state of the VM to disk and then stops the VM.</p>
</blockquote>
<p>Virtual box creates something like a snapshot with all memory content within this snapshot. When virtual machine is restarted, Virtual box will restore the state of VM to the state when the VM was saved.</p>
<p>One more assumption is if this works the same way in v. 1.20 - this is expected behaviour and not a bug (otherwise it would've been fixed already)</p>
<p><strong>Init-container and jobs</strong></p>
<p>You may consider moving your init-container's code to a a separate <code>job</code> so you will avoid any issues with unintended pod restarts and braking your deployment in the main container.  Also it's advised to have init-container's code idempotent.
Here's a quote from official documentation:</p>
<blockquote>
<p>Because init containers can be restarted, retried, or re-executed,
init container code should be idempotent. In particular, code that
writes to files on <code>EmptyDirs</code> should be prepared for the possibility
that an output file already exists.</p>
</blockquote>
<p>This can be achieved by using <code>jobs</code> in Kubernetes which you can run manually when you need to do so.
To ensure following the workflow you can place a check for a <code>Job completion</code> or a specific file on a data volume to the deployment's pod init container to indicate that code is working, deployment will be fine.</p>
<p>Links with more information:</p>
<ul>
<li><p><a href="https://www.virtualbox.org/manual/ch08.html#vboxmanage-controlvm" rel="nofollow noreferrer">VirtualBox <code>save state</code></a></p>
</li>
<li><p><a href="https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#detailed-behavior" rel="nofollow noreferrer">initContainers</a></p>
</li>
<li><p><a href="https://kubernetes.io/docs/concepts/workloads/controllers/job/" rel="nofollow noreferrer">kubernetes jobs</a></p>
</li>
</ul>
