From 1c7cb802a180978ddc7002de98adb84841fe3dc5 Mon Sep 17 00:00:00 2001 From: Furkan Date: Thu, 23 Feb 2023 14:10:04 +0300 Subject: [PATCH 1/2] Add detail about execution sequence for container termination Signed-off-by: Furkan --- content/en/docs/concepts/workloads/pods/pod-lifecycle.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index ca4f2aa5d1..c5ed56408c 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -432,7 +432,8 @@ place, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts gr shutdown. Typically, the container runtime sends a TERM signal to the main process in each -container. Many container runtimes respect the `STOPSIGNAL` value defined in the container +container. The signal is sent to all containers simultaneously without applying any execution sequence. +Many container runtimes respect the `STOPSIGNAL` value defined in the container image and send this instead of TERM. Once the grace period has expired, the KILL signal is sent to any remaining processes, and the Pod is then deleted from the {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. From 53b345db18fab9e84ec7db147f76e8fcff9a1962 Mon Sep 17 00:00:00 2001 From: Furkan Date: Thu, 6 Apr 2023 11:49:08 +0300 Subject: [PATCH 2/2] Fix reviews Signed-off-by: Furkan --- .../docs/concepts/workloads/pods/pod-lifecycle.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index c5ed56408c..c0e5d39e97 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -431,14 +431,12 @@ before the Pod is allowed to be forcefully killed. With that forceful shutdown t place, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts graceful shutdown. -Typically, the container runtime sends a TERM signal to the main process in each -container. The signal is sent to all containers simultaneously without applying any execution sequence. -Many container runtimes respect the `STOPSIGNAL` value defined in the container -image and send this instead of TERM. -Once the grace period has expired, the KILL signal is sent to any remaining processes, and the Pod -is then deleted from the {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. -If the kubelet or the container runtime's management service is restarted while waiting for -processes to terminate, the cluster retries from the start including the full original grace period. +Typically, with this graceful termination of the pod, kubelet makes requests to the container runtime to attempt to stop the containers in the pod by first sending a TERM (aka. SIGTERM) signal, with a grace period timeout, to the main process in each container. The requests to stop the containers are processed by the container runtime asynchronously. There is no guarantee to the order of processing for these requests. Many container runtimes respect the `STOPSIGNAL` value defined in the container image and, if different, send the container image configured STOPSIGNAL instead of TERM. +Once the grace period has expired, the KILL signal is sent to any remaining +processes, and the Pod is then deleted from the +{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. If the kubelet or the +container runtime's management service is restarted while waiting for processes to terminate, the +cluster retries from the start including the full original grace period. An example flow: