在 Kubernetes 的世界裡，Pod 是資源消耗的最小單位。當整個叢集同時運行多個應用時，如何確保每個服務都能穩定獲得所需的資源？這就是「資源限制與 QoS（Quality of Service）」的重點所在。

一、為什麼要設定資源限制？

Kubernetes 叢集中的節點資源是有限的。如果不為 Pod 設定資源限制：

• 某些服務可能佔用過多 CPU 或記憶體；
• 其他服務會因此變慢甚至被系統殺掉；
• Cluster Autoscaler 也可能誤判實際需求。

這就像餐廳的桌位管理：如果不限制用餐時間與預約人數，最終大家都得不到好服務。

二、核心概念：Requests 與 Limits

| 名稱 | 定義 | 影響層面 |
|------|------|-----------|
| **Requests** | Pod 啟動時所需的最低資源量 | 決定 Pod 是否能被 Scheduler 安排到節點 |
| **Limits** | Pod 執行時允許使用的最大資源量 | 決定容器實際執行時的上限 |

2.1 CPU 與 Memory 行為差異

• CPU：超過 Limit 時不會被殺死，但會被 throttle（降低 CPU 使用率）。
• Memory：超過 Limit 時會直接觸發 OOMKill（容器被殺死）。

三、QoS（Quality of Service）類別

Kubernetes 會依據 Requests 與 Limits 的設定方式，為每個 Pod 分類不同的 QoS 等級：

| 類別 | 條件 | 優先權 | 特性 |
|------|------|----------|------|
| **Guaranteed** | 每個 Container 都設定相同的 `requests = limits` | 最高 | 資源最穩定，不易被驅逐 |
| **Burstable** | 至少設定了部分 requests 或 limits | 中等 | 有彈性但可被搶資源 |
| **BestEffort** | 都沒設定 | 最低 | 最容易被驅逐或 OOMKill |

💡 建議使用情境：

• 核心系統（DB、API Gateway）→ Guaranteed
• 一般應用 → Burstable
• 臨時測試或批次任務 → BestEffort

四、Pod Priority 與 Preemption

當叢集資源不足時，Kubernetes 會根據 PriorityClass 進行「排擠 (Preemption)」，讓高優先權的 Pod 先被排程。

4.1 建立 PriorityClass

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000
globalDefault: false
description: "High priority for core services"

4.2 在 Pod 中使用 PriorityClass

apiVersion: v1
kind: Pod
metadata:
  name: important-pod
spec:
  priorityClassName: high-priority
  containers:
  - name: nginx
    image: nginx

當資源不足時，Kubernetes 可能會驅逐低優先權的 Pod，以釋放空間給高優先權服務。

五、實作範例：觀察 QoS 與資源限制行為

5.1 建立 Namespace

kubectl create ns qos-demo

5.2 建立三種不同 QoS 類別的 Pod

(1) Guaranteed Pod

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
  namespace: qos-demo
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        cpu: "200m"
        memory: "100Mi"
      limits:
        cpu: "200m"
        memory: "100Mi"

(2) Burstable Pod

apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
  namespace: qos-demo
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        cpu: "100m"
        memory: "50Mi"
      limits:
        cpu: "300m"
        memory: "150Mi"

(3) BestEffort Pod

apiVersion: v1
kind: Pod
metadata:
  name: besteffort-pod
  namespace: qos-demo
spec:
  containers:
  - name: nginx
    image: nginx

5.3 驗證 QoS 類別

kubectl get pod -n qos-demo -o custom-columns=NAME:.metadata.name,QOS:.status.qosClass

預期輸出：

NAME              QOS
guaranteed-pod    Guaranteed
burstable-pod     Burstable
besteffort-pod    BestEffort

5.4 模擬資源壓力觀察行為

使用 stress-ng 模擬 CPU / 記憶體壓力：

kubectl run stress-test --image=alpine/stress --namespace qos-demo -- \
  stress --cpu 1 --vm 1 --vm-bytes 200M --timeout 60s

觀察：

• 哪些 Pod 被 OOMKill？
• 哪些仍持續運行？

六、結合 AI：資源監控與異常偵測

在 DevOps 結合 AI 的情境中，我們可以進一步：

• 使用 Prometheus + LLM（如 ChatGPT API） 自動分析 Pod 的資源異常；
• 例如偵測「requests 設太低導致 throttling」；
• 結合 Kubernetes Event Log + AI 進行預測性維運（Predictive Maintenance）。

範例：輸入過去 7 天的 CPU 使用率 log，AI 自動建議合理的 Requests 值，達到自動化調整與最佳化。

七、總結

在本篇中，我們深入了解了 Kubernetes 中如何透過資源設定與 QoS 機制，維持整體系統的穩定與彈性：

1. Requests / Limits 是資源調度的基礎，

   • Requests 決定 Pod 是否能順利排程；
   • Limits 決定實際執行階段的上限與保護機制。

2. QoS 類別（Guaranteed / Burstable / BestEffort）
   為不同型態的應用提供合適的穩定性與資源彈性策略。

3. PriorityClass 讓關鍵服務在資源競爭下依然能被優先保護，
   是大型叢集穩定營運不可或缺的一環。

4. AI 結合監控 可讓 DevOps 團隊從「被動修復」轉向「主動優化」，
   透過智能分析資源使用模式，預測瓶頸並自動化建議設定。