前言
在 Kubernetes 的世界裡，自動擴縮容是維運人員的基本功。但你有沒有想過，除了傳統的 CPU / Memory 指標之外，能不能根據「外部事件」來動態調整 Pod 數量？這就是 KEDA（Kubernetes Event Driven Autoscaling） 要解決的問題。
我自己在專案中實際跑過 KEDA 搭配 Prometheus 的組合，這篇就來分享一下從安裝到設定的完整流程，順便把一些踩過的坑整理出來。
KEDA 是什麼？
簡單講，KEDA 是一個輕量級的 Kubernetes 元件，它讓你的工作負載可以根據外部事件來源（像是訊息佇列深度、HTTP 請求數、資料庫連線數等）進行自動擴縮。它跟原生的 HPA（Horizontal Pod Autoscaler）搭配運作，KEDA 負責從 0 到 1 的拉起，HPA 則接手 1 到 N 的橫向擴展。
KEDA 架構概覽（圖片來源：keda.sh）
KEDA 核心元件與事件驅動流程（圖片來源：devtron.ai）
安裝 KEDA
安裝方式很單純，透過 Helm 幾行指令就搞定。先把 KEDA 的 Helm repo 加進來：
helm repo add kedacore https://kedacore.github.io/charts
helm repo update接著直接安裝：
helm install keda kedacore/keda --namespace keda --create-namespace安裝完成後，KEDA 的 Controller 跟 Metrics Adapter 就會自動部署到你的叢集裡。
設定 ServiceMonitor（Prometheus 整合）
如果你的叢集有跑 Prometheus Operator，通常會需要一個 ServiceMonitor 來讓 Prometheus 知道要去哪裡抓指標。以下是一個範例：
| 欄位 | 值 | 說明 |
|---|---|---|
| apiVersion | monitoring.coreos.com/v1 | ServiceMonitor API 版本 |
| kind | ServiceMonitor | 資源類型 |
| metadata.name | my-app-monitor | 監控資源名稱 |
| spec.selector.matchLabels.app | my-app | 對應的 Service Label |
| spec.endpoints[0].port | http | 抓取指標的 Port 名稱 |
| spec.endpoints[0].path | /metrics | Metrics 端點路徑 |
| spec.endpoints[0].targetPort | 8081 | 實際目標 Port |
這樣 Prometheus 就會自動去你的應用程式抓 metrics 資料了。
建立 KEDA ScaledObject
核心來了。ScaledObject 是 KEDA 的 CRD，用來定義「根據什麼條件、擴縮哪個 Deployment」。以下是一個以 Prometheus 指標為觸發器的設定範例：
| 參數 | 範例值 | 用途 |
|---|---|---|
| scaleTargetRef.deploymentName | my-app | 要擴縮的 Deployment 名稱 |
| pollingInterval | 15（秒） | KEDA 檢查指標的頻率，預設 15 秒 |
| cooldownPeriod | 300（秒） | 縮容後的冷卻等待時間，預設 5 分鐘 |
| maxReplicaCount | 10 | 最大副本數上限 |
| triggers.type | prometheus | 使用 Prometheus 作為指標來源 |
| triggers.metadata.serverAddress | http://prometheus.monitoring:9090 | Prometheus 服務位址 |
| triggers.metadata.metricName | http_requests_total | 監控的指標名稱 |
| triggers.metadata.threshold | 100 | 觸發擴容的閾值 |
這邊特別提醒幾個重點：
- pollingInterval 不要設太短，不然 KEDA 會一直瘋狂查詢 Prometheus，對監控系統造成不必要的壓力。
- cooldownPeriod 建議依照你的業務場景調整，如果流量波動頻繁，可以適當縮短。
- threshold 的意義是「每個 Pod 平均承受的指標值」，不是總量，這點很多人搞混。
驗證 KEDA 是否正常運作
部署完成後，可以用以下指令確認一切就緒：
# 查看 ScaledObject 狀態
kubectl get scaledobject
# 檢查 KEDA Operator 日誌
kubectl logs -n keda -l app=keda-operator --tail=50
# 確認 HPA 有被自動建立
kubectl get hpa如果 ScaledObject 的狀態顯示 Active: True，而且對應的 HPA 也被成功建立，那就代表 KEDA 已經在正常監控你的指標了。接下來只要產生一些實際負載，就能觀察到 Pod 數量會根據指標自動增減。
小結
KEDA 最大的價值在於它把 Kubernetes 原生的 HPA 機制延伸到了「事件驅動」的維度。不管你是用 Prometheus、RabbitMQ、Kafka 還是 AWS SQS，都能透過 KEDA 的 Scaler 來串接。而且它支援 Scale to Zero 的特性，對於不需要常駐的工作負載來說，可以大幅節省資源成本。
如果你正在尋找一個彈性、輕量的自動擴縮方案，KEDA 絕對值得一試。
發佈留言