引言

在 Kubernetes 集群中，資源管理是確保應用穩定運行和集群高效利用的關鍵。其中，資源請求（Requests）作為資源管理的基礎機制，直接影響著 Pod 的調度決策和運行質量。

一、資源請求的基本概念

1.1 什么是資源請求

資源請求（Requests）是 Kubernetes 中定義 Pod 或容器所需最小資源量的聲明。在提供的示例中：

requests:cpu: 1memory: 2Gi

這表示該容器至少需要 1 個 CPU 核心和 2GiB 的內存才能正常運行。Kubernetes 調度器會使用這些值來決定將 Pod 放置在哪個節點上。

1.2 請求與限制的區別

與資源請求相對應的是資源限制（Limits），如示例中的：

limits:cpu: 2memory: 4Gi

兩者的主要區別在于：

• 請求(Requests)：是調度保證，確保 Pod 能夠獲得的最低資源量
• 限制(Limits)：是資源使用上限，防止 Pod 消耗過多資源

在調度階段，Kubernetes 只考慮 Requests；在運行時，Limits 則發揮作用防止資源饑餓。

二、CPU 請求的深入解析

2.1 CPU 請求的單位與含義

示例中的cpu: 1表示：

• 1 個 Kubernetes CPU 單位，相當于：
  • 1 個 AWS vCPU
  • 1 個 GCP 核心
  • 1 個 Azure vCore
  • 1 個超線程（在支持超線程的裸機上）

對于部分 CPU 核心，可以使用小數（如0.5）或毫核單位（如500m表示 500 毫核，即 0.5 個 CPU）。

2.2 CPU 請求的調度影響

當調度器看到cpu: 1的請求時，它會：

1. 檢查各節點的可分配 CPU 資源（總 CPU 減去已承諾的請求）
2. 只選擇至少有 1 個可用 CPU 單位的節點
3. 將該 CPU 單位"預留"給這個 Pod

2.3 CPU 請求與限制的關系

在示例中，CPU 請求為 1，限制為 2，這意味著：

• 調度保證：至少 1 個 CPU
• 運行上限：最多 2 個 CPU
• 突發能力：Pod 可以在需要時使用額外的 CPU 資源（最多 2 個），前提是節點上有可用資源

三、內存請求的深入解析

3.1 內存請求的單位與含義

示例中的memory: 2Gi表示：

• 2 gibibytes 的內存（1GiB = 1024^3 bytes）
• 也可使用其他單位如 MiB、KiB 等

3.2 內存請求的調度影響

與 CPU 類似，調度器會：

1. 檢查各節點的可用內存
2. 確保節點有至少 2GiB 的可分配內存
3. 將該內存"預留"給這個 Pod

3.3 內存請求的特殊性

內存與 CPU 的一個關鍵區別是：

• CPU 是可壓縮資源：當 Pod 超過請求但未達限制時，Pod 不會被殺死，只是會被限制
• 內存是不可壓縮資源：如果 Pod 超過內存限制，它將被 OOM Killer 終止

因此，合理設置內存請求尤為重要。

四、資源請求的實際應用場景

4.1 保證關鍵應用資源

對于關鍵業務應用，設置適當的請求可以確保：

• 始終有足夠的資源可用
• 不會被其他 Pod 的資源使用所影響
• 在節點資源緊張時獲得優先保障

4.2 提高集群利用率

通過合理設置請求：

• 管理員可以準確了解集群的資源承諾
• 實現更高效的裝箱（bin packing），提高資源利用率
• 避免資源浪費或過度配置

4.3 資源配額管理

在多租戶環境中，資源請求用于：

• 計算資源配額使用量
• 實施公平的資源分配策略
• 監控和限制各團隊/項目的資源消耗

五、設置資源請求的最佳實踐

5.1 如何確定合適的請求值

1. 基準測試：通過壓力測試確定應用的最小資源需求
2. 監控歷史數據：分析應用在正常負載下的資源使用情況
3. 考慮業務特點：
   • 周期性波動（如白天/夜間差異）
   • 突發流量處理能力需求
4. 安全余量：在最小需求上增加適當緩沖（通常 20-30%）

5.2 請求與限制的比例

常見的比例關系：

• CPU：請求:限制 = 1:2 或 1:1.5（如示例中的 1:2）
• 內存：請求:限制 = 1:1.2 或 1:1（內存突發收益小，風險高）

5.3 垂直自動擴縮(VPA)的考慮

雖然 VPA 可以自動調整資源，但：

• 生產環境建議謹慎使用自動調整請求
• 可先用于非關鍵應用
• 配合資源限制使用以避免失控

六、常見問題與解決方案

6.1 請求設置過高

癥狀：

• 集群利用率低
• 調度失敗（盡管實際資源足夠）

解決方案：

• 通過監控調整請求至更合理水平
• 考慮使用 VPA

6.2 請求設置過低

癥狀：

• Pod 頻繁被驅逐（內存不足）
• 應用性能不穩定

解決方案：

• 增加請求值
• 檢查應用是否有內存泄漏

6.3 節點壓力與資源請求

即使所有 Pod 都在請求范圍內，節點仍可能出現壓力，因為：

• 系統進程需要資源
• 容器運行時需要資源
• Kubelet 等組件需要資源

解決方案：

• 確保節點保留足夠資源給系統
• 設置適當的 kube-reserved 和 system-reserved

覺得有用的話點個贊 👍🏻 唄。
??????本人水平有限，如有紕漏，歡迎各位大佬評論批評指正！😄😄😄

💘💘💘如果覺得這篇文對你有幫助的話，也請給個點贊、收藏下吧，非常感謝!👍 👍 👍

🔥🔥🔥Stay Hungry Stay Foolish 道阻且長,行則將至,讓我們一起加油吧！🌙🌙🌙