前言

寫這篇想要分享的重點：
在多用戶或複雜微服務架構下，如果沒有妥善約束容器的資源使用，某個程式的記憶體洩漏（Memory Leak）或 CPU 飆高可能會弄爆整個 Node 上的其他服務。本篇將介紹 Requests 與 Limits 的差別，並說明如何利用 LimitRange 與 ResourceQuota 在 Namespace 上做好資源防護網。

這篇想要講什麼：

1. CPU 與 Memory 資源設定：requests 與 limits 的意義、單位計算與排隊/OOM 處置機制。
2. LimitRange：為 Namespace 內未設定資源限制的容器自動加上「預設值」與「上下限檢查」。
3. ResourceQuota：控制整個 Namespace 可使用的總資源額度與物件數量上限。

為何要寫這篇：
缺乏資源約束的叢集就像沒有防火牆的系統，極易發生「鄰居污染（Noisy Neighbor）」問題。搞懂 K8s 資源配額與限制機制，能讓叢集資源利用率最大化，同時保障整體系統的穩定度。

名詞對應

• Namespace: 命名空間
• Request: 需求預留額
• Limit: 上限極限值
• Out Of Memory (OOM): 記憶體耗盡
• ResourceQuota: 資源配額
• LimitRange: 限制範圍

CPU 與 Memory 資源請求與極限

在 K8s Pod 的 spec.containers.resources 中，我們可以分別針對 CPU 與 Memory 指定 requests 與 limits：

resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"

1. 資源單位說明

• CPU：以核心數（Cores）為單位。
  • 1 代表 1 vCPU / 1 Core。
  • 250m 表示 250 millicores，即 0.25 個 Core。最小可接受設定為 1m。
• Memory：以位元組（Bytes）為單位。常用單位包含 Ki, Mi, Gi（基於 1024 轉算）。

2. Requests vs. Limits 差異與行為

命名空間單一容器監管：LimitRange

當忘記在 Pod YAML 中寫 resources 時，預設是可以無限使用 Node 資源的。LimitRange 的作用是在 Namespace 層級設定安全規則：

1. 自動預設值 (Default Requests / Limits)：如果 Pod 沒寫，自動套用預設限制。
2. 邊界檢查 (Min / Max)：限制單一 Pod 或 Container 所能設定的最大與最小資源量，防止有人設定過大的 Requests。

LimitRange 配置範例

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-mem-limit-range
  namespace: development
spec:
  limits:
  - default: # 預設 limits
      cpu: "500m"
      memory: "512Mi"
    defaultRequest: # 預設 requests
      cpu: "200m"
      memory: "256Mi"
    max: # 單一容器最大允許設定
      cpu: "1"
      memory: "1Gi"
    min: # 單一容器最小允許設定
      cpu: "100m"
      memory: "128Mi"
    type: Container

命名空間整體配額監管：ResourceQuota

如果說 LimitRange 針對的是「單一個體」，那麼 ResourceQuota 則是針對「整個 Namespace 的資源總量監管」。它能限制某個團隊（Namespace）最多能消耗多少 CPU/Memory，或者最多能建立多少個 Pod/Service/PVC。

ResourceQuota 配置範例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: development
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "10"
    limits.memory: 16Gi
    pods: "20"
    services.loadbalancers: "2"

⚠️ 重要概念： 一旦在 Namespace 啟用 ResourceQuota 限制總 CPU/Memory 額度，之後在該 Namespace 建立的每一個 Pod，都必須明確設定 requests 與 limits（或必須設定 LimitRange ），否則 API Server 會拒絕建立 Pod！(除錯要注意！)
💡 Namespace 在後面的章節會提到

總結

• 本篇總結：
  Pod 的 Requests 決定調度配額，Limits 決定安全上限；配合 LimitRange 的預設與 ResourceQuota 的 Namespace 額度控管，能確保叢集資源被高效且安全地分配。

• 下一篇預告：
  搞懂了容器資源控管後，明天 Day 09 我們將邁入 常駐服務與靜態 Pod 部署 (DaemonSet & Static Pods)——探討如何在每個 Worker Node 上自動運行日誌/監控元件，以及由 Kubelet 獨立管理的 Static Pods 運作機制！敬請期待！

Takeaway

• Requests vs. Limits 職責區分：requests 是 Scheduler 用來做節點分配與預留的依據；limits 則是容器執行的安全防護上限，不影響調度。
• 資源超額運行的代價：CPU 超過 Limit 只會觸發限速（Throttling）降速運行；Memory 超過 Limit 則會直接觸發 Linux OOM Killer 導致容器被強制終止（OOMKilled）。
• LimitRange 邊界護欄：用於 Namespace 層級，能自動為未宣告資源設定的 Pod 注入預設 Requests/Limits，並強制限制單一容器資源設定的上限與下限。
• ResourceQuota 總額管控：限制整個 Namespace 可消耗的 CPU/Memory 總總額與物件數量。一旦啟用，該 Namespace 內的所有 Pod 都必須明確宣告資源設定。