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）分類(lèi)，未設(shè)置 requests 的 Pod 被歸類(lèi)為 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)首先滿(mǎn)足 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ú)法滿(mǎn)足所有 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è)置資源類(lèi)似，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（至少滿(mǎn)足應(yīng)用基線需求），并確保節(jié)點(diǎn)資源充足。
- 關(guān)鍵 Pod 使用 Guaranteed 類(lèi)型。
總結(jié)
以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。
相關(guān)文章
Kubernetes教程之Windows?HostProcess?運(yùn)行容器化負(fù)載
這篇文章主要介紹了Kubernetes?Windows?HostProcess?運(yùn)行容器化負(fù)載,本篇內(nèi)容還是比較多的，總共包含了?Windows?HostProcess的創(chuàng)建、為?Windows?Pod?和容器配置?GMSA?和?Windows?的?Pod?和容器配置?RunAsUserName三大功能模塊，需要的朋友可以參考下2022-07-07
云原生技術(shù)kubernetes調(diào)度單位pod的使用詳解
這篇文章主要介紹了云原生技術(shù)kubernetes調(diào)度單位pod的使用詳解，幫助大家更好的理解和學(xué)習(xí)使用K8S，感興趣的朋友可以了解下2021-03-03
K8S中某個(gè)容器突然出現(xiàn)內(nèi)存和CPU占用過(guò)高的問(wèn)題及解決方案
當(dāng)K8S容器出現(xiàn)資源過(guò)載時(shí),可通過(guò)kubectl監(jiān)控定位問(wèn)題,調(diào)整資源限制,優(yōu)化應(yīng)用代碼,拆分多應(yīng)用容器,利用監(jiān)控工具排查,實(shí)施水平擴(kuò)展或遷移負(fù)載,確保集群穩(wěn)定運(yùn)行2025-07-07
k8s是一個(gè)輕便的和可擴(kuò)展的開(kāi)源平臺(tái),用于管理容器化應(yīng)用和服務(wù),通過(guò)k8s能夠進(jìn)行應(yīng)用的自動(dòng)化部署和擴(kuò)縮容,這篇文章主要介紹了k8s的架構(gòu)組成,需要的朋友可以參考下2024-05-05
這篇文章介紹了使用kubeadm部署多節(jié)點(diǎn)集群的方法，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2022-04-04
在Kubernetes中,通過(guò)創(chuàng)建ServiceAccount和RoleBinding,可以實(shí)現(xiàn)一個(gè)命名空間中的Pod掛載另一個(gè)命名空間中的Secret,以下是具體步驟和示例代碼,包括創(chuàng)建ServiceAccount、Role和RoleBinding,以及在Pod中使用這些資源掛載Secret,感興趣的朋友一起看看吧2025-03-03
Kubernetes環(huán)境部署Redis集群過(guò)程
在Kubernetes環(huán)境中部署Redis集群,推薦使用Redis7.0及以上版本;需配置cluster-announce-ip確保節(jié)點(diǎn)間穩(wěn)定通信;使用StatefulSet管理節(jié)點(diǎn)提供穩(wěn)定網(wǎng)絡(luò)標(biāo)識(shí)和持久化存儲(chǔ);配置l生檢查確保節(jié)點(diǎn)可用性2026-06-06
Kubernetes中使用PersistentVolume掛載云盤(pán)方式
這篇文章主要介紹了Kubernetes中使用PersistentVolume掛載云盤(pán)方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-02-02
云原生技術(shù)kubernetes之volumes容器的使用
這篇文章主要為大家介紹了云原生技術(shù)kubernetes之volumes容器使用方式，?有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2022-03-03
Kubernetes有狀態(tài)應(yīng)用管理StatefulSet使用詳解
這篇文章主要為大家介紹了Kubernetes有狀態(tài)應(yīng)用管理StatefulSet使用詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2022-11-11