<p>Perhaps there's something fundamental that a pod delete-and-recreate does that a pod restart doesn't do (restart as per a Crashloop).  My first thought is mounting file, etc.  I've seen where some issues are resolved after a Delete, even though a Crashloop was in effect.</p>
<p>What does a kubectl delete do that a Crashloop Backoff Restart doesn't do?  Not sure if this is particular to a Daemonset, but it was a Daemonset that I last saw this behavior.</p>

<ul>
<li><code>CrashLoopBackOff</code>
<ul>
<li>Restarts the same pod and containers in the pod</li>
<li>If the pods keep crashing or failing health checks the time that it takes to restart the pod keeps increasing with every restart.</li>
</ul>
</li>
<li><code>kubectl delete</code>
<ul>
<li>Deletes the pod</li>
<li>If the pods are managed by a higher abstraction: DaemonSet, Deployment, StatefulSet, etc. a new pod gets created. Note that in a StatefulSet the ordinal numbers remain constant so the pod will have the same name, but with other abstractions, your pod name will change.</li>
</ul>
</li>
</ul>
<blockquote>
<p>My first thought is mounting a file, etc. I've seen where some issues are resolved after a Delete, even though a Crashloop was in effect.</p>
</blockquote>
<p>Yes, when you delete, technically volumes are unmounted and then re-mounted on the new Pod. When a <code>CrashLoopBackOff</code> the containers are restarted.</p>
<p><a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle" rel="nofollow noreferrer">From the docs</a>:</p>
<blockquote>
<p>Whilst a Pod is running, the kubelet is able to restart containers to handle some kind of faults. Within a Pod, Kubernetes tracks different container states and handles</p>
</blockquote>
<p>✌️</p>
