牧場主今日工作

今天要來談談牧場最重要的管理制度 - 飼料分配！就像牧場主要控制每個區域的草料供應量，避免某些貪心的牛隻把所有飼料都吃光，讓其他牛隻餓肚子。在 Kubernetes 的世界裡，這個機制叫做 ResourceQuota，它能確保每個 Project 和 Namespace 都有合理的資源使用限制，維持整個叢集的和諧運作。

技術背景與概念

ResourceQuota 是 Kubernetes 中控制資源使用的核心機制，在 Rancher 的多租戶環境中更是不可或缺的管理工具。它就像是牧場的飼料配給制度，確保每個租戶都能獲得應有的資源，同時防止資源被某個租戶過度佔用。

重要觀念釐清

在開始實作前，有幾個重要觀念需要先釐清：

Reservation vs Limit 的差異：

• Reservation（保留）: 實際上就是 Kubernetes 的 request 概念，是調度器用來計算 Pod 應該部署到哪個 Node 的依據
• Limit（限制）: 是 Pod 實際能使用的最大資源量

重要提醒: Reservation 並不代表系統保證該 Project 至少能使用的資源！實際上填了 Reservation 也不一定用得到，因為可能被其他超過 Request 值的 Pod 佔用。如果某個 Node 上有一堆使用量超過 Request 的 Pod，新部署的 Pod 依然可能只能使用低於 Request 的用量。

為什麼 Project 和 Namespace 都要設定？
設定完 Project Resource Quota 後，一定要設定 Namespace 層級的限制，因為沒設定 Namespace 層級的話，Project 層級也就沒意義了。由於 Project Owner 角色一般不會開放給使用者，所以 Namespace 層級通常也是由 Admin 控管。

詳細實作步驟

1. Project 層級資源配額設定

登入 Rancher 管理介面，進入 Cluster > Projects/Namespaces，選擇要設定配額的 Project。

設定 Project Resource Quota

在 Project 設定中找到 Resource Quotas 頁籤：

# Project: backend-project (實際部門)
# Project: ml-project (範例，實際環境可能沒有 ML 部門)  
# Project: frontend-project (範例，實際環境可能沒有 Frontend 部門)

在 Rancher 網頁介面的設定步驟：

1. CPU 配額設定：

   • CPU Reservation: 2000m (不填寫 CPU Limit)
   • 這代表該 Project 總共的 CPU Request 調度參考值為 2 CPU cores

2. Memory 配額設定：

   • Memory Limit: 8000MiB (不填寫 Memory Reservation)
   • 這代表該 Project 總共最多可以使用 8GB 記憶體

3. Storage 配額設定：

   • Storage Reservation: 10000MiB (昨天已設定過)
   • 這代表該 Project 總共可以申請 10GB 儲存空間

2. Namespace 層級資源配額設定

Project 設定完成後，進入個別的 Namespace 進行細部配額設定。

建立 Namespace Resource Quota

進入個別 Namespace，點選 Resource Quotas → Create：

以下為設定範例（實際環境請依需求調整）：

development namespace 設定範例：

• CPU Reservation: 500m
• Memory Limit: 2000MiB
• Storage Reservation: 2000MiB
• 開發環境配額相對寬鬆

staging namespace 設定範例：

• CPU Reservation: 1000m
• Memory Limit: 4000MiB
• Storage Reservation: 4000MiB
• 測試環境需要模擬生產負載，資源配額應接近生產環境

production namespace 設定範例：

• CPU Reservation: 1000m
• Memory Limit: 4000MiB
• Storage Reservation: 4000MiB
• 生產環境配額，與 staging 保持一致以確保測試準確性

重要規劃原則：

• Project/Namespace Limit 必須比實際 Peak 用量高，因為有 Rolling Update 需求
• 建議採用 GitOps 自動化機制管理配額，避免人工管理的複雜度
• 需要提到 reservation 就是 request 的概念

3. 設定 Container 預設資源限制

在 Namespace 中點選 Limit Ranges → Create，設定容器的預設資源：

Container 預設設定：

• Default CPU Limit: 10m (預設極小值，主要滿足必填要求)
• Default Memory Limit: 1000MiB
• Default CPU Request: 10m
• Default Memory Request: 100MiB (可選)

這樣所有部署到該 Namespace 的 Pod 如果沒有明確指定資源限制，就會自動套用這些預設值。

重要設定說明：

• CPU 填 10m 主要是滿足必填要求，不設定過高的 CPU Limit
• Memory Request 可選，但建議設定合理值
• 所有數值都要遵守上述 Project 和 Namespace 的配額限制

踩雷經驗分享

資源配額常見問題

問題 1: Reservation 誤解
很多人以為設定了 Reservation 就保證能使用那麼多資源，實際上 Reservation 只是調度參考。如果 Node 上其他 Pod 用量超標，你的 Pod 一樣可能資源不足。

問題 2: 忘記設定 Namespace 層級
只設定 Project 層級配額是沒用的，一定要設定到 Namespace 層級才會真正生效。這是最常見的設定錯誤。

問題 3: Rolling Update 資源不足
配額設定得剛好夠用，結果 Rolling Update 時因為需要同時存在新舊 Pod 而資源不足，導致部署失敗。配額設定時要把 Rolling Update 需要的額外資源計算進去，不能只設定單一 Pod 需要的量。

問題 4: 自動化管理缺失
手動管理多個租戶的配額設定非常麻煩，特別是當部門數量增加時。強烈建議導入 GitOps 自動化機制。

驗證與測試

監控資源使用情況

Cluster 層級監控：
在 Rancher 首頁可以看到 Cluster 整體資源用量，但要注意只有未被 Cordon 且具有 Worker Role 的 Node 資源才會被計算在內。

重要監控原則：

• Reservation 與 Usage 兩者取高者當作 Loading 比率
• 兩者都會影響集群可用資源量
• 考慮 system-reserved 等預留資源的影響

安全閾值建議：

# 資源充足環境
安全閾值: 60%  # 保留充足的 Rolling Update 和 Peak 需求空間

# 資源緊張環境  
最高閾值: 70%  # 超過此閾值就要考慮擴容

# 避免的危險閾值
危險閾值: 85%  # 地端環境擴容不易，此閾值過於緊繃

ResourceQuota 使用量檢查：
透過 Rancher 網頁介面檢查配額狀態，因為透過網頁建立的 ResourceQuota 通常不會知道具體的物件名稱。

重要備註：

• CPU 和 Memory 使用量高低看應用特性，需要根據實際監控數據調整
• 定期檢視配額使用狀況，避免過度保守或寬鬆的設定

今日總結與明日預告

今天完成了 ResourceQuota 資源配額的全面設定，建立了完整的多租戶資源管理制度。記住 Reservation 只是調度參考，不是資源保證；Project 設定後必須配套設定 Namespace 層級才會生效。

明天我們要先來認識 Cilium CNI 網路魔法師，了解 CNI 的運作原理和設定，為後續的 Network Policy 網路隔離打好基礎！

💡 牧場主小提示：資源配額就像牧場的飼料分配制度，設定太嚴格會餓死牛隻，太寬鬆會浪費資源！建議先從寬鬆的配額開始，觀察一週的使用模式後再逐步收緊。記住：Reservation 是「調度參考值」，Limit 是「最多能用的」，別搞混了！