導(dǎo)讀：近期，我們遇到了一個(gè)棘手的線上故障：在 K8s 集群宿主機(jī)執(zhí)行 systemd 相關(guān)發(fā)布操作時(shí)，會(huì)觸發(fā)宿主機(jī)上的業(yè)務(wù)服務(wù)出現(xiàn)超時(shí)問題。

本文將完整復(fù)盤這一故障的排查全過程，從業(yè)務(wù)超時(shí)的異?，F(xiàn)象切入，一步步抽絲剝繭，最終定位到runc 1.1.5 版本向 systemd 傳遞錯(cuò)誤綁核信息這一根因。排查過程中，我們還會(huì)分享如何巧用 Perfetto、BPF 等工具捕捉關(guān)鍵線索，還原問題本質(zhì)。無論你是 K8s 運(yùn)維人員、容器技術(shù)愛好者，還是經(jīng)常與線上故障 “過招” 的研發(fā)同學(xué)，都能從這份實(shí)戰(zhàn)案例中收獲排查思路與工具使用技巧，為日后解決同類問題提供可借鑒的參考。

關(guān)鍵詞：k8s, BPF, containerd, runc, systemd

• 一、故障的起因

• 二、排查過程

• 2.1 為什么 CPU Load 會(huì)升高？

• 2.2 為什么 CPU 使用率掉底了？

• 2.3 為什么綁核容器使用了同樣的 CPU？

• 2.4 Systemd 的錯(cuò)誤參數(shù)是哪里來的？

• 三、總結(jié)與思考

故障的起因

在某次對(duì) systemd 管理的組件進(jìn)行變更后，觀測(cè)到服務(wù)出現(xiàn)大量超時(shí)。這些服務(wù)都是綁核的時(shí)延敏感型服務(wù)，所在機(jī)器的 cpu load 都顯著升高，這可能是造成業(yè)務(wù)超時(shí)的原因。

排查過程

2.1 為什么 CPU Load 會(huì)升高？

在故障發(fā)生的機(jī)器上，我們注意到 CPU load 明顯升高。

圖片為了復(fù)現(xiàn)問題，我們選取了一臺(tái)宿主機(jī)，排空上面的業(yè)務(wù)實(shí)例，并部署了 90 個(gè) 2 核的綁核容器用于模擬業(yè)務(wù)實(shí)例。對(duì)這 90 個(gè)容器發(fā)送請(qǐng)求，使得 cpu 利用率穩(wěn)定在 50%，然后對(duì)這臺(tái)宿主機(jī)進(jìn)行一次相同的變更。cpu load 并沒有像故障時(shí)那樣劇烈上升，但是我們卻發(fā)現(xiàn)了 cpu util 的異常現(xiàn)象：在本次變更后，cpu util 瞬間下降。下圖為我們?cè)趩栴}復(fù)現(xiàn)時(shí)的 cpu util 變化情況。

我們又重新看了下機(jī)器監(jiān)控，發(fā)現(xiàn)在故障發(fā)生時(shí)，很多其他的指標(biāo)也符合 cpu util 下降的表現(xiàn)，例如：

• cpu idle time 上升

• 進(jìn)程切換的次數(shù)下降

• 軟中斷的次數(shù)下降

我們意識(shí)到，cpu load 升高可能并不是業(yè)務(wù)超時(shí)的原因，而是結(jié)果。我們有一直往被測(cè)試的 Pod 打流量，按理說它們應(yīng)該一直很繁忙猜對(duì)，為什么 CPU 使用率會(huì)下降呢？當(dāng)時(shí)的 CPU 核上在做什么？

`2.2 為什么 CPU 使用率掉底了？

那么為何發(fā)布會(huì)導(dǎo)致 cpu 使用率掉底了？我們抓取了 cfs 的調(diào)度事件，想看看當(dāng)時(shí) CPU 上到底在跑什么，使用 perfetto 分析得到的數(shù)據(jù)如下：

可以看到，在發(fā)布后，某些核上的任務(wù)被切成 idle 了。這些容器都是綁核的容器，是一直有流量進(jìn)來的，容器一直存活，為何這些核上的任務(wù)被切成 idle 了？

檢查了下容器的 cpuset.cpus，發(fā)現(xiàn)，在發(fā)布過后，一些不同的容器竟然綁定到了相同的核！

我們又對(duì)比了發(fā)布前容器拿到的 cpu 列表和 kubelet 分配的記錄，是一致的。

也就是說，在發(fā)布前，容器分配到的核與 kubelet 分配的記錄保持一致，符合預(yù)期。而在發(fā)布后，分配被打亂，有些容器使用了同樣的 CPU 列表。這就導(dǎo)致在這些 CPU 上排隊(duì)的線程數(shù)多了，cpu load 上升， 線程遲遲得不到調(diào)度，業(yè)務(wù)的延遲也上升。被空出來的 cpu 就處于 idle 狀態(tài)，所以整體的 cpu 使用率下降了。

2.3 為什么綁核容器使用了同樣的 CPU？

那么是誰改了容器的 cpuset.cpus，導(dǎo)致不同的綁核容器跑到了同樣的 cpu 核上 ？我們寫了一個(gè) bpf 程序，通過埋點(diǎn) linux 內(nèi)核函數(shù) cpuset_write_resmask ，監(jiān)控是誰在修改 cpuset.cpus 文件。

發(fā)現(xiàn)在容器創(chuàng)建時(shí)，runc 和 systemd 都會(huì)去設(shè)置 cpuset.cpus 文件，其中 runc 直接寫入的 cpu 列表是 kubelet 分配的 cpu 列表，符合預(yù)期，而systemd 寫入的是錯(cuò)的。

在容器創(chuàng)建時(shí)，執(zhí)行順序上，systemd 會(huì)先寫入，runc 再后寫入，因此最終的結(jié)果是對(duì)的。發(fā)布通過 systemd 管理的組件時(shí)，會(huì)執(zhí)行 systemd daemon-reload , 這會(huì)觸發(fā) systemd 對(duì)賬，將它自己持有的配置數(shù)據(jù)同步到 cgroup , 從上圖我們可以看到它持有的配置數(shù)據(jù)是錯(cuò)的，同步到 cgroup 后就導(dǎo)致不同的綁核容器使用同樣的 cpu 核了，這就是業(yè)務(wù)超時(shí)的原因。

2.4 Systemd 的錯(cuò)誤參數(shù)是哪里來的？

systemd 設(shè)置 cpuset.cpus 的鏈路為“容器創(chuàng)建請(qǐng)求 -> kubelet -> containerd -> containerd-shim-runc-v2 -> runc -> systemd ->容器 cgroup 的 cpuset.cpus”

結(jié)合 bpf 程序的結(jié)果。我們可以發(fā)現(xiàn)，runc 拿到的是一個(gè)正確的參數(shù)，但是 systemd 卻得到了一個(gè)錯(cuò)誤的參數(shù)，問題可能出現(xiàn)在 runc 傳給 systemd 的參數(shù)上。

該機(jī)器使用的 runc 版本是 v1.1.5，去查看了 runc 的 release log ，在 v1.1.6 中發(fā)現(xiàn)了相關(guān)的 bug-fix。

圖片于是我們將 runc 從 v1.1.5 升級(jí)到了 v1.1.6，再次進(jìn)行實(shí)驗(yàn)，發(fā)現(xiàn)錯(cuò)誤綁核的問題不再發(fā)生。至此，我們將問題定位到了 runc v1.1.5 的 bug 上。

定位問題后，現(xiàn)在來詳解一些為何 runc 拿到的是正確的綁核信息，傳給 systemd 后就變成了錯(cuò)誤的綁核信息。這里先貼一下該 bug-fix 的 PR https://github.com/opencontainers/runc/pull/3808/files

關(guān)鍵的代碼為：

    } 

這段代碼的邏輯是做一個(gè)反序操作，將 cpu 序號(hào)的二進(jìn)制掩碼轉(zhuǎn)成 systemd 要求的順序，systemd 在這個(gè) PR 里面做了對(duì)應(yīng)的接口。

舉例來說，假設(shè)一個(gè)容器想要綁定的核是"0-3,12"，即 0 至 3 號(hào)核，以及 12 號(hào)核。

systemd 期望得到的信息是這樣的：

    } 

在 runc 的這個(gè) bug-fix 之前，并沒有進(jìn)行反序操作，因此 runc 給 systemd 的信息是這樣的

這就導(dǎo)致 systemd 拿到的 cpu 信息為 4 號(hào)核，以及 8 至 11 號(hào)核。

那為何會(huì)有不同容器綁定到一個(gè)核上？ 舉例來說，容器 A 想要綁定的是 8 號(hào)核與 10 號(hào)核，容器 B 想要綁定的是 16 號(hào)核與 18 號(hào)核。 Systemd 期望的參數(shù)是：

容器 A：

00000101  // 8 號(hào)以及 10 號(hào)核

容器 B:

00000101  // 8 號(hào)以及 10 號(hào)核

實(shí)際 runc 1.1.5 版本給 systemd 的信息分別是:

容器 A:

00000000

容器 B:

00000000

兩者都被 systemd 解析為需要 0 號(hào)核與 2 號(hào)核。

總結(jié)與思考

最后來總結(jié)下，本次故障的原因?yàn)椋?/p>

容器創(chuàng)建時(shí)，systemd 拿到了錯(cuò)誤的綁核信息，runc 拿到了正確的綁核信息，由于 systemd 先寫入配置，runc 后覆蓋寫入，此時(shí)容器的綁核信息最終保持正確。

執(zhí)行 systemd 相關(guān)發(fā)布操作（如 systemctl daemon-reload）時(shí)，會(huì)觸發(fā) systemd 再次寫入錯(cuò)誤的綁核信息，覆蓋原正確配置。多個(gè)容器因此綁定到相同 CPU 核，引發(fā)算力競(jìng)爭(zhēng)，業(yè)務(wù)無法獲得足夠資源導(dǎo)致超時(shí)，進(jìn)而觸發(fā)請(qǐng)求重試，最終表現(xiàn)為 CPU load 升高、業(yè)務(wù)服務(wù)異常。

本次故障排查跨越了 K8s、containerd、runc、systemd 多個(gè)組件，涉及內(nèi)核調(diào)度、容器綁核等底層邏輯。整個(gè)過程既驗(yàn)證了工具的價(jià)值，也沉淀了可復(fù)用的故障排查與運(yùn)維思路。

線上故障既是挑戰(zhàn)，也是優(yōu)化的契機(jī)。本次排查不僅解決了具體問題，也啟發(fā)了我們要打破“現(xiàn)象即原因”的思維定式，聚焦指標(biāo)關(guān)聯(lián)性分析， 同時(shí)要重視組件版本管理與 bug 追蹤，從源頭規(guī)避風(fēng)險(xiǎn)。

希望本文能給遇到類似問題的小伙伴們一些啟發(fā)。最后，感謝燒魚、kimi song 兩位同學(xué)在故障排查過程中給予的大力支持和幫助。

作者簡(jiǎn)介

YY，攜程高級(jí)云原生研發(fā)經(jīng)理，關(guān)注云原生技術(shù)相關(guān)；

licabbage，云原生研發(fā)工程師，關(guān)注單機(jī)性能優(yōu)化方向；

團(tuán)隊(duì)熱招崗位：資深云原生開發(fā)工程師（容器）