作者｜炎尋
審核&校對：白玙
編輯&排版：雯燕

大家好，我是阿里云云原生應用平臺的炎尋，很高興能與大家繼續分享 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/activity/middleware/container-monitoring

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

總結

以上是生活随笔為你收集整理的系统架构面临的三大挑战，看 Kubernetes 监控如何解决？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。