Kubernetes 1.19.3
OS: CentOS 7.9.2009
Kernel: 5.4.94-1.el7.elrepo.x86_64
Docker: 20.10.6
先說結論,runc v1.0.0-rc93 有 bug,會導致 docker hang 住。
發現問題
線上告警提示集羣中存在 2-3 個 K8s 節點處於 NotReady 的狀態,並且 NotReady 狀態一直持續。
- kubectl describe node,有 NotReady 相關事件。
-
登錄問題機器後,查看節點負載情況,一切正常。
-
查看 kubelet 日誌,發現 PLEG 時間過長,導致節點被標記爲 NotReady。
-
docker ps 正常。
-
執行 ps 查看進程,發現存在幾個 runc init 的進程。runc 是 containerd 啓動容器時調用的 OCI Runtime 程序。初步懷疑是 docker hang 住了。
要解決這個問題可以通過兩種方法,首先來看一下 A 方案。
解決方案 A
針對 docker hang 住這樣的現象,通過搜索資料後發現了以下兩篇文章裏也遇到了相似的問題:
-
docker hang 問題排查[https://www.likakuli.com/posts/docker-hang/]
-
Docker hung 住問題解析系列(一):pipe 容量不夠[https://juejin.cn/post/6891559762320703495]
這兩篇文章都提到了是由於 pipe 容量不夠導致 runc init 往 pipe 寫入卡住了,將 /proc/sys/fs/pipe-user-pages-soft 的限制放開,就能解決問題。
於是,查看問題主機上 /proc/sys/fs/pipe-user-pages-soft 設置的是 16384。所以將它放大 10 倍 echo 163840 > /proc/sys/fs/pipe-user-pages-soft,然而 kubelet 還是沒有恢復正常,pleg 報錯日誌還在持續,runc init 程序也沒有退出。
考慮到 runc init 是 kubelet 調用 CRI 接口創建的,可能需要將 runc init 退出才能使 kubelet 退出。而根據文章中的說明,只需要將對應的 pipe 中的內容讀取掉,runc init 就能退出。因爲讀取 pipe 的內容可以利用「UNIX/Linux 一切皆文件」的原則,通過 lsof -p 查看 runc init 打開的句柄信息,獲取寫入類型的 pipe 對應的編號(可能存在多個),依次執行 cat /proc/$pid/fd/$id 的方式,讀取 pipe 中的內容。嘗試了幾個後,runc init 果然退出了。
再次檢查,節點狀態切換成 Ready,pleg 報錯日誌也消失了,觀察一天也沒有出現節點 NotReady 的情況,問題(臨時)解決。
對解決方案 A 疑問
雖然問題解決了,但是仔細讀 /proc/sys/fs/pipe-user-pages-soft 參數的說明文檔,不難發現這個參數跟本次問題的根本原因不太對得上。
pipe-user-pages-soft 含義是對沒有 CAP_SYS_RESOURCE CAP_SYS_ADMIN 權限的用戶使用 pipe 容量大小做出限制,默認最多隻能使用 1024 個 pipe,一個 pipe 容量大小爲 16k。
那這裏就有了疑問:
-
dockerd/containerd/kubelet 等組件均通過 root 用戶運行,並且 runc init 處於容器初始化階段,理論上不會將 1024 個 pipe 消耗掉。因此,pipe-user-pages-soft 不會對 docker hang 住這個問題產生影響,但是實際參數放大後問題就消失了,解釋不通。
-
pipe 容量是固定,用戶在創建 pipe 時無法聲明容量。從線上來看,pipe 的確被建出來了,容量是固定的話,不應該因爲用戶使用 pipe 總量超過 pipe-user-pages-soft 限制,而導致無法寫入的問題。是不是新創建的 pipe 容量變小了,導致原先可以寫入的數據,本次無法寫入了?
-
目前對 pipe-user-pages-soft 放大了 10 倍,放大 2 倍夠不夠,哪個值是最合適的值?
探索
定位問題最直接的方法,就是閱讀源碼。
先查看下 Linux 內核跟 pipe-user-pages-soft 相關的代碼。線上內核版本爲 5.4.94-1,切換到對應的版本進行檢索。
static bool too_many_pipe_buffers_soft(unsigned long user_bufs)
{
unsigned long soft_limit = READ_ONCE(pipe_user_pages_soft);
return soft_limit && user_bufs > soft_limit;
}
struct pipe_inode_info *alloc_pipe_info(void)
{
...
unsigned long pipe_bufs = PIPE_DEF_BUFFERS; // #define PIPE_DEF_BUFFERS 16
...
if (too_many_pipe_buffers_soft(user_bufs) && is_unprivileged_user()) {
user_bufs = account_pipe_buffers(user, pipe_bufs, 2);
pipe_bufs = 2;
}
if (too_many_pipe_buffers_hard(user_bufs) && is_unprivileged_user())
goto out_revert_acct;
pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer),
GFP_KERNEL_ACCOUNT);
...
}
在創建 pipe 時,內核會通過 too_many_pipe_buffers_soft 檢查是否超過當前用戶可使用 pipe 容量大小。如果發現已經超過,則將容量大小從 16 個 PAGE_SIZE 調整成 2 個 PAGE_SIZE。通過機器上執行 getconf PAGESIZE 可以獲取到 PAGESIZE 是 4096 字節,也就是說正常情況下 pipe 大小爲 164096 字節,但是由於超過限制,pipe 大小被調整成 24096 字節,這就有可能出現數據無法一次性寫入 pipe 的問題,基本可以驗證問題 2 的猜想。
至此,pipe-user-pages-soft 相關的邏輯也理順了,相對還是比較好理解的。
那麼,問題就回到了「爲什麼容器 root 用戶 pipe 容量會超過限制」。
百分百復現
找到問題根本原因的第一步,往往是在線下環境復現問題。
由於線上環境已經都通過方案 A 做了緊急修復,因此,已經無法在線上分析問題了,需要找到一種必現的手段。
功夫不負有心人,在 issue 中找到了相同的問題,並且可以通過以下方法復現。
https://github.com/containerd/containerd/issues/5261
echo 1 > /proc/sys/fs/pipe-user-pages-soft
while true; do docker run -itd --security-opt=no-new-privileges nginx; done
執行以上命令之後,立刻就出現 runc init 卡住的情況,跟線上的現象是一致的。通過 lsof -p 查看 runc init 打開的文件句柄情況:
可以看到 fd4、fd5、fd6 都是 pipe 類型,其中,fd4 跟 fd6 編號都是 415841,是同一個 pipe。那麼,如何來獲取 pipe 大小來實際驗證下「疑問 2」中的猜想呢?Linux 下沒有現成的工具可以獲取 pipe 大小,但是內核開放了系統調用 fcntl(fd, F_GETPIPE_SZ)可以獲取到,代碼如下:
#include <unistd.h>
#include <errno.h>
#include <stdio.h>
// Must use Linux specific fcntl header.
#include </usr/include/linux/fcntl.h>
int main(int argc, char *argv[]) {
int fd = open(argv[1], O_RDONLY);
if (fd < 0) {
perror("open failed");
return 1;
}
long pipe_size = (long)fcntl(fd, F_GETPIPE_SZ);
if (pipe_size == -1) {
perror("get pipe size failed.");
}
printf("pipe size: %ld\\n", pipe_size);
close(fd);
}
編譯好之後,查看 pipe 大小情況如下:
重點看下 fd4 跟 fd6,兩個句柄對應的是同一個 pipe,獲取到的容量大小是 8192 = 2 * PAGESIZE。所以的確是因爲 pipe 超過軟限制導致 pipe 容量被調整成了 2 * PAGESIZE。
使用 A 方案解決問題後,我們來看一下 B 方案。
解決方案 B
https://github.com/opencontainers/runc/pull/2871
該 bug 是在 runc v1.0.0-rc93 中引入的,並且在 v1.0.0-rc94 中通過上面的 PR 修復。那麼,線上應該如何做修復呢?是不是需要把 docker 所有組件都升級呢?
如果把 dockerd/containerd/runc 等組件都升級的話,就需要將業務切走然後才能升級,整個過程相對比較複雜,並且風險較高。而且在本次問題中,出問題的只有 runc,並且只有新創建的容器受到影響。因此順理成章考慮是否可以單獨升級 runc?
因爲在 Kubernetes v1.19 版本中還沒有棄用 dockershim,因此運行容器整個調用鏈爲:kubelet → dockerd → containerd → containerd-shim → runc → container。不同於 dockerd/containerd 是後臺運行的服務端,containerd-shim 調用 runc,實際是調用了 runc 二進制來啓動容器。因此,我們只需要升級 runc,對於新創建的容器,就會使用新版本的 runc 來運行容器。
在測試環境驗證了下,的確不會出現 runc init 卡住的情況了。最終,逐步將線上 runc 升級成 v1.1.1,並將 /proc/sys/fs/pipe-user-pages-soft 調整回原默認值。runc hang 住的問題圓滿解決。
分析&總結
PR 做了什麼修復?
Bug 的緣由。當容器開啓 no-new-privileges 後,runc 會需要去卸載一段已經加載的 bpf 代碼,然後重新加載 patch 後的 bpf 代碼。在 bpf 的設計中,需要先獲取已經加載的 bpf 代碼,然後才能利用這段代碼調用卸載接口。在獲取 bpf 代碼,內核開放了 seccomp_export_bpf 函數,runc 採用了 pipe 作爲 fd 句柄傳參來獲取代碼,由於 seccomp_export_bpf 函數是同步阻塞的,內核會將代碼寫入到 fd 句柄中,因此,如果 pipe 大小太小的話,就會出現 pipe 數據寫滿後無法寫入 bpf 代碼導致卡住的情況。
PR 中的解決方案。啓動一個 goroutine 來及時讀取 pipe 中的內容,而不是等數據寫入完成後再讀取。
爲什麼超過限制?
容器的 root 用戶 UID 爲 0,而宿主機的 root 用戶 UID 也是 0。在內核統計 pipe 使用量時,認爲是同一用戶,沒有做區分。所以,當 runc init 申請 pipe 時,內核判斷當前用戶沒有特權,就查詢 UID 爲 0 的用戶 pipe 使用量,由於內核統計的是所有 UID 爲 0 用戶(包括容器內) pipe 使用量的總和,所以已經超過了 /proc/sys/fs/pipe-user-pages-soft 中的限制。而實際容器 root 用戶 pipe 使用量並沒有超過限制。這就解釋了前面提到的疑問 2。
所以我們最後做個總結,本次故障的原因是,操作系統對 pipe-user-pages-soft 有軟限制,但是由於容器 root 用戶的 UID 與宿主機一致都是 0,內核統計 pipe 使用量時沒有做區分,導致當 UID 爲 0 的用戶 pipe 使用量超過軟限制後,新分配的 pipe 容量會變小。而 runc 1.0.0-rc93 正好會因爲 pipe 容量太小,導致數據無法完整寫入,寫入阻塞,一直同步等待,進而 runc init 卡住,kubelet pleg 狀態異常,節點 NotReady。
修復方案,runc 通過 goroutine 及時讀取 pipe 內容,防止寫入阻塞。
參考資料
https://iximiuz.com/en/posts/container-learning-path/
https://medium.com/@mccode/understanding-how-uid-and-gid-work-in-docker-containers-c37a01d01cf
https://man7.org/linux/man-pages/man7/pipe.7.html
https://gist.github.com/cyfdecyf/1ee981611050202d670c
https://github.com/containerd/containerd/issues/5261
https://github.com/opencontainers/runc/pull/2871