摘要：被設計為這樣一種方式，父進程必須明確地等待子進程終止，以便收集它的退出狀態。會完成的刪除，將優雅退出的時間設置為表示立即刪除。

三者都是結束/終止進程運行。

前者與字符ctrl+c關聯，后者沒有任何控制字符關聯。
前者只能結束前臺進程，后者則不是。

前者可以被阻塞、處理和忽略，但是后者不可以。KILL命令的默認不帶參數發送的信號就是SIGTERM.讓程序有好的退出。因為它可以被阻塞，所以有的進程不能被結束時，用kill發送后者信號，即可。即：kill-9 進程號。

當我們用docker stop命令來停掉容器的時候，docker默認會允許容器中的應用程序有10秒的時間用以終止運行。

在docker stop命令執行的時候，會先向容器中PID為1的進程(main process)發送系統信號SIGTERM，然后等待容器中的應用程序終止執行，如果等待時間達到設定的超時時間，或者默認的10秒，會繼續發送SIGKILL的系統信號強行kill掉進程。在容器中的應用程序，可以選擇忽略和不處理SIGTERM信號，不過一旦達到超時時間，程序就會被系統強行kill掉，因為SIGKILL信號是直接發往系統內核的，應用程序沒有機會去處理它。

默認情況下，docker kill命令不會給容器中的應用程序有任何gracefully shutdown的機會。它會直接發出SIGKILL的系統信號，以強行終止容器中程序的運行。

與docker stop命令不一樣的地方在于，docker kill沒有任何的超時時間設置，它會直接發送SIGKILL信號，以及用戶通過signal參數指定的其他信號。

docker stop命令，更類似于Linux系統中的kill命令，二者都是發送系統信號SIGTERM。而docker kill命令，更像是Linux系統中的kill -9或者是kill -SIGKILL命令，用來發送SIGKILL信號，強行終止進程。

process ID為1的進程，通常是UNIX init進程, 在操作系統中有重要的作用：每當一個進程退出了，如果它還有子進程存在，則該子進程變成了孤兒進程，init進程過來接管。Unix被設計為這樣一種方式，父進程必須明確地“等待”子進程終止，以便收集它的退出狀態。

子進程在結束后，內核仍然會為其維護一個基本的結構，保存其pid, 退出原因和狀態等信息，父進程通過waitpid系統調用，可以獲得這些信息。如果父進程沒有調用waitpid，這些狀態信息會一直保留，變成所謂僵尸進程。如果子進程后于父進程結束，一般來說, init進程會負責這些孤兒進程。

根據一般一個容器只運行一個進程的原則，對于一個web服務，它在容器中運行時的pid是1，假設它調用了bash的cgi腳本，而這個腳本又調用了grep，一段時間后，cgi腳本因為某種原因超時，web服務開始嘗試殺死它，但是grep卻并未受到影響，因此變成了孤兒進程。這時，pid=1的web服務應該能接管，但是絕大多數的web服務并沒有init那樣的能力，所以grep就變成了僵尸進程。

pod代表著一個集群中節點上運行的進程，讓這些進程不再被需要，優雅的退出是很重要的（與粗暴的用一個KILL信號去結束，讓應用沒有機會進行清理操作）。用戶應該能請求刪除，并且在室進程終止的情況下能知道，而且也能保證刪除最終完成。當一個用戶請求刪除pod，系統記錄想要的優雅退出時間段，在這之前Pod不允許被強制的殺死，TERM信號會發送給容器主要的進程。一旦優雅退出的期限過了，KILL信號會送到這些進程，pod會從API服務器其中被刪除。如果在等待進程結束的時候，Kubelet或者容器管理器重啟了，結束的過程會帶著完整的優雅退出時間段進行重試。

一個示例流程：

1.用戶發送一個命令來刪除Pod，默認的優雅退出時間是30秒

2.API服務器中的Pod更新時間，超過該時間Pod被認為死亡

3.在客戶端命令的的里面，Pod顯示為"Terminating（退出中）"的狀態

4.（與第3同時）當Kubelet看到Pod標記為退出中的時候，因為第2步中時間已經設置了，它開始pod關閉的流程

4.1如果該Pod定義了一個停止前的鉤子，其會在pod內部被調用。如果鉤子在優雅退出時間段超時仍然在運行，第二步會意一個很小的優雅時間斷被調用

4.2進程被發送TERM的信號

5.（與第三步同時進行）Pod從service的列表中被刪除，不在被認為是運行著的pod的一部分。緩慢關閉的pod可以繼續對外服務，當負載均衡器將他們輪流移除。

6.當優雅退出時間超時了，任何pod中正在運行的進程會被發送SIGKILL信號被殺死。

7.Kubelet會完成pod的刪除，將優雅退出的時間設置為0（表示立即刪除）。pod從API中刪除，不在對客戶端可見。

默認情況下，所有的刪除操作的優雅退出時間都在30秒以內。kubectl delete命令支持--grace-period=的選項，以運行用戶來修改默認值。0表示刪除立即執行，并且立即從API中刪除pod這樣一個新的pod會在同時被創建。在節點上，被設置了立即結束的的pod，仍然會給一個很短的優雅退出時間段，才會開始被強制殺死。

有兩種方式可以向正在運行的Nginx進程的發送信號以完全管理操作：使用Nginx進程的 -s 選項或者直接使用系統命令kill發送信號給master進程。使用 -s 選項時，nginx會自動查找運行中的master進程ID(master進程負責接收并處理信號，同時根據不同的信號，對所有工作進程完成不同的管理操作).

SIGINT和SIGTERM作用一樣，用于強制 Nginx進程退出；master進程接到強制退出信號時，會向所有工作進程發送強制退出信號，如果工作進程未能及時退出，master使用計時器重復發送強制信號，計時器觸發時會發送SIGALRM信號；SIGIO信號被Nginx顯式忽略；SIGCHLD信號告訴 master進程有工作進程退出，需要完成資源回收或者重啟工作進程的工作。

master進程接到SIGQUIT信號時
將此信號轉發給工作進程。工作進程隨后關閉監聽端口以便不再接收新的連接請求，并閉空閑連接，等待活躍連接全部正常結速后，調用 ngx_worker_process_exit 退出。而 master 進程在所有工作進程都退出后，調用 ngx_master_process_exit 函數退出；

master進程接收到SIGTERM或者SIGINT信號時
將信號轉發給工作進程。工 作進程直接調用 ngx_worker_process_exit 函數退出。master進程在所有工作進程都退出后，調用ngx_master_process_exit 函數退出。另外，如果工作進程未能正常退出，master進程會等待1秒后，發送SIGKILL信號強制終止工作進程。

 -s signal      Send signal to the master process. The argument signal can be
                one of: stop, quit, reopen, reload.

                The following table shows the corresponding system signals.

                stop    SIGTERM
                quit    SIGQUIT
                reopen  SIGUSR1
                reload  SIGHUP

其中
stop — 快速關閉
quit — 優雅退出，執行完當前的請求后退出
reload — 重新加載配置文件
reopen — 重新打開日志文件

kind: Deployment
metadata:
  name: nginx-demo
  namespace: scm
  labels:
    app: nginx-demo
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
      - name: nginx-demo
        image: library/nginx-demo
        imagePullPolicy: IfNotPresent
        lifecycle:
          preStop:
            exec:
              # nginx -s quit gracefully terminate while SIGTERM triggers a quick exit
              command: ["/usr/local/openresty/nginx/sbin/nginx","-s","quit"]
        env:
          - name: PROFILE
            value: "test"
        ports:
          - name: http
            containerPort: 8080

如何優雅地關閉java應用

command: ["/bin/bash", "-c", "PID=`pidof java` && kill -SIGTERM $PID && while ps -p $PID > /dev/null; do sleep 1; done;"]

uinx 信號 SIGINT SIGTERM SIGKILL區別

優雅的終止docker容器

Termination of Pods

Issues with running as PID 1 in a Docker container.

Docker and the PID 1 zombie reaping problem

Docker 和 PID 1 僵尸進程問題

Docker系統中僵尸進程問題

kubernetes-chinese-docs-pods

Nginx 源代碼筆記 - 運維命令

Does nginx have a soft quit?

Container Lifecycle Hooks

Graceful shutdown of pods with Kubernetes

Gracefully stopping a Java process in a pod in Kubernetes?

How can I ensure graceful scaling in kubernetes?

Do Kubernetes pods still receive requests after receiving SIGTERM?

Deleting pods and other resources with graceful shutdown