北京
導讀：近期，我們遇到了一個棘手的線上故障：在 K8s 集群宿主機執行 systemd 相關發布操作時，會觸發宿主機上的業務服務出現超時問題。
本文將完整復盤這一故障的排查全過程，從業務超時的異，F象切入，一步步抽絲剝繭，最終定位到runc 1.1.5 版本向 systemd 傳遞錯誤綁核信息這一根因。排查過程中，我們還會分享如何巧用 Perfetto、BPF 等工具捕捉關鍵線索，還原問題本質。無論你是 K8s 運維人員、容器技術愛好者，還是經常與線上故障 “過招” 的研發同學，都能從這份實戰案例中收獲排查思路與工具使用技巧，為日后解決同類問題提供可借鑒的參考。
關鍵詞：k8s, BPF, containerd, runc, systemd
一、故障的起因
二、排查過程
2.1 為什么 CPU Load 會升高？
2.2 為什么 CPU 使用率掉底了？
2.3 為什么綁核容器使用了同樣的 CPU？
2.4 Systemd 的錯誤參數是哪里來的？
三、總結與思考
故障的起因
在某次對 systemd 管理的組件進行變更后，觀測到服務出現大量超時。這些服務都是綁核的時延敏感型服務，所在機器的 cpu load 都顯著升高，這可能是造成業務超時的原因。
排查過程
2.1 為什么 CPU Load 會升高？
在故障發生的機器上，我們注意到 CPU load 明顯升高。
圖片為了復現問題，我們選取了一臺宿主機，排空上面的業務實例，并部署了 90 個 2 核的綁核容器用于模擬業務實例。對這 90 個容器發送請求，使得 cpu 利用率穩定在 50%，然后對這臺宿主機進行一次相同的變更。cpu load 并沒有像故障時那樣劇烈上升，但是我們卻發現了 cpu util 的異，F象：在本次變更后，cpu util 瞬間下降。下圖為我們在問題復現時的 cpu util 變化情況。
我們又重新看了下機器監控，發現在故障發生時，很多其他的指標也符合 cpu util 下降的表現，例如：
cpu idle time 上升
進程切換的次數下降
軟中斷的次數下降
我們意識到，cpu load 升高可能并不是業務超時的原因，而是結果。我們有一直往被測試的 Pod 打流量，按理說它們應該一直很繁忙猜對，為什么 CPU 使用率會下降呢？當時的 CPU 核上在做什么？
`2.2 為什么 CPU 使用率掉底了？
那么為何發布會導致 cpu 使用率掉底了？我們抓取了 cfs 的調度事件，想看看當時 CPU 上到底在跑什么，使用 perfetto 分析得到的數據如下：
可以看到，在發布后，某些核上的任務被切成 idle 了。這些容器都是綁核的容器，是一直有流量進來的，容器一直存活，為何這些核上的任務被切成 idle 了？
檢查了下容器的 cpuset.cpus，發現，在發布過后，一些不同的容器竟然綁定到了相同的核！
我們又對比了發布前容器拿到的 cpu 列表和 kubelet 分配的記錄，是一致的。
也就是說，在發布前，容器分配到的核與 kubelet 分配的記錄保持一致，符合預期。而在發布后，分配被打亂，有些容器使用了同樣的 CPU 列表。這就導致在這些 CPU 上排隊的線程數多了，cpu load 上升， 線程遲遲得不到調度，業務的延遲也上升。被空出來的 cpu 就處于 idle 狀態，所以整體的 cpu 使用率下降了。
2.3 為什么綁核容器使用了同樣的 CPU？
那么是誰改了容器的 cpuset.cpus，導致不同的綁核容器跑到了同樣的 cpu 核上 ？我們寫了一個 bpf 程序，通過埋點 linux 內核函數 cpuset_write_resmask ，監控是誰在修改 cpuset.cpus 文件。
發現在容器創建時，runc 和 systemd 都會去設置 cpuset.cpus 文件，其中 runc 直接寫入的 cpu 列表是 kubelet 分配的 cpu 列表，符合預期，而systemd 寫入的是錯的。
在容器創建時，執行順序上，systemd 會先寫入，runc 再后寫入，因此最終的結果是對的。發布通過 systemd 管理的組件時，會執行 systemd daemon-reload , 這會觸發 systemd 對賬，將它自己持有的配置數據同步到 cgroup , 從上圖我們可以看到它持有的配置數據是錯的，同步到 cgroup 后就導致不同的綁核容器使用同樣的 cpu 核了，這就是業務超時的原因。
2.4 Systemd 的錯誤參數是哪里來的？
systemd 設置 cpuset.cpus 的鏈路為“容器創建請求 -> kubelet -> containerd -> containerd-shim-runc-v2 -> runc -> systemd ->容器 cgroup 的 cpuset.cpus”
結合 bpf 程序的結果。我們可以發現，runc 拿到的是一個正確的參數，但是 systemd 卻得到了一個錯誤的參數，問題可能出現在 runc 傳給 systemd 的參數上。
該機器使用的 runc 版本是 v1.1.5，去查看了 runc 的 release log ，在 v1.1.6 中發現了相關的 bug-fix。
圖片于是我們將 runc 從 v1.1.5 升級到了 v1.1.6，再次進行實驗，發現錯誤綁核的問題不再發生。至此，我們將問題定位到了 runc v1.1.5 的 bug 上。
定位問題后，現在來詳解一些為何 runc 拿到的是正確的綁核信息，傳給 systemd 后就變成了錯誤的綁核信息。這里先貼一下該 bug-fix 的 PR https://github.com/opencontainers/runc/pull/3808/files
關鍵的代碼為：
} 這段代碼的邏輯是做一個反序操作，將 cpu 序號的二進制掩碼轉成 systemd 要求的順序，systemd 在這個 PR 里面做了對應的接口。
舉例來說，假設一個容器想要綁定的核是"0-3,12"，即 0 至 3 號核，以及 12 號核。
systemd 期望得到的信息是這樣的：
} 在 runc 的這個 bug-fix 之前，并沒有進行反序操作，因此 runc 給 systemd 的信息是這樣的
這就導致 systemd 拿到的 cpu 信息為 4 號核，以及 8 至 11 號核。
那為何會有不同容器綁定到一個核上？ 舉例來說，容器 A 想要綁定的是 8 號核與 10 號核，容器 B 想要綁定的是 16 號核與 18 號核。 Systemd 期望的參數是：
容器 A：
00000101 // 8 號以及 10 號核容器 B:
00000101 // 8 號以及 10 號核實際 runc 1.1.5 版本給 systemd 的信息分別是:
容器 A:
00000000容器 B:
00000000兩者都被 systemd 解析為需要 0 號核與 2 號核。
總結與思考
最后來總結下，本次故障的原因為：
容器創建時，systemd 拿到了錯誤的綁核信息，runc 拿到了正確的綁核信息，由于 systemd 先寫入配置，runc 后覆蓋寫入，此時容器的綁核信息最終保持正確。
執行 systemd 相關發布操作（如 systemctl daemon-reload）時，會觸發 systemd 再次寫入錯誤的綁核信息，覆蓋原正確配置。多個容器因此綁定到相同 CPU 核，引發算力競爭，業務無法獲得足夠資源導致超時，進而觸發請求重試，最終表現為 CPU load 升高、業務服務異常。
本次故障排查跨越了 K8s、containerd、runc、systemd 多個組件，涉及內核調度、容器綁核等底層邏輯。整個過程既驗證了工具的價值，也沉淀了可復用的故障排查與運維思路。
線上故障既是挑戰，也是優化的契機。本次排查不僅解決了具體問題，也啟發了我們要打破“現象即原因”的思維定式，聚焦指標關聯性分析， 同時要重視組件版本管理與 bug 追蹤，從源頭規避風險。
希望本文能給遇到類似問題的小伙伴們一些啟發。最后，感謝燒魚、kimi song 兩位同學在故障排查過程中給予的大力支持和幫助。
作者簡介
YY，攜程高級云原生研發經理，關注云原生技術相關；
licabbage，云原生研發工程師，關注單機性能優化方向；
團隊熱招崗位：資深云原生開發工程師（容器）
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
