本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

使用 Node Dashboard 視覺化 Kubelet 效能

作者：Zhou Fang (Google) |

自本文發表以來，節點效能儀表板已停用，不再可用。

此次停用發生在2019年初，作為 kubernetes/contrib 倉庫棄用的一部分。

在 Kubernetes 1.4 中，我們引入了一個新的節點效能分析工具，稱為節點效能儀表板，用於以更豐富的細節視覺化和探索 Kubelet 的行為。這項新功能將使 Kubelet 開發人員更容易理解和改進程式碼效能，並允許叢集維護人員根據提供的服務水平目標 (SLO) 設定配置。

背景

Kubernetes 叢集由主節點和工作節點組成。主節點管理叢集的狀態，而工作節點則實際執行和管理 Pod。為此，在每個工作節點上，一個名為 Kubelet 的二進位制檔案會監視 Pod 配置中的任何更改，並採取相應的操作以確保容器成功執行。Kubelet 的高效能，例如與新 Pod 配置收斂的低延遲和低資源使用率的高效內務管理，對於整個 Kubernetes 叢集至關重要。為了衡量這種效能，Kubernetes 使用端到端 (e2e) 測試來持續監控最新版本與新功能的基準變化。

Kubernetes SLO 由以下基準定義 :

* API 響應能力：99% 的所有 API 呼叫在不到 1 秒的時間內返回。
* Pod 啟動時間：99% 的 Pod 及其容器（使用預拉取的映象）在 5 秒內啟動。

在 1.4 版本釋出之前，我們僅在叢集級別衡量和定義了這些，這帶來了其他因素可能影響結果的風險。除此之外，我們還希望有更多與效能相關的 SLO，例如特定機器型別的最大 Pod 數量，以允許最大程度地利用您的叢集。為了正確地進行測量，我們希望引入一組僅限於節點效能的測試。此外，我們旨在從新測試中收集 Kubelet 更細粒度的資源使用情況和操作跟蹤資料。

資料收集

從 1.4 版本開始，節點特定的密度和資源使用測試現已新增到 e2e-node 測試集中。資源使用情況由獨立的 cAdvisor Pod 測量，以實現靈活的監控間隔（與 Kubelet 整合的 cAdvisor 相比）。效能資料，例如延遲和資源使用百分位，記錄在永續性測試結果日誌中。測試還記錄時間序列資料，例如 Pod 的建立時間、執行時間以及即時資源使用情況。Kubelet 操作的跟蹤資料記錄在其日誌中，並與測試結果一起儲存。

節點效能儀表板

自 Kubernetes 1.4 起，我們持續構建最新的 Kubelet 程式碼並執行節點效能測試。資料由我們的新效能儀表板收集，可在 node-perf-dash.k8s.io 獲取。圖 1 預覽了儀表板。您可以透過選擇測試開始探索，可以使用短測試名稱的下拉列表（區域 (a)）或逐一選擇測試選項（區域 (b)）。測試詳細資訊顯示在區域 (c) 中，其中包含來自 Ginkgo（Kubernetes 使用的 Go 測試框架）的完整測試名稱。然後選擇區域 (d) 中的節點型別（映象和機器）。

| | | 圖 1. 選擇要顯示在節點效能儀表板中的測試。 |

"BUILDS" 頁面顯示了不同構建的效能資料（圖 2）。這些圖表包括 Pod 啟動延遲、Pod 建立吞吐量以及 Kubelet 和執行時（目前為 Docker）的 CPU/記憶體使用情況。透過這種方式，可以輕鬆監控隨著新功能的簽入而隨時間變化的效能。

| | | 圖 2. 不同構建的效能資料。 |

比較不同的節點配置

比較不同配置之間的效能總是很有趣，例如比較不同機器型別、不同 Pod 數量的啟動延遲，或者比較託管不同數量 Pod 的資源使用情況。儀表板提供了一種便捷的方式來完成此操作。只需單擊測試選擇選單右上角的“Compare it”按鈕（圖 1 中的區域 (e)）。選定的測試將新增到“COMPARISON”頁面中的比較列表，如圖 3 所示。一系列構建的資料被聚合到一個值中，以方便比較並以條形圖顯示。

| | | 圖 3. 比較不同的測試配置。 |

時間序列和追蹤：深入探究效能資料

Pod 啟動延遲是 Kubelet 的一個重要指標，尤其是在每個節點建立大量 Pod 時。使用儀表板，您可以檢視延遲的變化，例如，當建立 105 個 Pod 時，如圖 4 所示。當您看到高度可變的線條時，您可能會認為這種差異是由於不同的構建造成的。然而，由於這些測試是針對相同的 Kubernetes 程式碼執行的，我們可以得出結論，這種差異是由於效能波動造成的。當我們比較構建 #162 和 #173 的 99% 延遲時，方差接近 40 秒，這是一個非常大的值。為了深入探究波動源，讓我們檢視“TIME SERIES”頁面。

| | | 圖 4. 建立 105 個 Pod 時的 Pod 啟動延遲。 |

具體來看構建 #162，我們能夠看到在 Pod 建立延遲圖（圖 5）中繪製的跟蹤資料。每條曲線都是已經到達某個跟蹤探針的 Pod 運算元量的累積直方圖。跟蹤 Pod 的時間戳要麼從效能測試中收集，要麼透過解析 Kubelet 日誌獲得。目前我們收集以下跟蹤資料

  • "create"（在測試中）：測試透過 API 客戶端建立 Pod；
  • "running"（在測試中）：測試監視 Pod 從 API 伺服器執行；
  • "pod_config_change"：Kubelet SyncLoop 檢測到 Pod 配置更改；
  • "runtime_manager"：執行時管理器開始建立容器；
  • "infra_container_start"：Pod 的基礎設施容器啟動；
  • "container_start"：Pod 的容器啟動；
  • "pod_running"：Pod 正在執行；
  • "pod_status_running"：狀態管理器更新執行中 Pod 的狀態；

時間序列圖表顯示狀態管理器更新 Pod 狀態需要很長時間（“running”的資料未顯示，因為它與“pod_status_running”重疊）。我們發現此延遲是由於 Kubelet 對 API 伺服器的每秒查詢數 (QPS) 限制（預設為 5）造成的。意識到這一點後，我們在其他測試中發現，透過增加 QPS 限制，“running”曲線逐漸與“pod_running”收斂，從而導致更低的延遲。因此，之前的 e2e 測試 Pod 啟動結果反映了 Kubelet 和上傳狀態時間的總延遲，Kubelet 的效能因此被低估了。

| | | 圖 5. 使用構建 #162 資料的時間序列頁面。 |

此外，透過比較構建 #162（圖 5）和構建 #173（圖 6）的時間序列資料，我們發現效能 Pod 啟動延遲波動實際上發生在更新 Pod 狀態期間。構建 #162 有幾個落後的“pod_status_running”事件，具有較長的延遲尾部。因此，它為未來的最佳化提供了有用的想法。

| | | 圖 6. 構建 #173 的 Pod 啟動延遲。 |

未來，我們計劃使用 Kubernetes 中具有固定日誌格式的事件來更方便地收集跟蹤資料。這樣，您無需提取現有日誌條目，即可在 Kubelet 內部插入自己的跟蹤探針，並獲取每個分段的細分延遲。

您可以在“TRACING”頁面中檢查不同構建之間任意兩個探針的延遲，如圖 7 所示。例如，透過選擇“pod_config_change”作為開始探針，並選擇“pod_status_running”作為結束探針，它給出了 Kubelet 在沒有狀態更新開銷的連續構建中的延遲方差。透過此功能，開發人員能夠監控 Kubelet 內部特定部分程式碼的效能變化。

| | | 圖 7. 繪製任意兩個探針之間的延遲。 |

未來工作

節點效能儀表板是一個全新的功能。它仍處於活躍開發中的 Alpha 版本。我們將持續最佳化資料收集和視覺化，為開發人員和叢集維護人員提供更多測試、指標和工具。

請加入我們的社群，幫助我們構建 Kubernetes 的未來！如果您對節點或效能測試特別感興趣，請加入我們的 Slack 頻道與我們聊天，或加入我們每週二太平洋時間上午 10 點舉行的 SIG-Node Hangout 會議。