Kubernetes資源白吃型容器掃描實戰(zhàn):誰在浪費你的CPU和內(nèi)存?
1. 背景:我們要找的不是“高消耗”,而是“低產(chǎn)能”
在日常運維中,很多人喜歡盯著哪些 Pod 用資源最多,仿佛“高 CPU、高內(nèi)存”才是麻煩制造者。但我們這次的視角反過來了:
我們關(guān)注的是——那些資源申請了一大堆,結(jié)果幾乎沒怎么用的容器!
說白了:你申請了 1 核 2G,結(jié)果只用了 20m、100Mi,這不就是“吃不完還拿一堆”的典型資源浪費?
這些資源申請過多但實際使用很少的容器,是拖累集群整體資源利用率的罪魁禍首——調(diào)度器認為節(jié)點沒資源,但其實有的是空間!
所以我們寫了一個腳本,專門找出這些“白吃型”容器,幫助我們優(yōu)化資源分配。
#!/bin/bash
OUTPUT_FILE="output.md"
# 寫入Markdown表頭
echo "| NAMESPACE | POD | CONTAINER | CPU_USED(m) | CPU_REQUEST(m) | CPU_LIMIT(m) | MEM_USED(Mi) | MEM_REQUEST(Mi) | MEM_LIMIT(Mi) |" > "$OUTPUT_FILE"
echo "| :- | :- | :- | :- | :- | :- | :- | :- | :- |" >> "$OUTPUT_FILE"
# 打印終端表頭
printf "%-20s %-40s %-30s %-10s %-15s %-15s %-15s %-15s %-15s\n" \
"NAMESPACE" "POD" "CONTAINER" "CPU_USED(m)" "CPU_REQUEST(m)" "CPU_LIMIT(m)" "MEM_USED(Mi)" "MEM_REQUEST(Mi)" "MEM_LIMIT(Mi)"
# 遍歷pods
kubectl get pods --all-namespaces --no-headers | awk '{print $1, $2}' | while read namespace pod; do
kubectl top pod "$pod" -n "$namespace" --containers --no-headers 2>/dev/null | while read -r pod_name container cpu_used mem_used; do
cpu_used_value=$(echo "$cpu_used" | sed 's/m//')
mem_used_value=$(echo "$mem_used" | sed 's/Mi//')
if [[ -z "$cpu_used_value" ]]; then
continue
fi
cpu_request=$(kubectl get pod "$pod" -n "$namespace" -o jsonpath="{.spec.containers[?(@.name==\"$container\")].resources.requests.cpu}" 2>/dev/null)
mem_request=$(kubectl get pod "$pod" -n "$namespace" -o jsonpath="{.spec.containers[?(@.name==\"$container\")].resources.requests.memory}" 2>/dev/null)
cpu_limit=$(kubectl get pod "$pod" -n "$namespace" -o jsonpath="{.spec.containers[?(@.name==\"$container\")].resources.limits.cpu}" 2>/dev/null)
mem_limit=$(kubectl get pod "$pod" -n "$namespace" -o jsonpath="{.spec.containers[?(@.name==\"$container\")].resources.limits.memory}" 2>/dev/null)
# cpu_request處理
if [[ "$cpu_request" == *m ]]; then
cpu_request_value=$(echo "$cpu_request" | sed 's/m//')
elif [[ -n "$cpu_request" ]]; then
cpu_request_value=$((cpu_request * 1000))
else
cpu_request_value=0
fi
# mem_request處理
if [[ "$mem_request" == *Mi ]]; then
mem_request_value=$(echo "$mem_request" | sed 's/Mi//')
elif [[ "$mem_request" == *Gi ]]; then
mem_request_value=$(echo "$mem_request" | sed 's/Gi//' | awk '{print $1 * 1024}')
else
mem_request_value=0
fi
# cpu_limit處理
if [[ "$cpu_limit" == *m ]]; then
cpu_limit_value=$(echo "$cpu_limit" | sed 's/m//')
elif [[ -n "$cpu_limit" ]]; then
cpu_limit_value=$((cpu_limit * 1000))
else
cpu_limit_value=0
fi
# mem_limit處理
if [[ "$mem_limit" == *Mi ]]; then
mem_limit_value=$(echo "$mem_limit" | sed 's/Mi//')
elif [[ "$mem_limit" == *Gi ]]; then
mem_limit_value=$(echo "$mem_limit" | sed 's/Gi//' | awk '{print $1 * 1024}')
else
mem_limit_value=0
fi
cpu_used_value=${cpu_used_value:-0}
mem_used_value=${mem_used_value:-0}
# 打印到終端
printf "%-20s %-40s %-30s %-10s %-15s %-15s %-15s %-15s %-15s\n" \
"$namespace" "$pod" "$container" "$cpu_used_value" "$cpu_request_value" "$cpu_limit_value" "$mem_used_value" "$mem_request_value" "$mem_limit_value"
# 同時追加到Markdown文件
echo "| $namespace | $pod | $container | $cpu_used_value | $cpu_request_value | $cpu_limit_value | $mem_used_value | $mem_request_value | $mem_limit_value |" >> "$OUTPUT_FILE"
done
done
echo "? 結(jié)果已保存到 $OUTPUT_FILE,并同步打印到了終端!"
2. 腳本干了什么?
我們這個腳本做的事情其實非常簡單、直接:
在所有命名空間中,掃描每個容器,只保留那些 CPU 和內(nèi)存實際使用量都低于它的資源 Request 和 Limit 的容器。
條件如下:
?CPU_USED < CPU_REQUEST 且 CPU_USED < CPU_LIMIT?MEM_USED < MEM_REQUEST 且 MEM_USED < MEM_LIMIT
只要滿足以上條件的容器,我們就認定它“吃不完”,并將其列入輸出報告中。
舉個例子
假設某個容器配置如下:
項目 | 數(shù)值 |
CPU Used | 35m |
CPU Request | 200m |
CPU Limit | 500m |
Mem Used | 90Mi |
Mem Request | 512Mi |
Mem Limit | 1024Mi |
這個容器看起來“沒啥問題”,但從資源角度,它就是個嚴重冗余:
?申請了 200m,結(jié)果只用了 35m,浪費超過 80%?內(nèi)存申請了 512Mi,結(jié)果只用了 90Mi,浪費近 83%
我們會把這個容器列出來,并記錄在 Markdown 表格中。
3. 輸出結(jié)果長什么樣?
我們輸出的數(shù)據(jù)像這樣:
NAMESPACE | POD | CONTAINER | CPU_USED(m) | CPU_REQUEST(m) | CPU_LIMIT(m) | MEM_USED(Mi) | MEM_REQUEST(Mi) | MEM_LIMIT(Mi) |
default | user-service-xxx | user-api | 35 | 200 | 500 | 90 | 512 | 1024 |
auth | token-service | signer | 10 | 100 | 200 | 50 | 256 | 512 |
每一行,都是一個“吃不完”的容器。
4. 我們?yōu)槭裁粗魂P(guān)注“使用 < 請求/限制”的?
Kubernetes 的調(diào)度邏輯是以 Request 值 為準的:
?你申請了 500m CPU,系統(tǒng)就預留給你這么多?哪怕你實際上只用 5m,別人也搶不到你這部分資源
所以,這些“吃不完”的容器,就是資源調(diào)度的黑洞:
?不會觸發(fā)報警?不會拖垮服務?但就是霸占資源,別的服務調(diào)不過來
定期找出這些容器,把 Request 降下來,能顯著提升集群整體可用資源量,從而:
?節(jié)省節(jié)點數(shù)量?降低成本?提升調(diào)度成功率
5. 實際收獲
我們在多個測試和生產(chǎn)集群中跑了腳本,得出了幾個有趣結(jié)論:
5.1 大量容器“吃不完”
?CPU 使用長期低于 50m,但申請卻是 500m 的服務比比皆是?內(nèi)存使用不足 100Mi,申請卻是 1G、2G 的也不少
這些服務配置基本可以砍一半都綽綽有余。
5.2 資源浪費并不等于性能好
很多團隊出于“保險”目的,習慣性給服務多申請點資源,但現(xiàn)實是:
多申請 ≠ 更穩(wěn)定,反而會阻塞別人用資源,降低集群整體健康度。
資源配太多,不但沒必要,還會讓 HPA 失效(因為看起來沒啥使用率變化)。
5.3 調(diào)整資源配置的真實效果
我們試著將幾個服務的資源 Request 按實際使用情況下調(diào)了 50%:
?節(jié)省節(jié)點數(shù)約 2 臺(每臺 16 核 64G)?新部署的服務調(diào)度成功率提升明顯?系統(tǒng)整體負載下降,擴容需求延后
6. 建議下一步怎么做?
以下是我們建議的實踐方案:
?定期執(zhí)行這個資源篩查腳本(每周一次即可)
加個 CronJob 或 Jenkins 任務,把結(jié)果郵件發(fā)給團隊。
?將輸出表格作為資源優(yōu)化依據(jù)
可以給開發(fā)負責人看,讓他們根據(jù)實際使用情況調(diào)整資源。
?把結(jié)果導入 Grafana/Excel 做可視化
更直觀地展示每個 Namespace 的資源浪費情況,有助于決策和資源管控。
7. 附:如何使用這個腳本?
?要求集群部署了 metrics-server[1]?腳本使用標準 kubectl 和 bash 語法,不依賴額外插件?輸出為 Markdown 表格,終端也會實時顯示
8. 總結(jié)一句話
真正拖慢你 Kubernetes 集群的,不是吃得太多的容器,而是那些“吃得太少還拿得多”的!
9. 小問答時間(Q&A)
?Q1:為什么資源使用小于 Request 和 Limit 也值得關(guān)注? ?? 因為這意味著資源配置過度了!雖然不會造成服務故障,但會導致集群資源浪費,影響其他 Pod 的調(diào)度甚至增加成本。
?Q4:要不要把資源配得很寬裕,以防突發(fā)流量? ?? 不推薦!可以使用 HPA(Horizontal Pod Autoscaler)來應對突發(fā)流量,而不是長期浪費資源。按需自動擴容才是現(xiàn)代云原生的正確打開方式。
References
[1] metrics-server: https://github.com/kubernetes-sigs/metrics-server