容器化 RDS：借助火焰圖定位Kubernetes性能問題

發布時間：2020-08-08 21:38:32 來源：ITPUB博客閱讀：191 作者：沃趣科技欄目：云計算

容器化RDS系列文章：

容器化RDS：計算存儲分離架構下的“Split-Brain”
容器化RDS：計算存儲分離還是本地存儲？
容器化RDS：你需要了解數據是如何被寫"壞"的
容器化RDS：借助 CSI 擴展 Kubernetes 存儲能力

借助 CSI（Container Storage Interface），加上對 Kubenetes 核心代碼的少量修改，可以 out-tree 的方式高效且低耦合的方式擴展 Kubenetes 存儲管理子模塊。

如《 容器化 RDS：借助 CSI 擴展 Kubernetes 存儲能力 》介紹，以 out-tree 方式添加 PVC 擴容（Resize）特性。

從可執行程序到可用編程產品，還需要設計結合業務需求的性能基準測試，并對發現的性能瓶頸進行優化。

經驗數據表明，相同功能的編程產品的成本，至少是已經過測試的程序的三倍。 ——人月神話

本文將分享性能基準測試的優化案例：

發現性能瓶頸
確定問題組件
借助 CPU Profile 和 Flame Graph，快速縮小范圍，定位到問題 code-path
有針對的優化

| 發現性能瓶頸

測試用例：

批量創建100個讀寫模式為RWO，容量為1GiB 的 PVC

期望測試結果：

180秒內全部創建成功并無報錯

所有的編程人員都是樂觀主義者，畢竟在可能出現問題的地方，一定都會遇到問題，在耗時 3600 秒后，95% 的 PVC 處于 Pending 狀態，嚴格的說，在批量創建的場景，該功能不可用。

容器化 RDS：借助火焰圖定位Kubernetes性能問題

大量 PVC 處于 Pending 狀態

| 定位問題組件

由于涉及組件眾多：

kube-apiserver
kube-controller-manager
kubelet
external-provisioner
external-attacher
csi-driver
qcfs-csi-plugin

組件之間調用復雜，再加上無處不在的協程（goroutine），如果直接查看日志或是 debug code 定位問題，猶如大海撈針，更不要說定位性能瓶頸。所以，首要工作是先定位到問題組件。

在測試過程中，我們記錄了所有組件和系統的資源使用情況，運氣不佳，從 CPU 使用情況，內存使用情況，網絡 I/O 和磁盤 I/O 來看都沒有異常數據。

通過梳理存儲管理相關組件的架構圖：

容器化 RDS：借助火焰圖定位Kubernetes性能問題

架構圖

以及業務流程的梳理，kube-controller-manager、external-provisioner 和 csi-driver 嫌疑較大。

通過 kubelet logs 查看日志，可以在 external-provisioner 中發現可疑日志：

I0728 19:19:50.504069    1 request.go:480] Throttling request took 192.714335ms, request: POST:https://10.96.0.1:443/api/v1/namespaces/default/events
I0728 19:19:50.704033    1 request.go:480] Throttling request took 190.667675ms, request: POST:https://10.96.0.1:443/api/v1/namespaces/default/events

external-provisioner 訪問 kube-apiserver 觸發限流

external-provisioner 有重大嫌疑。

| 定位問題 code-path

我們可以立馬進入調試環節：

閱讀 external-provisioner 代碼，加入調試日志，理解邏輯
不斷縮小 code-path

步驟 1、2持續迭代，直到最終定位到問題函數，這是非常有效的辦法。

或者采用 CPU profile：

采集堆棧樣本
找到在采樣手氣內消耗 CPU 時間比率最高的函數，把該函數作為調試的起點

相比上一種，更高效的縮小問題的范圍，節省更多的時間。

借助模塊“net/http/pprof”，對 external-provisioner 進行 60 秒的 CPU 采樣，可以獲得如下信息：

生成堆棧使用百分比排序：

容器化 RDS：借助火焰圖定位Kubernetes性能問題

函數的調用關系以及采樣周期內 CPU 耗時百分比：

容器化 RDS：借助火焰圖定位Kubernetes性能問題

針對“net/http/pprof”稍微啰嗦幾句：

提供 CPU profile 和 Heap profile；
在采樣時獲得堆棧(幾乎所有)信息, 以此為依據估算整個采樣周期內堆棧的CPU占用百分比, 并不是 100% 準確；
采樣成本并不低，100赫茲既可以采樣夠用的堆棧信息，又不會給應用程序帶來過大開銷；
CPU 采樣頻率默認為 100 赫茲，并硬編碼到模塊中, 不建議調到 500 赫茲以上。

網上已經有大量的相關文章，這里不贅述。

配合獲取的 CPU profile 信息生成火焰圖（Flame Graph）：

容器化 RDS：借助火焰圖定位Kubernetes性能問題

這里針對火焰圖再啰嗦下：

借助第三方工具 go-torch 繪制
每個矩形代表一個堆棧，采樣時間內，CPU 占用百分比越高 Y 軸越長，X 軸表明了堆棧之間的調用關系
從左到右按照字母表排序
顏色隨機選擇，無具體含義

網上已經有大量的相關文章，這里不贅述。

可以發現函數 addClaim 和 lockProvisionClaimOperation 的 CPU 占用比率達到 36.23%。

容器化 RDS：借助火焰圖定位Kubernetes性能問題

來自于 external-provisioner 調用的第三方模塊 kubenetes-incubator/external-storage

所以，只要引用例如了模塊 Kubenetes-incubator/external-storage 實現卷創建功能，都可以復現 api throttling。

再針對性的加入調試日志到 code-path 中，理解邏輯，很快可以確定問題：

在創建卷時，external-storage 需要訪問 API 資源（譬如 configmap、pvc、pv、event、secrets、storageclass 等），為減少 kube-apiserver 工作負荷，不建議直接訪問 kube-apiserver，而應該利用本地緩存（由 informer cache 構建）。但 external-storage 恰好直接訪問 kube-apiserver。通過下圖可以看到，有18.84%的采樣時間在 list event，這是導致 api throttling 的原因。

容器化 RDS：借助火焰圖定位Kubernetes性能問題

進一步分析，之所以有大量的 list event 是因為 Leader Election 的 Lock 實現粒度太細導致鎖搶占嚴重。生產環境中，一個組件會啟動多個實例，搶占到 Leader Lock 的實例即為 Leader 并對外提供服務，其他實例以 Slave 模式運行，一旦 Leader 出現問題，Slave 發現 Leader Lock 在租期內沒有更新即可發起搶占成為新的 Leader 并接管服務。這樣不僅提升了組件的可用性也避免了可能帶來的 data race 問題。所以可以理解成是一個組件實例一把鎖，并且只在 Leader 和 Slave 角色切換時才會重新選主，但 external-storage 原意為了提升并發度，運行多個實例同時為 Leader 提供服務，可以簡單理解成一個 PVC 一把鎖，100 PVC 就意味著多個實例要最少發生100次的 Lock 搶占。

最終定位到問題原因：

Lock 的搶占導致 api throttling，引發 Lock 搶占 timeout，timeout 后搶占重試，進一步惡化 api throttling。

從下圖可以進一步得到驗證，有 8.7% 的采樣時間在進行 Leader Election。

容器化 RDS：借助火焰圖定位Kubernetes性能問題

| 解決問題

一旦發現問題的根源，解決它反而是件不難的事情。后面針對該問題做了修復：

采用 sharedinformer cache
修改 Leader Lock 粒度

再次生成運行，可以發現函數 addClaim 和 lockProvisionClaimOperation 的 CPU 占用百分比下降到 13.95%。

容器化 RDS：借助火焰圖定位Kubernetes性能問題

external-provisioner 日志中的 throttling 關鍵字消失

100 PVC 的時間縮短到60秒以內全部創建成功，無任何報錯。

| 結語

對于終端用戶而言，交互的界面越來越簡單，但對于開發者而言，組件越來越多，編譯一次的時間越來越久，加上無處不在的并發，導致定位問題的難度越來越大，尤其是性能問題。所以，對體系架構的理解能幫我們快速鎖定問題組件，配合 Profile 工具和 Flame Graph 快速定位 code-path，再加上對業務邏輯的理解找到解決方案。

所有的編程人員都是樂觀主義者，無論是什么樣的程序，結果是勿庸置疑的："這次它肯定會運行。" 或者 "我剛剛找出了最后一個問題。" ——人月神話

| 作者簡介

熊中哲·沃趣科技聯合創始人

曾就職于阿里巴巴和百度，超過10年關系型數據庫工作經驗，目前致力于將云原生技術引入到關系型數據庫服務中。

向AI問一下細節

亚洲激情专区-91九色丨porny丨老师-久久久久久久女国产乱让韩-国产精品午夜小视频观看