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