Kubernetes 容量規劃 - 如何調整集羣的資源佔用
Kubernetes 容量規劃是基礎架構工程師必須面對的主要挑戰之一，因爲了解 Kubernetes 的資源要求和限制並非易事。
您可能預留了更多的資源，以確保容器不會用完內存或受到 CPU 限制。如果您處於這種情況，那麼即使不使用這些資源，也要向雲廠商付費，這也將使調度變得更加困難。這就是爲什麼 Kubernetes 容量規劃始終是集羣的穩定性和可靠性與正確使用資源之間的平衡。
在本文中，您將學習如何識別未使用的資源以及如何合理分配羣集的容量。
不要成爲貪婪的開發者
在某些情況下，容器需要的資源超出了限制。如果只是一個容器，它可能不會對您的賬戶產生重大影響。但是，如果所有容器中都發生這種情況，則在大型羣集中將產生幾筆額外費用。
更不用說 Pod 佔用資源太大，這可能需要你會花費更多的精力來發現佔用資源過多的問題。畢竟，對於 Kubernetes 來說，佔用資源過多的 Pod 調度起來相對困難。
介紹兩個開源工具來幫助您進行 Kubernetes 的容量規劃：
-
kube-state-metrics：一個附加代理，用於生成和公開集羣級別的指標。
-
CAdvisor：容器的資源使用分析器。
通過在羣集中運行這些工具，您將能夠避免資源利用不足並調整羣集資源佔用的大小。
如何檢測未充分利用的資源
CPU
CPU 資源佔用是最難調整的閾值之一，如果調整的太小可能限制服務的計算能力，如果調整的太大又會造成該節點多數計算資源處於空閒狀態。
檢測空閒 CPU 資源
利用給出的container_cpu_usage_seconds_total、kube_pod_container_resource_requests參數，可以檢測到 CPU 核心利用情況。
sum((rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[30m]) - on (namespace,pod,container) group_left avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="cpu"})) * -1 >0)如何識別那些命名空間浪費了更多的 CPU 內核
通過使用 PromQL 按名稱空間彙總過去的查詢，您可以獲得更細粒度的使用情況。通過這些信息，使您能夠向超大命名空間而且不充分利用資源的部門算賬。
sum by (namespace)((rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[30m]) - on (namespace,pod,container) group_left avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="cpu"})) * -1 >0)查找 CPU 佔用前 10 的容器
正如我們在 PromQL 入門指南中介紹的那樣，您可以使用該 topk 函數輕鬆獲取 PromQL 查詢的最佳結果。像這樣：
topk(10,sum by (namespace,pod,container)((rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[30m]) - on (namespace,pod,container) group_left avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="cpu"})) * -1 >0))內存
正確進行內存規劃至關重要。如果您內存使用率過高，則該節點將在內存不足時開始逐出 Pod。但是內存也是有限的，因此設置越好，每個節點可以容納的 Pod 就越多。
檢測未使用的內存
您可以使用container_memory_usage_bytes、kube_pod_container_resource_requests查看您浪費了多少內存。
sum((container_memory_usage_bytes{container!="POD",container!=""} - on (namespace,pod,container) avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="memory"})) * -1 >0 ) / (1024*1024*1024)在上面的示例中，您可以看到可以爲該集羣節省 0.8gb 的成本。
如何識別哪些命名空間浪費了更多的內存
就像我們使用 CPU 一樣，我們可以按命名空間進行聚合。
sum by (namespace)((container_memory_usage_bytes{container!="POD",container!=""} - on (namespace,pod,container) avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="memory"})) * -1 >0 ) / (1024*1024*1024)查找內存過大的前 10 個容器
同樣，使用該 topk 函數，我們可以確定在每個命名空間內浪費更多內存的前 10 個容器。
topk(10,sum by (namespace,pod,container)((container_memory_usage_bytes{container!="POD",container!=""} - on (namespace,pod,container) avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="memory"})) * -1 >0 ) / (1024*1024*1024))如何對容器的資源利用進行優化
在 Kubernetes 容量規劃中，要保留足夠的計算資源，您需要分析容器的當前資源使用情況。爲此，您可以使用此 PromQL 查詢來計算屬於同一工作負載的所有容器的平均 CPU 利用率。將工作負載理解爲Deployment、StatefulSet、DaemonSet。
avg by (namespace,owner_name,container)((rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[5m])) * on(namespace,pod) group_left(owner_name) avg by (namespace,pod,owner_name)(kube_pod_owner{owner_kind=~"DaemonSet|StatefulSet|Deployment"}))在上圖中，您可以看到每個容器的平均 CPU 利用率。根據經驗，可以將容器的 Request 設置爲 CPU 或內存平均使用率的 85％到 115％之間的值。
如何衡量優化的影響
在執行了一些 Kubernetes 容量規劃操作之後，您需要檢查更改對基礎架構的影響。爲此，您可以將未充分利用的 CPU 內核現在與一週前的值進行比較，以評估優化後的影響。
sum((rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[30m]) - on (namespace,pod,container) group_left avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="cpu"})) * -1 >0) - sum((rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[30m] offset 1w) - on (namespace,pod,container) group_left avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="cpu"} offset 1w )) * -1 >0)在上圖中，您可以看到優化之後，集羣中未使用的 CPU 更少了。
總結
現在您知道了貪婪的開發者的後果以及如何檢測平臺資源的過度分配。此外，您還學習瞭如何對容器的請求進行容量設置以及如何衡量優化的影響。
這些技巧應該是構建全面的 Kubernetes 容量規劃儀表板的良好起點，並獲得包含優化平臺資源所需的單一面板。
更多文檔請參考 [1][2][3][4]
參考資料
[1]
度量工具: https://github.com/kubernetes/kube-state-metrics
[2]
度量工具: https://github.com/google/cadvisor
[3]
PromQL: https://sysdig.com/blog/getting-started-with-promql-cheatsheet/
[4]
內存不足的錯誤: https://sysdig.com/blog/troubleshoot-kubernetes-oom/
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/nVVbScHHaynUr1csPr6Lag