<p>We have container per pod. Each container runs a service that listens on SIGTERM signal to initiate it's shutdown process.</p>
<p>To initiate the shutdown process,</p>
<ol>
<li><p>does <code>kubectl delete pod [podname]</code> command needs to be initiated?</p>
</li>
<li><p>does container receive the SIGTERM signal from the linux kernel of the kubernetes node?</p>
</li>
<li><p>if yes, how does kubelet inform the kernel of kubernetes node, to throw SIGTERM signal on a specific container?</p>
</li>
</ol>
<p>Note: of course pod is just a network namespace isolated container</p>

overexchange
<p>When initiating a pod deletion request</p>
<pre><code>kubectl delete pods &lt;POD&gt;
</code></pre>
<p>the container runtime would send a <code>TERM</code> signal <strong>to the main process in each container</strong>.</p>
<p>When the <code>--force --grace-period=0</code> switch options are used, the container runtime will send a <code>TERM</code> followed directly by the <code>KILL</code> signal.</p>
<p><code>kubectl</code> won't initiate a termination request in a container based fashion but would rather terminate all containers running inside a terminated pod.</p>
<p>Note that a pod won't transition to a <code>TERMINATING</code> state only upon an explicit request to delete the latter, but this should be a core part of how <em>Kubernetes</em> would manage your cluster meaning that it might terminate a <strong>perfectly healthy</strong> container for one of below reasons:</p>
<ul>
<li>If the deployment is updated with a rolling update</li>
<li>If a node is drained</li>
<li>If a node runs out of resources</li>
</ul>
<p>You can check <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination" rel="nofollow noreferrer">the <em>Pods Lifecycle</em> documentation</a> for further details.</p>
