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

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

云計(jì)算 云原生
在日常運(yùn)維中,很多人喜歡盯著哪些 Pod 用資源最多,仿佛“高 CPU、高內(nèi)存”才是麻煩制造者。但我們這次的視角反過(guò)來(lái)了:我們關(guān)注的是——那些資源申請(qǐng)了一大堆,結(jié)果幾乎沒(mé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

責(zé)任編輯:武曉燕 來(lái)源: 幽靈代筆
相關(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ù)中國(guó)城市未來(lái)發(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

過(guò)剩資源

2022-07-23 21:31:24

KubernetesLinux開(kāi)源

2023-02-20 14:27:56

Kubernetes內(nèi)存單位

2019-05-14 14:27:36

KubernetesDocker存儲(chǔ)

2022-03-22 08:52:40

KubernetesCPU內(nèi)存資源

2014-08-15 10:33:57

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

2015-08-04 10:26:44

OpenStackKubernetes容器管理

2013-11-25 16:50:56

點(diǎn)贊
收藏

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

主站蜘蛛池模板: 天天干国产 | 91视频久久 | 国产精品夜夜夜一区二区三区尤 | 欧美日韩国产精品一区二区 | 一级免费毛片 | 欧美激情综合五月色丁香小说 | 欧美一级黑人aaaaaaa做受 | 久久久久久国产 | 91精品国产乱码久久久久久久久 | 成年人在线视频 | 久久99成人 | 欧美一级二级视频 | 成人国产一区二区三区精品麻豆 | 亚洲视频在线看 | 91国内精品久久 | 精品一区久久 | 久久国产精品无码网站 | 超碰人人在线 | 一区二区三区视频在线免费观看 | 精精国产xxxx视频在线播放 | 另类专区成人 | 欧美日韩高清免费 | 国产精品福利网站 | av中文字幕在线观看 | 自拍中文字幕 | 午夜影院普通用户体验区 | 91人人看| 欧美激情在线一区二区三区 | 一区二区成人在线 | 欧美性猛片aaaaaaa做受 | 在线免费观看毛片 | 国产精品一区二区三区久久 | 天堂av中文在线 | 免费在线视频精品 | 精品国产欧美一区二区 | 一本久久a久久精品亚洲 | 水蜜桃亚洲一二三四在线 | 精品亚洲视频在线 | 亚洲乱码一区二区 | 天天综合久久 | 精品一级电影 |