聊聊容器與pod中的僵尸進程
三種狀態的進程模型
按進程在執行過程中的不同情況至少要定義三種狀態：
- 運行(running)態：進程占有處理器正在運行的狀態。進程已獲得CPU，其程序正在執行。在單處理機系統中，只有一個進程處于執行狀態;在多處理機系統中，則有多個進程處于執行狀態。
- 就緒(ready)態：進程具備運行條件，等待系統分配處理器以便運行的狀態。當進程已分配到除CPU以外的所有必要資源后，只要再獲得CPU，便可立即執行，進程這時的狀態稱為就緒狀態。在一個系統中處于就緒狀態的進程可能有多個，通常將它們排成一個隊列，稱為就緒隊列。
- 等待(wait)態：又稱阻塞態或睡眠態，指進程不具備運行條件，正在等待某個時間完成的狀態。也稱為等待或睡眠狀態，一個進程正在等待某一事件發生(例如請求I/O而等待I/O完成等)而暫時停止運行，這時即使把處理機分配給進程也無法運行，故稱該進程處于阻塞狀態。
引起進程狀態轉換的具體原因如下：
- 運行態→等待態：等待使用資源;如等待外設傳輸;等待人工干預。
- 等待態→就緒態：資源得到滿足;如外設傳輸結束;人工干預完成。
- 運行態→就緒態：運行時間片到;出現有更高優先權進程。
- 就緒態—→運行態：CPU 空閑時選擇一個就緒進程。
五種狀態的進程模型
五態模型在三態模型的基礎上增加了新建態(new)和終止態(exit)。
新建態：對應于進程被創建時的狀態，尚未進入就緒隊列。創建一個進程需要通過兩個步驟：1.為新進程分配所需要資源和建立必要的管理信息。2.設置該進程為就緒態，并等待被調度執行。
終止態：指進程完成任務到達正常結束點，或出現無法克服的錯誤而異常終止，或被操作系統及有終止權的進程所終止時所處的狀態。處于終止態的進程不再被調度執行，下一步將被系統撤銷，最終從系統中消失。終止一個進程需要兩個步驟：1.先等待操作系統或相關的進程進行善后處理(如抽取信息)。2.然后回收占用的資源并被系統刪除。
引起進程狀態轉換的具體原因如下：
- NULL→新建態：執行一個程序，創建一個子進程。
- 新建態→就緒態：當操作系統完成了進程創建的必要操作，并且當前系統的性能和虛擬內存的容量均允許。
- 運行態→終止態：當一個進程到達了自然結束點，或是出現了無法克服的錯誤，或是被操作系統所終結，或是被其他有終止權的進程所終結。
- 運行態→就緒態：運行時間片到;出現有更高優先權進程。
- 運行態→等待態：等待使用資源;如等待外設傳輸;等待人工干預。
- 就緒態→終止態：未在狀態轉換圖中顯示，但某些操作系統允許父進程終結子進程。
- 等待態→終止態：未在狀態轉換圖中顯示，但某些操作系統允許父進程終結子進程。
- 終止態→NULL：完成善后操作。
linux的進程狀態
無論進程還是線程，在 Linux 內核里其實都是用 task_struct{}這個結構來表示的。它其實就是任務(task)，也就是 Linux 里基本的調度單位。
Linux進程狀態有：
- TASK_RUNNING : 就緒態或者運行態，進程就緒可以運行，但是不一定正在占有CPU，對應進程狀態的R。
- TASK_INTERRUPTIBLE:睡眠態，但是進程處于淺度睡眠，可以響應信號，一般是進程主動sleep進入的狀態，對應進程狀態S。
- TASK_UNINTERRUPTIBLE:睡眠態，深度睡眠，不響應信號，典型場景是進程獲取信號量阻塞，對應進程狀態D。
- TASK_ZOMBIE:僵尸態，進程已退出或者結束，但是父進程還不知道，沒有回收時的狀態，結束之前的一個狀態，對應進程狀態Z。
- EXIT_DEAD:結束態，進程已經結束，也就是進程結束退出那一瞬間的狀態，對應進程狀態X。
- TASK_STOPED:停止，調試狀態，對應進程狀態T。
孤兒進程
一個父進程退出，而它的一個或多個子進程還在運行，那么那些子進程將成為孤兒進程。孤兒進程將被init進程(進程號為1，也有可能是容器中的init)所收養，并由init進程對它們完成狀態收集工作。孤兒進程是沒有父進程的進程，孤兒進程這個重任就落到了init進程身上，init進程就好像是一個民政局，專門負責處理孤兒進程的善后工作。每當出現一個孤兒進程的時候，內核就把孤 兒進程的父進程設置為init，而init進程會循環地wait()它的已經退出的子進程。這樣，當一個孤兒進程凄涼地結束了其生命周期的時候，init進程就會代表黨和政府出面處理它的一切善后工作。因此孤兒進程并不會有什么危害。
僵尸進程
在類UNIX系統中，僵尸進程是指完成執行(通過 exit 系統調用，或運行時發生致命錯誤或收到終止信號所致)，但在操作系統的進程表中仍然存在其進程控制塊，處于"終止狀態"的進程。我們從上面的概念中得知，僵尸進程仍然存在在進程表中。進程會占用系統系統資源，僵尸進程過多會導致資源泄露，最主要的資源就是PID。我們來看一下linux系統中的PID。這個最大值可以我們在 /proc/sys/kernel/pid_max 這個參數中看到。
- [root@k8s-dev]# cat /proc/sys/kernel/pid_max
- 32768
Linux 內核在進行初始化時，會根據CPU 的數目對 pid_max 進行設置。
- 如果CPU 的數目小于等于32，那么 pid_max 會被設置為32768;
- 如果CPU 的數目大于32，那么 pid_max = 1024 * (CPU 數目)。
所以如果超過這個最大值，那么系統就無法創建出新的進程了，比如你想 SSH 登錄到這臺機器上就不行了。清理僵尸進程：了解了僵尸進程的危害，我們來看看怎么清理僵尸進程：收割僵尸進程的方法是通過kill命令手工向其父進程發送SIGCHLD信號。如果其父進程仍然拒絕收割僵尸進程，則終止父進程，使得init進程收養僵尸進程。init進程周期執行wait系統調用收割其收養的所有僵尸進程。為避免產生僵尸進程，實際應用中一般采取的方式是：
將父進程中對SIGCHLD信號的處理函數設為SIG_IGN(忽略信號);
- fork兩次并殺死一級子進程，令二級子進程成為孤兒進程而被init所“收養”、清理。
- docker容器中的進程
容器中的PID
在Docker中，進程管理的基礎就是Linux內核中的PID名空間技術。在不同PID名空間中，進程ID是獨立的;即在兩個不同名空間下的進程可以有相同的PID。
Linux內核為所有的PID名空間維護了一個樹狀結構：最頂層的是系統初始化時創建的root namespace(根名空間)，再創建的新PID namespace就稱之為child namespace(子名空間)，而原先的PID名空間就是新創建的PID名空間的parent namespace(父名空間)。通過這種方式，系統中的PID名空間會形成一個層級體系。父節點可以看到子節點中的進程，并可以通過信號等方式對子節點中的進程產生影響。反過來，子節點不能看到父節點名空間中的任何內容，也不可能通過kill或ptrace影響父節點或其他名空間中的進程。
在Docker中，每個Container都是Docker Daemon的子進程，每個Container進程缺省都具有不同的PID名空間。通過名空間技術，Docker實現容器間的進程隔離。另外Docker Daemon也會利用PID名空間的樹狀結構，實現了對容器中的進程交互、監控和回收。注：Docker還利用了其他名空間(UTS，IPC，USER)等實現了各種系統資源的隔離，由于這些內容和進程管理關聯不多，本文不會涉及。
容器退出
當創建一個Docker容器的時候，就會新建一個PID名空間。容器啟動進程在該名空間內PID為1。當PID1進程結束之后，Docker會銷毀對應的PID名空間，并向容器內所有其它的子進程發送SIGKILL。
當執行docker stop命令時，docker會首先向容器的PID1進程發送一個SIGTERM信號，用于容器內程序的退出。如果容器在收到SIGTERM后沒有結束， 那么Docker Daemon會在等待一段時間(默認是10s)后，再向容器發送SIGKILL信號，將容器殺死變為退出狀態。這種方式給Docker應用提供了一個優雅的退出(graceful stop)機制，允許應用在收到stop命令時清理和釋放使用中的資源。
docker kill可以向容器內PID1進程發送任何信號，缺省是發送SIGKILL信號來強制退出應用。
容器中的僵尸進程
產生原因
容器化后，由于單容器單進程，已經沒有傳統意義上的 init 進程了。應用進程直接占用了 pid 1 的進程號。從而導致以下兩個問題。
常見的使用是 docker run my-container script 。給 docker run進程發送SIGTERM 信號會殺掉 docker run 進程，但是容器還在后臺運行。
2.當進程退出時，它會變成僵尸進程，直到它的父進程調用 wait()( 或其變種 ) 的系統調用。process table 里面會把它的標記為 defunct 狀態。一般情況下，父進程應該立即調用 wait(), 以防僵尸進程時間過長。
如果父進程在子進程之前退出，子進程會變成孤兒進程, 它的父進程會變成 PID 1。因此，init進程就要對這些進程負責，并在適當的時候調用 wait() 方法。通常情況下，大部分應用進程不會處理偶然依附在自己進程上的隨機子進程，所以在容器中，會出現許多僵尸進程。
解決方案
解決這個的辦法就是pid為1的跑一個支持信號轉發且支持回收孤兒僵尸進程的進程就行了，為此有人開發出了tini項目，感興趣可以github上搜下下，現在tini已經內置在docker里了。使用tini可以在docker run的時候添加選項–init即可，底層我猜測是復制docker-init到容器的/dev/init路徑里然后啟動entrypoint cmd，大家可以在run的時候測試下上面的步驟會發現根本不會有僵尸進程遺留。這里不多說，如果是想默認使用tini可以把tini構建到鏡像里(例如k8s目前不支持docker run 的--init，所以需要把tini做到鏡像里)，參照jenkins官方鏡像dockerfile和tini的github地址文檔 https://github.com/krallin/tini
k8s pod中的僵尸進程
k8s 可以將多個容器編排到一個 pod 里面，共享同一個 Linux Namespace。這項技術的本質是使用 k8s 提供一個 pause 鏡像，也就是說先啟動一個 pause 容器，相當于實例化出 Namespace，然后其他容器加入這個 Namespace 從而實現 Namespace 的共享。我們來介紹一下 pause。
pause 是 k8s 在 1.16 版本引入的技術，要使用 pause，我們只需要在 pod 創建的 yaml 中指定 shareProcessNamespace 參數為 true，如下：
- apiVersion: v1
- kind: Pod
- metadata:
- name: nginx
- spec:
- shareProcessNamespace: true
- containers:
- - name: nginx
- image: nginx
- - name: shell
- image: busybox
- securityContext:
- capabilities:
- add:
- - SYS_PTRACE
- stdin: true
- tty: true
attach到pod中，ps查看進程列表：
- / # kubectl attach POD -c CONTAINER
- / # ps ax
- PID USER TIME COMMAND
- 1 root 0:00 /pause
- 8 root 0:00 nginx: master process nginx -g daemon off;
- 14 101 0:00 nginx: worker process
- 15 root 0:00 sh
- 21 root 0:00 ps ax
我們可以看到 pod 中的 1 號進程變成了 /pause，其他容器的 entrypoint 進程都變成了 1 號進程的子進程。這個時候開始逐漸逼近事情的本質了：/pause 進程是如何處理 將孤兒進程的父進程置為 1 號進程進而避免僵尸進程的呢?
pause 鏡像的源碼如下：pause.c
- #include <signal.h>
- #include <stdio.h>
- #include <stdlib.h>
- #include <string.h>
- #include <sys/types.h>
- #include <sys/wait.h>
- #include <unistd.h>
- static void sigdown(int signo) {
- psignal(signo, "Shutting down, got signal");
- exit(0);
- }
- // 關注1
- static void sigreap(int signo) {
- while (waitpid(-1, NULL, WNOHANG) > 0)
- ;
- }
- int main(int argc, char **argv) {
- int i;
- for (i = 1; i < argc; ++i) {
- if (!strcasecmp(argv[i], "-v")) {
- printf("pause.c %s\n", VERSION_STRING(VERSION));
- return 0;
- }
- }
- if (getpid() != 1)
- /* Not an error because pause sees use outside of infra containers. */
- fprintf(stderr, "Warning: pause should be the first process\n");
- if (sigaction(SIGINT, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0)
- return 1;
- if (sigaction(SIGTERM, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0)
- return 2;
- // 關注2
- if (sigaction(SIGCHLD, &(struct sigaction){.sa_handler = sigreap,
- .sa_flags = SA_NOCLDSTOP},
- NULL) < 0)
- return 3;
- for (;;)
- pause(); // 編者注：該系統調用的作用是wait for signal
- fprintf(stderr, "Error: infinite loop terminated\n");
- return 42;
- }
重點關注一下void sigreap(int signo){...}和if (sigaction(SIGCHLD,...) ，這個不就是我們上面說的 除了這種方式外，還可以通過異步的方式來進行回收，這種方式的基礎是子進程結束之后會向父進程發送 SIGCHLD 信號，基于此父進程注冊一個 SIGCHLD 信號的處理函數來進行子進程的資源回收就可以了。
SIGCHLD 信號的處理函數核心就是這一行 while (waitpid(-1, NULL, WNOHANG) > 0) ，其中各參數示意如下：
- -1：meaning wait for any child process.
- NULL：?
- WNOHANG ：return immediately if no child has exited.
結論
得出pause 容器的兩個最重要的特性：
- 在 pod 中作為容器共享namespace的基礎
- 作為 pod 內的所有容器的父容器，扮演 init 進程(即systemd)的作用。
最后
通過這篇文章的學習，大家能解決容器中出現僵尸進程的問題。
本文轉載自微信公眾號「運維開發故事」
