k8s pod resources:{}設(shè)置的含義及說(shuō)明
一、resources: {} 含義
未聲明資源請(qǐng)求和限制:
當(dāng) Pod 的 resources 字段設(shè)置為 {},表示該 Pod 未聲明任何 CPU 和內(nèi)存的請(qǐng)求(requests)或限制(limits)。
- 無(wú)資源保障:Kubernetes 不會(huì)為該 Pod 保證任何 CPU 或內(nèi)存資源(即 requests 未定義)。
- 無(wú)資源上限:Pod 可以使用節(jié)點(diǎn)上剩余的 CPU 和內(nèi)存,但 不能超過(guò)節(jié)點(diǎn)的物理資源總量(即使未設(shè)置 limits,系統(tǒng)仍會(huì)通過(guò) QoS 策略限制其優(yōu)先級(jí))。
QoS 級(jí)別為 BestEffort:
根據(jù) Kubernetes 的服務(wù)質(zhì)量(QoS)分類,未設(shè)置 requests 的 Pod 被歸類為 BestEffort(最低優(yōu)先級(jí))。
- 優(yōu)先級(jí)最低:在資源不足時(shí),BestEffort Pod 會(huì)被優(yōu)先驅(qū)逐(OOM Killer 或調(diào)度器拒絕調(diào)度)。
- 僅使用剩余資源:只能使用節(jié)點(diǎn)上未被其他 Pod 的 requests 占用的資源。
二、不設(shè)置是可以無(wú)限使用機(jī)器資源嗎?
并不是。Pod 的資源使用仍受以下約束:
- 節(jié)點(diǎn)物理資源上限:Pod 的資源使用不能超過(guò)節(jié)點(diǎn)的 CPU 和內(nèi)存總量。
- 系統(tǒng)保留資源:Kubernetes 會(huì)為系統(tǒng)組件(如 kubelet、容器運(yùn)行時(shí))保留部分資源,剩余資源由 Pod 競(jìng)爭(zhēng)。
- 其他 Pod 的請(qǐng)求:設(shè)置了 requests 的 Pod 會(huì)優(yōu)先獲得其聲明的資源,剩余資源才會(huì)被 BestEffort Pod 使用。
那么,pod 資源使用有什么優(yōu)先級(jí)嗎?當(dāng)然有!
三、資源分配的優(yōu)先級(jí)規(guī)則
當(dāng)節(jié)點(diǎn)資源緊張時(shí),Kubernetes 根據(jù) QoS 級(jí)別 決定資源分配順序:
| QoS級(jí)別 | 定義 | 資源保障 | 優(yōu)先級(jí) |
|---|---|---|---|
| Guaranteed | requests == limits 且所有資源均被聲明 | 系統(tǒng)強(qiáng)制保障其 requests | 最高(優(yōu)先保護(hù)) |
| Burstable | requests < limits 或僅聲明 requests | 保障 requests,超出部分需競(jìng)爭(zhēng) | 中等(剩余資源可使用) |
| BestEffort | 未聲明任何資源(resources: {}) | 無(wú)保障 | 最低(可能被驅(qū)逐) |
具體分配邏輯:
優(yōu)先保障高 QoS Pod:
- 系統(tǒng)首先滿足 Guaranteed 和 Burstable Pod 的 requests 需求。
- 剩余資源由所有 Pod(包括 BestEffort)競(jìng)爭(zhēng)使用。
資源不足時(shí)的驅(qū)逐順序:
當(dāng)節(jié)點(diǎn)資源耗盡時(shí),Kubernetes 會(huì)優(yōu)先終止 BestEffort Pod(QoS 最低),以保障高優(yōu)先級(jí) Pod 的資源需求。
四、如何設(shè)置盡可能避免被驅(qū)逐
首先言明,任何一種QoS都有可能被驅(qū)逐。
| QoS 級(jí)別 | 驅(qū)逐順序 | 是否可能被驅(qū)逐 |
|---|---|---|
| BestEffort | 最先被驅(qū)逐 | 是(資源不足時(shí)優(yōu)先被終止) |
| Burstable | 在 BestEffort 之后驅(qū)逐,但 可能在極端情況下被驅(qū)逐 | 是(資源極度緊張時(shí)) |
| Guaranteed | 最后被驅(qū)逐,但并非絕對(duì)安全 | 是(極端情況下,如節(jié)點(diǎn)崩潰) |
具體邏輯如下:
BestEffort Pod:
- 優(yōu)先被驅(qū)逐,因?yàn)槠?QoS 級(jí)別最低,且無(wú)資源請(qǐng)求保障。
Burstable Pod:
在資源極度緊張(如節(jié)點(diǎn)內(nèi)存耗盡)時(shí),可能因超出 limits 或系統(tǒng)強(qiáng)制回收資源而被驅(qū)逐。例如:
- 如果 Pod 的內(nèi)存使用超過(guò) limits,會(huì)被 OOM Killer 終止。
- 當(dāng)節(jié)點(diǎn)資源完全耗盡(如內(nèi)存不足),Kubernetes 會(huì)按優(yōu)先級(jí)逐步驅(qū)逐 Pod。
Guaranteed Pod:
通常不會(huì)被驅(qū)逐,因?yàn)槠?requests == limits,系統(tǒng)會(huì)盡力保障其資源。但以下極端情況下仍可能被驅(qū)逐:
- 節(jié)點(diǎn)崩潰或硬件故障:如節(jié)點(diǎn)宕機(jī),所有 Pod 均會(huì)被終止。
- 資源總量不足:如果節(jié)點(diǎn)總資源(如 CPU 或內(nèi)存)無(wú)法滿足所有 Guaranteed Pod 的 requests(例如調(diào)度器誤調(diào)度),則可能觸發(fā)驅(qū)逐。
如上,Guaranteed最安全,只有節(jié)點(diǎn)崩潰情況下才會(huì)被驅(qū)逐,其次是Burstable,最不安全的是BestEffort,故要避免被驅(qū)逐,最好不要設(shè)置成BestEffort。
五、limits 和requests 的含義
- requests 是資源調(diào)度的“入場(chǎng)券”:決定 Pod 是否能被調(diào)度到節(jié)點(diǎn)。
- limits 是資源使用的“天花板”:防止 Pod 占用過(guò)多資源影響其他應(yīng)用。
- QoS 級(jí)別決定生存優(yōu)先級(jí):合理配置可避免資源爭(zhēng)搶和意外驅(qū)逐。
5.1、含義
requests(資源請(qǐng)求):
定義 Pod 運(yùn)行所需的最小資源保障。
- Kubernetes 調(diào)度器根據(jù) requests 確定 Pod 可調(diào)度到的節(jié)點(diǎn)。
- 節(jié)點(diǎn)必須提供至少 requests 指定的資源量,否則 Pod 無(wú)法調(diào)度到該節(jié)點(diǎn)。
- 作用:確保 Pod 啟動(dòng)時(shí)獲得基本資源,避免因資源不足崩潰。
limits(資源限制):
定義 Pod 允許使用的最大資源量。
- 當(dāng) Pod 資源使用超過(guò) limits 時(shí),Kubernetes 會(huì)通過(guò)限制或終止 Pod 防止資源濫用。
- 作用:防止 Pod 占用過(guò)多資源影響其他應(yīng)用。
5.2、不同設(shè)置的含義及影響
| 設(shè)置組合 | QoS 級(jí)別 | 含義與影響 |
|---|---|---|
| requests 和 limits 均設(shè)置 | Guaranteed | 資源保障:requests 和 limits 相等或 requests ≤ limits。 優(yōu)先級(jí)最高:資源不足時(shí)最后被驅(qū)逐。 示例:requests.cpu=1, limits.cpu=1 → 確保始終獲得 1 核 CPU。 |
| 僅設(shè)置 requests | Burstable | -資源保障:requests 定義最小資源,limits 未設(shè)置則默認(rèn)為節(jié)點(diǎn)最大資源。- 優(yōu)先級(jí)中等:資源不足時(shí)在 BestEffort 后驅(qū)逐。 示例:requests.memory=512Mi → 保證 512 MiB 內(nèi)存,但可使用剩余資源。 |
| 僅設(shè)置 limits | Burstable | - 不推薦:requests 未設(shè)置時(shí),requests 默認(rèn)為 0。 - 與未設(shè)置資源類似,QoS 級(jí)別為 Burstable,但資源保障不足。 |
| 均不設(shè)置 | BestEffort | - 無(wú)資源保障:僅在節(jié)點(diǎn)資源充足時(shí)使用剩余資源。 - 優(yōu)先級(jí)最低:資源不足時(shí)最先被驅(qū)逐。 |
5.3、哪些設(shè)置是有風(fēng)險(xiǎn)或者錯(cuò)誤的
未設(shè)置 requests:
Pod 可能因資源不足被調(diào)度到無(wú)法運(yùn)行的節(jié)點(diǎn)(例如節(jié)點(diǎn)內(nèi)存不足但未聲明 requests)。
limits < requests:
配置無(wú)效,Kubernetes 會(huì)以 requests 為準(zhǔn),limits 被忽略。
過(guò)度設(shè)置 requests:
可能導(dǎo)致節(jié)點(diǎn)資源碎片化,其他 Pod 無(wú)法調(diào)度。
未設(shè)置 limits:
Pod 可能占用過(guò)多資源,影響其他高優(yōu)先級(jí)應(yīng)用(如 Burstable Pod 的內(nèi)存無(wú)上限)。
5.4、 資源調(diào)度與驅(qū)逐規(guī)則
調(diào)度規(guī)則:
- 調(diào)度器確保節(jié)點(diǎn)的 總可用資源 ≥ 所有 Pod 的 requests 總和。
- 若節(jié)點(diǎn)資源不足,Pod 會(huì)被標(biāo)記為 Pending 直到資源可用。
資源使用與限制:
CPU:
- requests:Pod 可穩(wěn)定使用的 CPU 資源。
- limits:超過(guò) limits 時(shí)會(huì)被 CPU 限制(如降速)。
內(nèi)存:
- requests:Pod 可穩(wěn)定使用的內(nèi)存。
- limits:超過(guò) limits 時(shí)會(huì)被 OOM Killer 終止。
驅(qū)逐順序:
- BestEffort → 2. Burstable → 3. Guaranteed
- Guaranteed Pod 例外:若節(jié)點(diǎn)資源完全耗盡(如內(nèi)存不足),仍可能被
OOM Killer終止。
5.5、典型場(chǎng)景
| 場(chǎng)景 | 配置建議 | 說(shuō)明 |
|---|---|---|
| 關(guān)鍵服務(wù)(如數(shù)據(jù)庫(kù)) | requests == limits(Guaranteed) | 確保資源隔離,避免因資源波動(dòng)導(dǎo)致服務(wù)不穩(wěn)定。 |
| 普通應(yīng)用(如 Web 服務(wù)) | 設(shè)置 requests,并適當(dāng)設(shè)置 limits(Burstable) | 允許短暫超限,但防止資源濫用。 |
| 測(cè)試 Pod | resources: {}(BestEffort) | 僅用于低優(yōu)先級(jí)任務(wù),資源不足時(shí)可容忍終止。 |
5.6、最佳實(shí)踐
始終設(shè)置 requests:
- 確保 Pod 被調(diào)度到有足夠資源的節(jié)點(diǎn)。
合理設(shè)置 limits:
- 對(duì)關(guān)鍵服務(wù)設(shè)置 requests == limits(Guaranteed)。
- 對(duì)普通應(yīng)用設(shè)置 limits 防止資源濫用。
監(jiān)控資源使用:
- 使用 Prometheus 或 Metrics Server 監(jiān)控實(shí)際資源使用,調(diào)整配置。
避免過(guò)度聲明:
- 過(guò)度聲明 requests 會(huì)降低集群資源利用率。
5.7、常見(jiàn)問(wèn)題
Q1 :設(shè)置 requests 但未設(shè)置 limits 會(huì)怎樣?
- Pod 可使用節(jié)點(diǎn)上所有剩余資源(不超過(guò)節(jié)點(diǎn)物理限制),但無(wú)上限保護(hù)。
- QoS 級(jí)別為 Burstable,資源不足時(shí)可能因超限被 OOM Killer 終止。
Q2: limits 是否能超過(guò)節(jié)點(diǎn)資源?
- 否:limits 的總和不能超過(guò)節(jié)點(diǎn)的物理資源,否則 Pod 無(wú)法調(diào)度。
Q3: 如何避免 Pod 被驅(qū)逐?
- 設(shè)置合理的 requests(至少滿足應(yīng)用基線需求),并確保節(jié)點(diǎn)資源充足。
- 關(guān)鍵 Pod 使用 Guaranteed 類型。
總結(jié)
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
相關(guān)文章
Linux安裝Kubernetes(k8s)超詳細(xì)教程
Kubernetes是一個(gè)輕便的和可擴(kuò)展的開(kāi)源平臺(tái),用于管理容器化應(yīng)用和服務(wù),通過(guò)Kubernetes能夠進(jìn)行應(yīng)用的自動(dòng)化部署和擴(kuò)縮容,這篇文章主要給大家介紹了關(guān)于Linux安裝Kubernetes(k8s)的相關(guān)資料,需要的朋友可以參考下2024-07-07
使用k8tz解決pod內(nèi)的時(shí)區(qū)問(wèn)題(坑的解決)
時(shí)區(qū)的不一致,會(huì)帶來(lái)很多困擾。即使代碼與時(shí)區(qū)無(wú)關(guān),但容器日志與系統(tǒng)日志時(shí)間相關(guān)聯(lián)排查問(wèn)題也會(huì)讓人頭疼,這篇文章主要介紹了使用k8tz優(yōu)雅的解決pod內(nèi)的時(shí)區(qū)問(wèn)題,需要的朋友可以參考下2022-10-10
k8s暴露服務(wù)之Ingress環(huán)境部署實(shí)踐
文章介紹了如何部署ingress控制器ingress-nginx,包括下載部署文件、修改鏡像地址、上傳文件、應(yīng)用資源以及解決pod狀態(tài)異常的問(wèn)題2026-01-01
Podman開(kāi)機(jī)自啟容器實(shí)現(xiàn)過(guò)程及與Docker對(duì)比
這篇文章主要為大家介紹了Podman開(kāi)機(jī)自啟容器實(shí)現(xiàn)過(guò)程,通過(guò)示例代碼的形式進(jìn)行演繹過(guò)程,有需要的朋友可以參考下,希望可以有所幫助2021-09-09
常見(jiàn)Kubernetes kubectl命令使用詳解
這篇文章主要為大家介紹了常見(jiàn)Kubernetes kubectl命令使用詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-08-08

