一、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í)別 決定資源分配順序：

具體分配邏輯：

優(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ū)逐。

具體邏輯如下：

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è)置的含義及影響

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)景

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è)參考，也希望大家多多支持腳本之家。