一、前言：為什麼要自動伸縮？

在雲端環境中，彈性伸縮（Autoscaling） 是確保系統穩定與成本效率的重要機制。
想像一個電商平台在雙十一活動期間流量暴增，若無法即時擴容，就可能導致服務延遲或當機；而在離峰時段若仍維持高資源配置，又會造成資源浪費。

在前一篇中，我們透過 LivenessProbe、ReadinessProbe、StartupProbe 讓系統能自我檢查與修復。
但「健康」只是第一步，接下來要讓系統能自我調整資源，才是真正的智慧化運維。

Kubernetes 提供了兩種主要的自動伸縮方式：

• HPA (Horizontal Pod Autoscaler)：透過增加或減少 Pod 數量來應對負載。
• VPA (Vertical Pod Autoscaler)：透過調整單一 Pod 的 CPU/記憶體配置來優化效能。

二、HPA 與 VPA 的概念比較

| 特性 | HPA (水平自動伸縮) | VPA (垂直自動伸縮) |
|------|--------------------|--------------------|
| 伸縮方向 | Pod 數量 | 單 Pod 的資源配置 |
| 控制依據 | CPU、Memory、Custom Metrics | 實際歷史資源使用量 |
| 適用場景 | 流量突增、可平行化的服務 | 長期負載趨勢變化或效能瓶頸 |
| 優點 | 反應快速、擴展容易 | 精準調整資源、不浪費 |
| 缺點 | 無法解決單 Pod 效能瓶頸 | 需要重啟 Pod、生效較慢 |

三、實作一：水平自動伸縮 HPA

1️⃣ 前置條件

• 已部署 metrics-server

  kubectl get deployment metrics-server -n kube-system

• 確保集群可收集 CPU/Mem metrics。

2️⃣ 建立範例 Deployment

建立一個簡單的服務作為測試目標：

hpa-demo.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hpa-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hpa-demo
  template:
    metadata:
      labels:
        app: hpa-demo
    spec:
      containers:
      - name: hpa-demo
        image: k8s.gcr.io/hpa-example
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 200m
          limits:
            cpu: 500m

套用：

kubectl apply -f hpa-demo.yaml

3️⃣ 建立 HPA 設定

kubectl autoscale deployment hpa-demo --cpu-percent=50 --min=1 --max=5

確認：

kubectl get hpa

⸻

4️⃣ 模擬負載測試

啟動一個負載產生器：

kubectl run -i --tty load-generator --image=busybox /bin/sh
# 進入容器後執行
while true; do wget -q -O- http://hpa-demo.default.svc.cluster.local; done

此時可觀察：

kubectl get pods -w

✅ 觀察結果：
當 CPU 使用率超過 50% 時，Pod 數量自動增加；負載減少時，Pod 數量會逐漸回縮。

四、實作二：垂直自動伸縮 VPA

1️⃣ 安裝 VPA 元件

VPA 不像 HPA 是預設存在的元件，需手動安裝：

kubectl apply -f https://github.com/kubernetes/autoscaler/releases/latest/download/vertical-pod-autoscaler.yaml

2️⃣ 建立範例 Deployment

可以沿用 HPA 的 Deployment，或建立一份新的：

vpa-demo.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vpa-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vpa-demo
  template:
    metadata:
      labels:
        app: vpa-demo
    spec:
      containers:
      - name: vpa-demo
        image: k8s.gcr.io/hpa-example
        resources:
          requests:
            cpu: 100m
          limits:
            cpu: 200m

3️⃣ 建立 VPA 設定
vpa.yaml

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-demo
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: vpa-demo
  updatePolicy:
    updateMode: "Auto"

套用：

kubectl apply -f vpa.yaml

4️⃣** 檢查推薦與調整結果**

kubectl describe vpa vpa-demo

你會看到類似：

Recommendation:
  Container Recommendations:
    Container Name:  vpa-demo
    Lower Bound:     100m
    Target:          300m
    Upper Bound:     500m

若 updateMode 為 Auto，Kubernetes 會自動重啟 Pod 並套用新建議。

五、實務建議與整合觀點

1. HPA 與 VPA 可並用，但要小心衝突

若 HPA 與 VPA 同時作用於同一個 Deployment，可能出現「彼此打架」的情況。

• 建議 HPA 控制 Pod 數量
• VPA 只負責 初始資源建議

設定 VPA 時可使用：

updatePolicy:
  updateMode: "Off"

以避免自動調整造成不預期的重啟。

2. 與監控整合（預告下一篇）

HPA 不只支援 CPU / Memory，還能與 Prometheus 整合使用 Custom Metrics，
例如根據「請求數量」、「佇列長度」、「延遲時間」等業務指標動態伸縮。

在下一篇，我將介紹如何利用 Prometheus + Grafana + Loki 建立完整觀測環境，
讓自動伸縮有更精準的依據。

3. 觀察與調整週期

HPA 與 VPA 的調整頻率、閾值設定應根據實際業務情境：

• HPA 適合秒級反應，例如 API 流量高峰。
• VPA 適合長期調整，例如服務平均資源需求的變化。

可透過歷史資料（如 Grafana Dashboard）觀察趨勢，再逐步調整。

六、結語

到目前為止，我們已經完成三個自動化層級：

1. Probe：確保容器健康
2. HPA / VPA：確保系統能自我調整
3. 下一篇 (Logging & Monitoring)：讓你能觀察並理解整個系統的狀況

透過這三篇的組合，我們正在打造一個能自我修復、自我調整、自我觀測的智慧 DevOps 生態系。