kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #39637 from Dentrax/container-kill-order 

Add detail about execution sequence for container kill order during Pod Termination
pull/42566/head
Kubernetes Prow Robot 2023-08-15 21:06:28 -07:00 committed by GitHub
parent 8f221066aa 53b345db18
commit acc735f769
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
content/en/docs/concepts/workloads/pods/pod-lifecycle.md
View File

@ -435,13 +435,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. 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: