當我們剛把 search 部署進 Kubernetes 時，看起來一切都很順。
但如果仔細觀察：Pods 在 node 上隨機搶資源，沒有任何配額。
某個查詢量高的容器，可能一瞬間吃滿 CPU；
另一個 Pod 反而被擠到喘不過氣。

這樣的叢集，就像是辦桌沒分菜——有人吃三碗，有人連湯都沒喝到。
所以今天我們要加上 資源 Requests / Limits，讓 K8s scheduler 知道「要怎麼分飯給誰」。

改造版 Deployment

我們延續昨天的 deployment.yaml，
但這次多了一段關鍵設定：

# k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: search-deploy
  labels:
    app: search
spec:
  replicas: 2
  selector:
    matchLabels:
      app: search
  template:
    metadata:
      labels:
        app: search
    spec:
      containers:
      - name: search
        image: shirleychang/cloud-native-search:day26
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "100m"       # 至少留 0.1 core
            memory: "128Mi"   # 最小記憶體需求
          limits:
            cpu: "300m"       # 最多 0.3 core
            memory: "256Mi"   # 最多 256MB
        envFrom:
        - configMapRef:
            name: search-config
        - secretRef:
            name: search-secret
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
        livenessProbe:
          httpGet:
            path: /livez
            port: 8080

為什麼是這樣設定？

• requests 是 scheduler 依據的「保證額度」
  → 如果節點空間不足，K8s 不會排太多 pod 進去。
• limits 是容器的「天花板」
  → 超過限制時會被 Throttle 或 OOMKill。

可以用 kubectl describe pod 觀察實際分配結果。

實戰觀察指令

# 觀察 Pod 資源限制
kubectl get pod -l app=search -o custom-columns=NAME:.metadata.name,CPU_REQ:.spec.containers[*].resources.requests.cpu,CPU_LIM:.spec.containers[*].resources.limits.cpu

# 查看 node 資源使用
kubectl top nodes

# 查看 pod 資源使用
kubectl top pods -l app=search

深入理解：Scheduler 的決策邏輯

在 Kubernetes 裡，scheduler 會依據 requests 來排程 pod。
舉例：

所以如果不設定 requests，
Pod 看起來都能跑，但其實 scheduler 根本沒在控資源，
導致整台 node「表面正常、其實在超載」。

小測試：觀察 Throttling 行為

# 對 search-svc 壓測（以 hey 為例）
kubectl run hey --rm -it --image=rakyll/hey -- \
  -z 10s -c 5 "http://search-svc/search?q=python"

同時開另一個 terminal：

kubectl top pods -l app=search

你會看到：

• CPU 一直在 300m 附近 → 表示 limit 生效。
• 如果過度壓力 → logs 可能出現 slow request（因 throttle）。

為何不一開始就加 limit？

初期開發階段我們刻意「放開限制」，
讓每個模組自由跑，快速驗證功能正確。
但當系統穩定、要進入部署階段，就必須開始上鎖：
先正確，再穩定。

小結