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

使用節點儀表板視覺化 Kubelet 效能

作者：Zhou Fang (Google) |

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

此停用發生在 2019 年初，是 kubernetes/contrib 儲存庫棄用的一部分。

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

背景

Kubernetes 叢集由 master 節點和 worker 節點組成。master 節點管理叢集的狀態，而 worker 節點執行運行和管理 Pod 的實際工作。為此，在每個 worker 節點上，一個名為 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 上舉行。