成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

Kubernetes資源白吃型容器掃描實戰(zhàn):誰在浪費你的CPU和內(nèi)存?

云計算 云原生
在日常運維中,很多人喜歡盯著哪些 Pod 用資源最多,仿佛“高 CPU、高內(nèi)存”才是麻煩制造者。但我們這次的視角反過來了:我們關(guān)注的是——那些資源申請了一大堆,結(jié)果幾乎沒怎么用的容器!

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

責任編輯:武曉燕 來源: 幽靈代筆
相關(guān)推薦

2022-07-27 19:27:47

CPU資源內(nèi)存

2024-01-01 18:59:15

KubernetesCPU內(nèi)存

2014-01-07 14:29:14

HadoopYARN

2025-06-11 09:28:22

2018-03-15 08:25:53

2018-01-11 15:56:37

大數(shù)據(jù)中國城市未來發(fā)展

2017-12-25 09:39:07

Linuxbashparallel

2018-07-03 09:25:04

閑置云資源資金

2022-05-27 11:59:22

Linux內(nèi)存CPU

2024-11-14 08:00:00

2013-06-27 10:09:21

大數(shù)據(jù)

2016-01-11 10:07:27

容器Kubernetes

2009-07-07 09:51:38

過剩資源

2022-07-23 21:31:24

KubernetesLinux開源

2023-02-20 14:27:56

Kubernetes內(nèi)存單位

2022-03-22 08:52:40

KubernetesCPU內(nèi)存資源

2019-05-14 14:27:36

KubernetesDocker存儲

2014-08-15 10:33:57

編程效率項目經(jīng)理

2013-11-25 16:50:56

2015-08-04 10:26:44

OpenStackKubernetes容器管理
點贊
收藏

51CTO技術(shù)棧公眾號

主站蜘蛛池模板: 污视频免费在线观看 | 中国av在线免费观看 | 狠狠的干 | 韩日av在线| 日本成人一区二区 | 亚洲视频一区在线 | 91视频正在播放 | 麻豆久久久 | 网站黄色在线 | 欧美jizzhd精品欧美巨大免费 | 精品视频99| 超碰97免费观看 | 久草在线高清 | av毛片| 欧美一级特黄aaa大片在线观看 | 欧美三级在线 | 久久久成人免费一区二区 | 黄色三级免费 | 亚洲精品视频在线 | 国产精品久久福利 | 一区二区三区视频在线免费观看 | 久久久久国产一级毛片 | 国产欧美日韩综合精品一区二区 | a级在线观看 | 羞羞视频网页 | 天天干免费视频 | 中文一区| 高清一区二区三区 | 盗摄精品av一区二区三区 | 国产精品久久久久国产a级 欧美日韩国产免费 | 亚洲精品不卡 | 日本亚洲欧美 | 日韩精品一区二区在线 | 一区二区三区在线观看视频 | 一级黄色裸片 | 久久久久国产精品一区二区 | 精品www| 日本免费小视频 | 成人黄色a | 精品一区电影 | 日韩福利 |