今日目標

• 理解水平擴展（Scale-out）與垂直擴展（Scale-up）的差異與應用情境。
• 掌握 Kubernetes Horizontal Pod Autoscaler (HPA) 的工作原理與計算公式。
• 了解 Metrics Server 的角色：K8s 監控數據採集的基石。
• 實戰操作：啟用 Metrics Server、部署 HPA，並透過壓力測試工具實測 Pod 的自動水平擴展與收縮。

痛點場景：手動擴展為什麼跟不上流量暴增？

在電商促銷（如雙 11）、突發新聞推播或熱門活動開跑時，系統流量常常會在幾分鐘內暴增數倍。
如果依靠維運人員半夜手動執行 kubectl scale deployment --replicas=10：

1. 反應太慢：等到工程師收到告警、登入 VPN、下完指令，服務可能已經被流量打垮、使用者已經收到 504 Gateway Timeout。
2. 資源浪費：如果為了保險起見一直開著 10 個副本，在半夜離峰時段就會白白浪費昂貴的雲端主機算力。

Horizontal Pod Autoscaler (HPA) 就是為了解決這個問題：根據即時的 CPU 使用率、記憶體或自訂指標，自動、即時地調整 Deployment 的 Pod 副本數量！

HPA 的運作架構與核心公式

HPA 的運作依賴一個每 15 秒執行一次的控制循環（Control Loop）：

[ Pods CPU/Memory 消耗 ]
│
▼
[ Metrics Server 採集數據 ]
│
▼
[ HPA Controller 比對目標閾值 ]
│
▼
[ 自動調整 Deployment replicas 數量 ]

擴展副本數的計算公式

期望副本數 = 向上取整 [ 當前副本數 × ( 當前指標數值 / 目標指標數值 ) ]

• 舉例：目前有 1 個 Pod，目標 CPU 使用率設為 50%。當前實測 CPU 衝到了 200%，則期望副本數為：
  1 × (200% / 50%) = 4 個 Pod！

實戰演練：HPA 自動擴展與壓測

步驟 1：在 Minikube 啟用 Metrics Server

HPA 需要透過 Metrics Server 來取得 CPU 與記憶體數據。在 Minikube 中只需一行指令啟用：

minikube addons enable metrics-server

驗證 Metrics Server 是否已就緒（可能需要等待 30 秒至 1 分鐘）：

kubectl top nodes

如果能看到 Node 的 CPU 與 MEMORY 數據，代表指標採集正常！

步驟 2：建立具備資源限制的 Deployment

極重要前提：要讓 HPA 能正常運作，Pod 容器內部**必須明確宣告 resources.requests.cpu**，否則 HPA 無法計算使用率百分比！

建立 hpa-demo-app.yaml（使用一個會進行密集計算的 PHP Apache 應用）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  replicas: 1
  selector:
    matchLabels:
      run: php-apache
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
        - name: php-apache
          image: registry.k8s.io/hpa-example
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
spec:
  ports:
    - port: 80
  selector:
    run: php-apache

套用配置：

kubectl apply -f hpa-demo-app.yaml

步驟 3：建立 HPA 規則

我們設定 HPA 監控 php-apache：

• 最少副本數（Min）：1
• 最多副本數（Max）：5
• 目標平均 CPU 使用率：50%

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=5

查看 HPA 當前狀態：

kubectl get hpa php-apache

輸出預期：

NAME         REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   0%/50%    1         5         1          30s

步驟 4：執行壓力測試（模擬突發流量）

另開一個獨立的終端機視窗，啟動一個壓力測試 Pod，向 php-apache 發送密集無窮迴圈請求：

kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

步驟 5：見證自動擴展（Auto-scaling）奇蹟

回到原本的終端機，持續監控 HPA 與 Pod 的變化：

kubectl get hpa php-apache -w

你會看到即時的變化過程：

1. TARGETS 的 CPU 使用率開始飆升（例如衝到 250%/50%）。
2. HPA 觸發擴展，REPLICAS 自動從 1 ➔ 4 ➔ 5。
3. 查詢 kubectl get pods，你會發現 Kubernetes 已經在幾秒內自動為你開好 5 個 Pod 一起分擔流量！

步驟 6：停止壓測與自動冷卻收縮（Scale-down）

在壓測終端機按下 Ctrl + C 終止請求。

回到監控視窗，CPU 使用率會迅速降回 0%。

• 冷卻保護機制（Cooldown Period）：Kubernetes 預設會等待約 5 分鐘（Stabilization Window），確認流量真的平息而非暫時震盪後，才會逐步將 Pod 縮回 1 個副本，避免頻繁擴縮造成系統抖動（Flapping）。

本日小結

今天我們實作了 Kubernetes 最強大的核心功能之一：

• Metrics Server 負責採集集群運算指標。
• HPA 根據 CPU 負載公式動態計算，實現「秒級應對高峰、離峰自動省錢」的自動化彈性維運。

有了自動擴縮容之後，我們該如何統一收集成百上千個 Pod 產生的日誌？系統出問題時要去哪裡看視覺化圖表？

明天 Day 24，我們將學習全方位的可觀測性方案：「全方位可觀測性：Prometheus + Grafana 監控集群指標」！