SIGINT SIGTERM SIGKILL區(qū)別

三者都是結(jié)束/終止進程運行霍弹。

1.SIGINT SIGTERM區(qū)別

前者與字符ctrl+c關聯(lián)，后者沒有任何控制字符關聯(lián)娃弓。
前者只能結(jié)束前臺進程典格，后者則不是。

2.SIGTERM SIGKILL的區(qū)別

前者可以被阻塞台丛、處理和忽略耍缴，但是后者不可以。KILL命令的默認不帶參數(shù)發(fā)送的信號就是SIGTERM.讓程序有好的退出挽霉。因為它可以被阻塞防嗡，所以有的進程不能被結(jié)束時，用kill發(fā)送后者信號侠坎，即可蚁趁。即：kill-9 進程號。

1-ZAZWGqxfJh59DsqQlFWakw.png

docker stop與docker kill

docker stop

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

在docker stop命令執(zhí)行的時候，會先向容器中PID為1的進程(main process)發(fā)送系統(tǒng)信號SIGTERM童芹，然后等待容器中的應用程序終止執(zhí)行涮瞻，如果等待時間達到設定的超時時間，或者默認的10秒假褪，會繼續(xù)發(fā)送SIGKILL的系統(tǒng)信號強行kill掉進程署咽。在容器中的應用程序客扎，可以選擇忽略和不處理SIGTERM信號，不過一旦達到超時時間脉让，程序就會被系統(tǒng)強行kill掉铸磅，因為SIGKILL信號是直接發(fā)往系統(tǒng)內(nèi)核的，應用程序沒有機會去處理它慕匠。

docker kill

默認情況下饱须，docker kill命令不會給容器中的應用程序有任何gracefully shutdown的機會。它會直接發(fā)出SIGKILL的系統(tǒng)信號台谊，以強行終止容器中程序的運行蓉媳。

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

docker stop命令盐须，更類似于Linux系統(tǒng)中的kill命令玩荠，二者都是發(fā)送系統(tǒng)信號SIGTERM。而docker kill命令贼邓，更像是Linux系統(tǒng)中的kill -9或者是kill -SIGKILL命令阶冈，用來發(fā)送SIGKILL信號，強行終止進程立帖。

關于pid為1的進程

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

子進程在結(jié)束后描融，內(nèi)核仍然會為其維護一個基本的結(jié)構(gòu)铝噩，保存其pid, 退出原因和狀態(tài)等信息，父進程通過waitpid系統(tǒng)調(diào)用窿克，可以獲得這些信息骏庸。如果父進程沒有調(diào)用waitpid，這些狀態(tài)信息會一直保留年叮，變成所謂僵尸進程具被。如果子進程后于父進程結(jié)束，一般來說, init進程會負責這些孤兒進程只损。

根據(jù)一般一個容器只運行一個進程的原則一姿，對于一個web服務七咧，它在容器中運行時的pid是1，假設它調(diào)用了bash的cgi腳本叮叹，而這個腳本又調(diào)用了grep艾栋，一段時間后，cgi腳本因為某種原因超時蛉顽，web服務開始嘗試殺死它蝗砾，但是grep卻并未受到影響，因此變成了孤兒進程携冤。這時遥诉，pid=1的web服務應該能接管，但是絕大多數(shù)的web服務并沒有init那樣的能力噪叙，所以grep就變成了僵尸進程。

kubernetes的pod關閉機制

pod代表著一個集群中節(jié)點上運行的進程霉翔，讓這些進程不再被需要睁蕾，優(yōu)雅的退出是很重要的（與粗暴的用一個KILL信號去結(jié)束，讓應用沒有機會進行清理操作）债朵。用戶應該能請求刪除子眶，并且在室進程終止的情況下能知道，而且也能保證刪除最終完成序芦。當一個用戶請求刪除pod臭杰，系統(tǒng)記錄想要的優(yōu)雅退出時間段，在這之前Pod不允許被強制的殺死谚中，TERM信號會發(fā)送給容器主要的進程渴杆。一旦優(yōu)雅退出的期限過了，KILL信號會送到這些進程宪塔，pod會從API服務器其中被刪除磁奖。如果在等待進程結(jié)束的時候，Kubelet或者容器管理器重啟了某筐，結(jié)束的過程會帶著完整的優(yōu)雅退出時間段進行重試比搭。

一個示例流程：

• 1.用戶發(fā)送一個命令來刪除Pod，默認的優(yōu)雅退出時間是30秒
• 2.API服務器中的Pod更新時間南誊，超過該時間Pod被認為死亡
• 3.在客戶端命令的的里面身诺，Pod顯示為"Terminating（退出中）"的狀態(tài)
• 4.（與第3同時）當Kubelet看到Pod標記為退出中的時候，因為第2步中時間已經(jīng)設置了抄囚，它開始pod關閉的流程
• 4.1如果該Pod定義了一個停止前的鉤子霉赡，其會在pod內(nèi)部被調(diào)用。如果鉤子在優(yōu)雅退出時間段超時仍然在運行怠苔，第二步會意一個很小的優(yōu)雅時間斷被調(diào)用
• 4.2進程被發(fā)送TERM的信號
• 5.（與第三步同時進行）Pod從service的列表中被刪除同廉，不在被認為是運行著的pod的一部分。緩慢關閉的pod可以繼續(xù)對外服務，當負載均衡器將他們輪流移除迫肖。
• 6.當優(yōu)雅退出時間超時了锅劝，任何pod中正在運行的進程會被發(fā)送SIGKILL信號被殺死。
• 7.Kubelet會完成pod的刪除蟆湖，將優(yōu)雅退出的時間設置為0（表示立即刪除）故爵。pod從API中刪除，不在對客戶端可見隅津。

默認情況下诬垂，所有的刪除操作的優(yōu)雅退出時間都在30秒以內(nèi)。kubectl delete命令支持--grace-period=的選項伦仍，以運行用戶來修改默認值结窘。0表示刪除立即執(zhí)行，并且立即從API中刪除pod這樣一個新的pod會在同時被創(chuàng)建充蓝。在節(jié)點上隧枫，被設置了立即結(jié)束的的pod，仍然會給一個很短的優(yōu)雅退出時間段谓苟，才會開始被強制殺死官脓。

nginx與SIGTERM

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

SIGINT和SIGTERM作用一樣仑撞，用于強制 Nginx進程退出赤兴；master進程接到強制退出信號時，會向所有工作進程發(fā)送強制退出信號隧哮，如果工作進程未能及時退出搀缠，master使用計時器重復發(fā)送強制信號，計時器觸發(fā)時會發(fā)送SIGALRM信號近迁；SIGIO信號被Nginx顯式忽略艺普；SIGCHLD信號告訴 master進程有工作進程退出，需要完成資源回收或者重啟工作進程的工作鉴竭。

Nginx進程退出分為兩種

• master進程接到SIGQUIT信號時
  將此信號轉(zhuǎn)發(fā)給工作進程歧譬。工作進程隨后關閉監(jiān)聽端口以便不再接收新的連接請求，并閉空閑連接搏存，等待活躍連接全部正常結(jié)速后瑰步，調(diào)用 ngx_worker_process_exit 退出。而 master 進程在所有工作進程都退出后璧眠，調(diào)用 ngx_master_process_exit 函數(shù)退出缩焦；

• master進程接收到SIGTERM或者SIGINT信號時
  將信號轉(zhuǎn)發(fā)給工作進程读虏。工 作進程直接調(diào)用 ngx_worker_process_exit 函數(shù)退出。master進程在所有工作進程都退出后袁滥，調(diào)用ngx_master_process_exit 函數(shù)退出盖桥。另外，如果工作進程未能正常退出题翻，master進程會等待1秒后揩徊，發(fā)送SIGKILL信號強制終止工作進程。

nginx的優(yōu)雅退出

 -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 — 優(yōu)雅退出嵌赠，執(zhí)行完當前的請求后退出
reload — 重新加載配置文件
reopen — 重新打開日志文件

使用kubernetes Lifecycle Hooks優(yōu)雅退出nginx

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

題外

如何優(yōu)雅地關閉java應用

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

doc

• uinx 信號 SIGINT SIGTERM SIGKILL區(qū)別
• 優(yōu)雅的終止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系統(tǒng)中僵尸進程問題
• 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