作者｜炎尋

稽核&校對：白璵

編輯&排版：雯燕

大家好，我是阿里云云原生應用平臺的炎尋，很高興能與大家繼續分享 Kubernetes 監控系列公開課。前兩期公開課我們講到了 Vol.1《通過 Kubernetes 監控探索應用架構，發現預期外的流量》、Vol.2《如何發現 Kubernetes 中服務和工作負載的異常》。

如何使用 Kubernetes 監控的拓撲來探索應用架構，使用產品採集的監控資料配置告警來發現服務效能問題。今天我們將進行第三講《使用 Kubernetes 監控發現資源使用，流量分佈不均勻的問題》，大家可以釘釘搜尋釘群 31588365，加入 Kubernetes 監控答疑群進行交流。

隨著 Kubernetes 的不斷實踐落地，我們經常會遇到越來越多問題，諸如負載均衡、叢集排程、水平擴充套件等問題。歸根到底，這些問題背後都暴露出流量分佈不均的問題。那麼，我們該如何發現資源使用，解決流量分佈不均問題呢？今天，我們就藉助三個具體場景聊聊這一問題以及相應的解決方案。

系統架構面臨的挑戰一：負載均衡

通常來說，對於一個業務系統，架構會有很多層，每層包含很多元件，比如服務接入、中介軟體、儲存，我們希望每個元件的負載都是均衡的，這樣效能和穩定性都是最高的，但在多語言多通訊協議場景下，快速發現以下問題具備一定難度，比如：

• 應用伺服器處理的請求是否均勻？
• 應用伺服器對中介軟體服務例項的訪問流量是否均勻？
• 資料庫各個分庫分表例項讀寫流量是否均勻？
• …

我們在實際工作實踐中會遇到的典型場景就是負載不均衡，線上的流量轉發策略或者流量轉發元件自身有問題，導致應用服務各個例項接收到的請求量不均衡，部分例項處理的流量顯著高於其他節點，導致這部分例項的效能相對於其他例項來說顯著惡化，那麼路由到這部分例項上的請求無法得到及時的響應，造成系統整體的效能和穩定性降低。

除了服務端不均勻場景之外，雲上使用者大多使用雲服務例項，在實踐中會出現應用服務各個例項處理的流量均勻，但訪問雲服務例項的節點出現流量不均勻，導致雲服務例項整體效能和穩定性下降。通常在應用執行時整體鏈路梳理和特定問題節點上下游分析時，會進入該場景。

那麼，我們如何快速發現問題、解決問題呢？

針對這一問題，我們可以從服務負載、請求負載這兩個方面對客戶端、服務端進行問題發現，判斷各個元件例項服務負載和對外請求負載是否均衡。

（1）服務端負載

對於服務端負載均衡問題排查，我們需要了解服務詳情，對任意特定的 Service，Deployment，DaemonSet，StatefulSet 進行更具針對性的排查。通過 Kubernetes 監控服務詳情功能，我們可以看到 Pod 列表部分會列出後端的所有 Pod，在表格中我們列出了每個 Pod 在選擇時間段內的請求數聚合值和請求數時序，通過對請求數一列進行排序，我們可以清楚地看到後端的流量是否均勻。

（2）客戶端負載

對於客戶端負載均衡問題排查，Kubernetes 監控提供叢集拓撲功能，對於任意特定的 Service，Deployment，DaemonSet，StatefulSet，我們都可以檢視其關聯的拓撲，當選定關聯關係之後，點選表格化會列出所有與問題實體關聯的網路拓撲，表格每一項都是應用服務節點對外請求的拓撲關係，在表格中我們會展示每一對拓撲關係在選擇時間段內的請求數聚合值和請求數時序，通過對請求數一列進行排序，可以清楚地看到特定節點作為客戶端對特定的服務端訪問是否流量均勻。

系統架構面臨的挑戰二：叢集排程

在 Kubernetes 叢集部署場景下，將 Pod 分發到某個節點的過程稱之為排程，對於每個 Pod 來說，其排程過程包含了“根據過濾條件找候選節點”以及“找最好的節點”兩個步驟，“根據過濾條件找候選節點”除了根據 Pod 和 node 的汙點，忍受關係來過濾節點，還有一點非常重要的就是根據資源預留的量來過濾，比如節點的 CPU 只有 1 核的預留，那麼對於一個請求 2 核的 Pod 來說該節點將被過濾。“找最好的節點”除了根據 Pod 和 node 的親和性來選擇，一般是在過濾出來的節點裡面選擇最空閒的。

基於上面的理論，我們在實踐過程中經常會遇到一些問題：

• 為什麼叢集資源使用率很低卻無法排程 Pod？
• 為什麼部分節點資源使用率顯著高於其他節點？
• 為什麼只有部分節點資源無法排程？
• …

我們在實際工作實踐中會遇到的典型場景就是資源熱點問題，特定節點頻繁發生 Pod 排程問題，整個叢集資源利用率極低但是無法排程 Pod。如圖，我們可以看到 Node1、Node2 已經排程滿了 Pod，Node3 沒有任何 Pod 排程上去，這個問題對跨 region 容災高可用，整體的效能都有影響。我們通常在 Pod 排程失敗會進入到該場景。

那麼，我們該如何處理呢？

對於 Pod 無法排程的問題排查，我們通常應該關注到下面三個要點：

• 節點有 Pod 數量排程上限
• 節點有 CPU 請求排程上限
• 節點有記憶體請求排程上限

Kubernetes 監控提供的叢集節點列表展示以上三個要點。通過排序去檢視各個節點是否均勻來檢視資源熱點問題。比如，某個節點 CPU 請求率接近 100%，那麼就意味著任何對 CPU 有請求的 Pod 都無法排程到該節點上，如果說只有個別節點的 CPU 請求率接近 100%，其他節點都十分空閒，就需要檢查一下該節點的資源容量和 Pod 分佈，進一步排查問題。

除了節點有資源熱點問題之外，容器也有資源熱點問題。如圖，對於一個多副本服務來說，其容器的資源使用分佈也可能有資源熱點問題，主要體現在 CPU 和記憶體使用上，CPU 在容器環境中是可壓縮資源，達到上限之後只會限制，不會對容器本身生命週期造成影響，而記憶體在容器環境中是不可壓縮資源，達到上限之後會出現 OOM，由於每個節點執行的時候雖然處理的請求量一致，但是不同請求不同引數導致的 CPU 和記憶體消耗可能不一樣，那麼這樣會導致部分容器的資源出現熱點，對生命週期和自動擴縮容都會造成影響。

針對容器的資源熱點問題，通過理論分析，我們需要關注的要點如下：

• CPU 是可壓縮資源
• 記憶體是不可壓縮資源
• Requests 用於排程
• Limits 用於執行時資源限制隔離

Kubernetes 監控在服務詳情的 Pod 列表展示以上四個要點，支援排序，通過檢視各個 Pod 是否均勻來檢視資源熱點問題，比如某個 Pod CPU 使用/請求率接近 100%，那麼就意味著可能觸發自動擴縮容，如果說只有個別 Pod 的 CPU 使用/請求率接近 100%，其他節點都十分空閒，就需要檢查處理邏輯，進一步排查問題。

系統架構面臨的挑戰三：單點問題

對於單點問題而言，其本質就是高可用問題。高可用問題解法只有一個，就是冗餘，多節點，多 region，多 zone，多機房，越分散越好，越冗餘越好。除此之外，在流量增長，元件壓力增大的情況下，系統各元件是否可以水平擴充套件也成為一個重要的議題。

單點問題，應用服務只有最多 1 個節點，當該節點因為網路或者其他問題中斷，無法通過重啟解決時，系統崩潰，與此同時，因為只有一個節點，當流量增長超過一個節點的處理能力時，系統整體的效能表現會嚴重惡化，單點問題會影響系統的效能和高可用能力，針對該問題，Kubernetes監控支援檢視 Service，Daemonset，StatefulSet，Deployment 的副本數，快速定位單點問題。

通過上面的介紹我們可以看到 Kubernetes 監控可以從服務端，客戶端多視角支援多語言多通訊協議場景下的負載均衡問題排查，與此同時容器，節點，服務的資源熱點問題排查，最後通過副本數檢查和流量分析支援單點問題排查。在後續的迭代過程中，我們會將這些檢查點作為場景開關，一鍵開啟之後自動檢查，報警。

目前，Kubernetes 監控免費使用中。點選下方連結，開啟 ARMS 即可使用。
https://www.aliyun.com/activi...

Kubernetes 監控答疑釘釘群（群號：31588365）