<p>In Kubernetes, when a Pod repeatedly crashes and is in <code>CrashLoopBackOff</code> status, it is not possible to shell into the container and poke around to find the problem, due to the fact that containers (unlike VMs) live only as long as the primary process. If I shell into a container and the Pod is restarted, I'm kicked out of the shell.</p>
<p>How can I keep a Pod from crashing so that I can investigate if my primary process is failing to boot properly?</p>

<h2>Redefine the <code>command</code></h2>
<p>In <strong>development only</strong>, a temporary hack to keep a Kubernetes pod from crashing is to redefine it and <a href="https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/" rel="noreferrer">specify the container's <code>command</code></a> (corresponding to a Docker <code>ENTRYPOINT</code>) and <code>args</code> to be a command that will not crash. For instance:</p>
<pre><code>  containers:
  - name: something
    image: some-image
    # `shell -c` evaluates a string as shell input
    command: [ &quot;sh&quot;, &quot;-c&quot;]
    # loop forever, outputting &quot;yo&quot; every 5 seconds
    args: [&quot;while true; do echo 'yo' &amp;&amp; sleep 5; done;&quot;]
</code></pre>
<p>This allows the container to run and gives you a chance to shell into it, like <code>kubectl exec -it pod/some-pod -- sh</code>, and investigate what may be wrong.</p>
<p>This needs to be undone after debugging so that the container will run the command it's actually meant to run.</p>
<p>Adapted from <a href="https://beanexpert.co.in/troubleshoot-pod-crashloopbackoff-error-kubernetes/" rel="noreferrer">this blog post</a>.</p>
