2026 年 Kubernetes 自動擴縮容（KEDA & Karpenter）成本優化指南
盲區一：HPA 只能反應「已經發生」的負載。HPA 的運作邏輯是讀取 Metrics Server 的 CPU / Memory 數據，然後調整 Replica 數量。問題在於，CPU 使用率上升是「結果」而不是「原因」。當你看到 CPU 飆高時，請求已經開始堆積了。對於突發流量，HPA 的反應延遲通常在 30 秒到 2 分鐘之間，這段時間足以讓服務降級。
盲區二：HPA 無法 Scale to Zero。一個沒有請求的服務，HPA 還是會保留最少 1 個 Pod（因為 minReplicas 預設是 1）。對於那些每天只被呼叫幾次、甚至幾小時才被呼叫一次的排程型或事件型工作負載，這 1 個 Pod 就是純粹的浪費。而且這個浪費會乘以幾十個微服務，乘以 30 天。
盲區三：Cluster Autoscaler 是「節點群組」思維。Cluster Autoscaler 依賴自動擴展群組（ASG / MIG），每個群組綁定一種執行個體類型。這導致幾個問題：一，擴容時只能從預先定義的群組裡挑，無法根據當下最便宜的選擇來決定；二，縮容時必須整個節點排空，而且對「有狀態」或「有 PDB」的節點常常縮不掉；三，Spot 與 On-Demand 的混合策略難以精細控制。
這三個盲區，就是 KEDA 與 Karpenter 存在的理由。
1.3 KEDA 與 Karpenter 的角色分工
很多人第一次接觸這兩個工具時會搞混：它們是不是在搶同一件事？答案是否定的。用一句話區分：
兩者是互補的。KEDA 說「我現在需要 50 個 Pod」，Karpenter 就負責「好，那我馬上開三台 c7g.4xlarge，而且優先挑 Spot」。反過來，KEDA 說「現在只需要 2 個 Pod」，Karpenter 就會把空出來的節點收回。這種分工，構成了 2026 年最完整的成本優化鏈路。
二、KEDA 深度解析：事件驅動的極致縮容
KEDA 全名是 Kubernetes Event-driven Autoscaling，它是一個 CNCF 畢業專案（2023 年正式畢業）。它的核心價值，在於把「擴縮容的觸發條件」從 CPU / Memory 這種滯後指標，轉移到「事件來源」這種領先指標。
2.1 KEDA 架構與核心元件
KEDA 的架構相當輕量，主要由三個部分組成：
這裡有一個關鍵設計：KEDA 並不取代 HPA，而是與 HPA 協作。KEDA 會自動建立一個 HPA 物件，把外部指標餵給它，然後由 HPA 負責實際的 Replica 調整。這個設計的好處是複用了 Kubernetes 原生的擴縮容邏輯（包含擴容/縮容的穩定窗口），同時又突破了原生指標的限制。
# 檢查 KEDA 是否正常運作
kubectl get pods -n keda
kubectl get scaledobject -A
kubectl get hpa -A | grep keda
2.2 ScaledObject 與 ScaledJob 實戰
KEDA 提供兩種主要的工作模式，對應兩種截然不同的工作負載。
ScaledObject 用於「長時間運行」的服務，例如 API Server、消費者服務。它會在 0 到 N 之間調整 Replica。
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: order-consumer
namespace: production
spec:
scaleTargetRef:
name: order-consumer
minReplicaCount: 0 # 關鍵：允許縮到零
maxReplicaCount: 200
cooldownPeriod: 300 # 最後一個事件後 5 分鐘才縮到零
pollingInterval: 15 # 每 15 秒檢查一次事件來源
advanced:
horizontalPodAutoscalerConfig:
behavior:
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 50
periodSeconds: 60
triggers:
- type: aws-sqs-queue
metadata:
queueURL: https://sqs.ap-northeast-1.amazonaws.com/123456789/orders
queueLength: "10" # 每 10 個訊息擴一個 Pod
awsRegion: ap-northeast-1
authenticationRef:
name: keda-aws-credentials
ScaledJob 則用於「一次性任務」，例如影片轉檔、報表生成、批次 ETL。每個事件觸發一個獨立的 Job Pod，跑完就結束。這是成本優化上最暴力的模式——因為它真正做到「不用時，一個 Pod 都沒有」。
apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
name: video-transcoder
namespace: media
spec:
jobTargetRef:
parallelism: 1
completions: 1
backoffLimit: 3
template:
spec:
containers:
- name: transcoder
image: registry.example.com/transcoder:v3.2
resources:
requests:
cpu: "2"
memory: "4Gi"
pollingInterval: 10
maxReplicaCount: 100
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 3
triggers:
- type: redis
metadata:
address: redis.media.svc.cluster.local:6379
listName: transcode_queue
listLength: "1"
這種模式在大規模影音平台或資料工程團隊中非常常見。過去他們可能養著一批常駐的 Worker 節點，24 小時待命；現在改成 ScaledJob，只有真的有東西要處理時才開機器。
2.3 從零到零（Scale to Zero）的成本效益
Scale to Zero 是 KEDA 最性感的功能，但也是最容易被誤用的功能。它的價值有多大？我們來算一筆帳。
假設你有一個內部報表服務，每天被呼叫約 40 次，每次處理 20 秒。傳統做法是保留 2 個 Pod（為了高可用），每個 Pod request 0.5 CPU / 1Gi。這樣一來，這個服務每天消耗的資源是：2 Pod × 24 小時 × 0.5 CPU = 24 CPU-小時。而它真正需要的運算時間只有 40 × 20 秒 = 0.22 CPU-小時。浪費率超過 99%。
改用 KEDA + Scale to Zero 之後，這個服務在沒有請求時完全是 0 個 Pod、0 個節點資源。它的成本會降到幾乎為零，只在你真的呼叫它時才產生費用。
但要注意一個重要前提：冷啟動。縮到零之後，第一個請求會經歷「拉 Pod → 拉映像檔 → 啟動應用 → 通過 Readiness」的完整流程，這個時間可能是 5 秒到 60 秒不等。因此，Scale to Zero 適合的是：
可以容忍冷啟動的非同步任務（批次、排程、佇列消費）。
低頻但有突發性的內部工具。
開發 / 測試環境的所有服務（這個場景超適合，帳單直接砍 70%）。
而不適合的是：對延遲極度敏感的使用者端 API。對於這類服務，可以改用 minReplicaCount: 1 或 2，搭配較短的 cooldownPeriod，在成本與延遲之間取得平衡。
2.4 常見 Scaler 與觸發器配置
KEDA 在 2026 年已經支援超過 70 種 Scaler。以下是實務上最常用的幾類：
類別
Scaler
適用場景
關鍵參數
訊息佇列
aws-sqs-queue / rabbitmq / kafka / redis
非同步任務、事件消費
queueLength / lagThreshold
資料庫
postgresql / mysql / mssql
自建排程、報表服務
query / targetQueryValue
HTTP
metrics-api / prometheus
自訂業務指標
query / threshold
雲端監控
aws-cloudwatch / azure-monitor
混合雲指標
metricName / targetValue
時間排程
cron
定時擴容（上班時間）
start / end / desiredReplicas
其中 cron Scaler 值得特別一提。很多團隊的流量有明顯的「上班時間」特徵，例如早上 9 點到晚上 9 點是高峰，凌晨是低谷。你可以用 cron Scaler 在早上 8:30 就把 minReplicaCount 拉到一個基礎值，避免第一波流量來的時候還在冷啟動。這是一種「主動式」與「被動式」混合的策略。
triggers:
- type: cron
metadata:
timezone: Asia/Taipei
start: 0 30 8 * * * # 08:30 開始
end: 0 0 22 * * * # 22:00 結束
desiredReplicas: "10"
2.5 KEDA 的坑與調校技巧
實務上部署 KEDA 最常踩的坑，大概有以下幾個：
坑一：pollingInterval 太短，把事件來源打爆。預設是 30 秒，有些團隊為了「反應更快」改成 5 秒，結果 Redis 或 SQS 的 API 呼叫量暴增，反而產生額外費用（尤其是 CloudWatch 或 API Gateway 按次計費的服務）。建議維持 15 到 30 秒。
坑二：queueLength 設太小，Pod 數暴走。如果目標佇列長度是 10、佇列裡突然堆了 10000 個訊息，KEDA 會瞬間想要 1000 個 Pod。務必設定合理的 maxReplicaCount，並搭配 HPA 的 scaleUp 速率限制。
坑三：忘了設定 cooldownPeriod，導致縮容太快。有些工作負載是間歇性的，例如每 2 分鐘來一批。如果 cooldownPeriod 只有 30 秒，系統會不斷在「開 Pod → 關 Pod → 開 Pod」之間震盪，這個震盪本身就是成本。建議設 300 秒以上。
坑四：認證資訊管理不當。KEDA 需要存取外部事件來源，這些憑證要用 TriggerAuthentication 搭配 Secret 管理，千萬不要寫死在 ScaledObject 裡。
三、Karpenter 深度解析：節點級別的即時供給
如果說 KEDA 是「需求側」的優化，那 Karpenter 就是「供給側」的革命。它從根本上改變了 Kubernetes 叢集擴容的方式。
3.1 Karpenter vs Cluster Autoscaler 的根本差異
要理解 Karpenter 的價值，最好先理解 Cluster Autoscaler 的設計限制。Cluster Autoscaler 的運作模式是：
發現有 Pod 因為資源不足而 Pending。
查看這個 Pod 的 resource request。
從預先定義好的節點群組（ASG）中，選一個「能裝得下」的群組。
呼叫雲端 API 把該群組的 desired capacity 加一。
等待新節點加入叢集。
這個流程有幾個問題。第一，它受制於「節點群組」這個抽象層，每個群組只能是一種執行個體類型，導致你必須為每種工作負載開一個群組，管理複雜。第二，它的決策是「事後」的——必須先有 Pending Pod 才會動作。第三，它無法根據「當下最便宜的執行個體」來做決策。
Karpenter 完全不同。它不走節點群組，而是直接呼叫雲端 API 建立執行個體。它的運作模式是：
監聽叢集中所有「無法被排程」的 Pod。
把這些 Pod 的資源需求、親和性、汙點容忍等條件彙總起來。
直接呼叫 EC2 API 建立執行個體（透過 NodeClaim 這個中間資源）。
這個差異帶來三個巨大的成本優勢：
3.2 NodePool 與 EC2NodeClass 設計
Karpenter 1.x 的 API 把設定拆成兩個資源：NodePool（定義「要開什麼樣的節點」）與 EC2NodeClass（定義「怎麼開，用哪個 AMI、哪個子網、哪個安全群組」）。這種拆分讓不同團隊可以複用同一套基礎設施設定。
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: general-purpose
spec:
template:
spec:
requirements:
- key: kubernetes.io/arch
operator: In
values: ["amd64", "arm64"]
- key: karpenter.sh/capacity-type
operator: In
values: ["spot", "on-demand"]
- key: karpenter.k8s.aws/instance-family
operator: In
values: ["c7g", "c7i", "m7g", "m7i", "c6g", "m6g"]
- key: karpenter.k8s.aws/instance-size
operator: In
values: ["large", "xlarge", "2xlarge", "4xlarge"]
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
expireAfter: 720h # 節點最長存活 30 天
limits:
cpu: "1000"
memory: 2000Gi
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 1m
budgets:
- nodes: "10%"
這裡有幾個關鍵設定值得展開說明：
requirements 是成本優化的核心。把 capacity-type 同時放入 spot 與 on-demand，Karpenter 會優先嘗試 Spot，只有在 Spot 不可用時才退回到 On-Demand。把多個 instance-family 與 size 列進去，等於給 Karpenter 更大的「購物籃」，讓它更容易找到便宜又有容量的選擇。
expireAfter 是節點的生命週期上限。定期汰換節點有兩個好處：一是確保作業系統與 AMI 的安全性修補會生效，二是避免節點因為長期的記憶體碎片或核心洩漏而效率下降。設 720 小時（30 天）是常見做法。
disruption.consolidationPolicy 是 2026 年最重要的成本優化開關。設定為 WhenEmptyOrUnderutilized 時，Karpenter 不只會在節點空了之後縮掉它，還會在節點「使用率偏低」時，主動把 Pod 搬到更適合的節點上，然後關掉原本那台。這個動作稱為 Consolidation（整併）。
3.3 實例類型多樣化與 Spot 整合
Spot 執行個體通常能帶來 60% 到 90% 的折扣，是 Kubernetes 成本優化最大的單一槓桿。但 Spot 的挑戰是「中斷」——雲端廠商隨時可能收回，並給你兩分鐘的預告。
Karpenter 對 Spot 的支援相當成熟，它提供幾個關鍵機制：
實務建議是：把無狀態服務放到 Spot NodePool，把需要長期穩定的服務（如資料庫、監控、Ingress Controller）放在 On-Demand NodePool。透過 nodeSelector 或 taint / toleration 來分流。
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-server
spec:
template:
spec:
nodeSelector:
karpenter.sh/capacity-type: spot
tolerations:
- key: sku
operator: Equal
value: spot
effect: NoSchedule
3.4 整合中斷處理與 Consolidation
Consolidation 是 Karpenter 最能直接省錢的功能，但它也是最容易造成服務抖動的功能。原因是：整併節點時，上面的 Pod 必須被驅逐並重新排程。如果沒有做好 PDB（PodDisruptionBudget）與優雅關閉，就可能造成短暫的服務中斷。
建議的配置策略是：
為關鍵服務設定 PDB，例如 minAvailable: 80%。
consolidateAfter 設為 1 到 5 分鐘，不要設太短，避免剛開完節點就想整併。disruption.budgets 限制整併的速率，例如 nodes: "10%" 表示同時最多整併 10% 的節點。preStop hook 與 terminationGracePeriodSeconds，確保連線能優雅結束。2026 年的 Karpenter 在整併演算法上已經比早期版本聰明很多，它會考慮 Pod 的資源分布、節點的成本、以及搬遷的「隱性成本」（例如映像檔拉取時間），來決定是否值得整併。但這仍然需要維運團隊持續觀察與調校。
3.5 2026 年的新特性與生態發展
Karpenter 在 2024 年進入 CNCF 之後，發展速度明顯加快。到了 2026 年，以下幾個方向值得關注：
多雲供應者成熟化：除了 AWS 原生支援，Azure、GCP 與其他雲端廠商的 Karpenter Provider 在 2025 到 2026 年間陸續成熟。這意味著多雲架構可以用同一套 NodePool 抽象來管理。
Node Overlay 與成本感知排程：Karpenter 開始能讀取更多價格與容量資訊，並在排程階段就給出「這個 Pod 放在哪一種節點最便宜」的建議。
與 Kueue 等批次排程器整合：針對 AI / ML 工作負載，Karpenter 與 Kueue 的搭配讓 GPU 資源的取得與釋放更加自動化，這在 GPU 價格居高不下的時代極為重要。
四、KEDA + Karpenter 協同架構：1+1 大於 2 的成本優化
單獨使用 KEDA 或 Karpenter 都能省錢，但真正的威力在於兩者的協同。這一節我們來看完整的鏈路與實務上要注意的細節。
4.1 事件驅動的完整鏈路
讓我們用一個電商訂單處理系統來走一遍完整流程：
使用者下單，訊息進入 SQS 佇列。
queueLength: 10 計算出需要 5 個 Pod。KEDA 建立的 HPA 將 Deployment 的 Replica 從 0 調整到 5。
5 個新的 Pod 進入 Pending，因為叢集沒有足夠資源。
Karpenter 建立 NodeClaim，呼叫 EC2 API 啟動 Spot 執行個體。
約 45 秒後節點就緒，Pod 被排程上去，開始消費訊息。
訂單處理完畢，佇列清空。
KEDA 在 cooldownPeriod（300 秒）後將 Replica 縮回 0。
整個流程從「沒有請求」到「處理完畢並釋放全部資源」，完全不需要人工介入，而且成本只發生在真正有工作要做的那些分鐘。
4.2 避免「擴容震盪」的策略
這種架構最常見的問題是「震盪」：Pod 擴了又縮、節點開了又關，每一次開關都伴隨著 API 呼叫、映像檔拉取、啟動時間，這些都是成本，而且是隱形成本。
避免震盪的關鍵是設定合理的時間窗口。以下是建議的配置原則：
參數
建議值
說明
KEDA pollingInterval
15-30 秒
太短會打爆事件來源，太長反應遲鈍
KEDA cooldownPeriod
300-600 秒
避免批次間的短暫空窗導致縮容
HPA scaleDown stabilizationWindow
300 秒
讓縮容更平滑
Karpenter consolidateAfter
1-5 分鐘
避免節點剛開就被整併
Karpenter expireAfter
720 小時
定期汰換，維持效率與安全
另一個策略是分層擴縮容。對於那些「可以容忍冷啟動但有時會突然忙碌」的服務，可以設定 minReplicaCount: 1，並搭配 KEDA 的 cron Scaler 在預期的高峰前預先擴容。這樣就不用完全依賴事件觸發，減少了反應延遲。
4.3 監控指標與回饋迴路
要讓這套系統持續省錢，你必須建立完整的觀測。以下是幾個必看的指標：
服務指標：P99 延遲、錯誤率、冷啟動頻率。
把這些指標放進同一個 Grafana 儀表板，你就能夠回答最重要的問題：「我這個月省了多少錢？代價是什麼？」
五、成本優化實戰：數字會說話
談了這麼多架構，我們來看實際的成效。以下是一個綜合多個真實案例的基準情境。
5.1 基準案例：某電商平台的遷移
假設有一個中型電商平台，運行約 45 個微服務，日常流量如下：
平日白天（09:00-21:00）：平均 800 RPS，峰值 2500 RPS。
平日晚間（21:00-09:00）：平均 150 RPS。
大促期間：峰值可達 12000 RPS，持續約 4 小時。
優化前的架構是：使用 Cluster Autoscaler 搭配 6 個節點群組，混合 Spot 與 On-Demand，所有服務使用 CPU-based HPA，minReplicas 設為 2。每月雲端運算成本約 18,000 美元。
優化後的架構是：
KEDA 接管所有非同步服務（訂單、通知、物流、報表）與部分 API 服務。
Karpenter 接管全部節點供給，使用單一 NodePool 涵蓋 12 種執行個體族系。
Spot 使用比例從 40% 提升到 78%。
開發 / 測試環境全面啟用 Scale to Zero。
5.2 成本拆解與節省來源
優化項目
月度節省（美元）
佔比
Spot 比例提升（40% → 78%）
4,300
32%
非同步服務 Scale to Zero
3,200
24%
Karpenter 整併減少閒置節點
2,700
20%
開發環境 Scale to Zero
1,900
14%
執行個體類型最佳化（Rightsizing）
1,300
10%
合計
13,400
100%
換句話說，成本從每月 18,000 美元降到約 5,600 美元，節省幅度約 69%。這個數字並非特例——在正確配置的前提下，60% 到 75% 的節省是相當常見的區間。
但必須強調：節省不是免費的。這個團隊花了約三個月的時間做架構調整、調校參數、建立監控，並在前期經歷了幾次服務抖動。這是必要的投資。
5.3 FinOps 儀表板設計
要讓成本優化持續發生，你必須讓成本「可見」。以下是建議的 FinOps 儀表板核心區塊：
區塊一：總覽——本月至今花費、與上月同期比較、與預算比較、預估月底總額。這個區塊要放在最上面，讓所有人第一眼就看到。
區塊二：成本歸屬——按 namespace、按 team label、按服務拆解成本。這讓每個團隊知道自己的帳單，形成問責機制。
區塊三：效率指標——叢集整體 CPU / Memory 使用率、Spot 覆蓋率、每千次請求的成本、閒置容量比例。
區塊四：擴縮容行為——KEDA 的擴縮容次數、Karpenter 的節點週轉率、冷啟動頻率、平均擴容延遲。
把這些指標自動化，每週產生報表，並在異常時發出告警（例如「Spot 覆蓋率低於 60%」或「閒置容量超過 30%」）。這樣才能把成本優化從「一次性專案」變成「持續營運」。
六、2026 年趨勢展望與落地路線圖
最後，我們來談談未來與實作路徑。
6.1 AI 工作負載帶來的挑戰與機會
2026 年最大的變數，無疑是 AI 工作負載。GPU 資源的價格是 CPU 的數十倍，一個不小心，AI 訓練任務就能吃掉整個月的預算。
這帶來兩個新的需求。第一，GPU 資源的擴縮容。KEDA 已經開始支援透過自訂指標（例如 Kueue 的佇列長度）來觸發 GPU Pod 的擴容，而 Karpenter 也在 2025 年之後支援 GPU 執行個體（如 p5、g6 系列）的 NodePool。第二，批次排程與資源共享。把多個訓練任務排進同一個佇列，讓 GPU 資源被充分使用，而不是每個團隊各自養一批閒置的 GPU。
對於有 AI 工作負載的團隊，建議把 KEDA、Karpenter 與 Kueue 三者搭配使用，形成「佇列 → 擴容 → 供給」的完整鏈路。
6.2 30 / 60 / 90 天落地計畫
如果你現在才要開始，以下是務實的三階段計畫：
第 1 到 30 天：可觀測性與基礎建設
部署 Kubecost 或 OpenCost，建立成本可視化。
盤點所有工作負載，標記「同步 / 非同步」、「可中斷 / 不可中斷」。
在非生產環境先部署 Karpenter，取代 Cluster Autoscaler。
建立 Grafana 儀表板與每週成本報表。
第 31 到 60 天：KEDA 導入與 Scale to Zero
在開發 / 測試環境為所有服務啟用 Scale to Zero。
選定 3 到 5 個非同步服務（如報表、通知、批次）導入 ScaledJob。
調校 pollingInterval 與 cooldownPeriod，觀察震盪情況。
在生產環境逐步導入 KEDA，先從低風險服務開始。
第 61 到 90 天：Spot 整合與持續優化
把可中斷服務遷移到 Spot NodePool，目標覆蓋率 70% 以上。
建立 FinOps 回饋流程：每月檢視成本報表，調整參數。
評估 AI / GPU 工作負載的整合可能性。
6.3 常見反模式與避坑清單
最後，整理幾個實務上常見的反模式，供你避坑：
結論：把成本優化當成一場長跑，而不是一次衝刺
2026 年的 Kubernetes 成本優化，已經從「選配」變成了「標配」。KEDA 與 Karpenter 這兩個工具，分別從「需求側」與「供給側」解決了原生 Kubernetes 擴縮容的效率問題。它們的組合，讓你可以真正做到「有需求才付費、沒需求就歸零」。
但請記住，工具只是工具。真正決定成本的是架構設計、參數調校、與持續的觀測與迭代。一套配置得當的 KEDA + Karpenter 架構，可以讓你的雲端帳單降低 60% 到 70%；但配置不當，也可能帶來震盪、超時、甚至服務中斷。
建議的起步方式是：先做可觀測性，再做非生產環境的實驗，最後才在生產環境逐步導入。不要試圖一次到位，也不要為了省錢而犧牲 SLO。真正成熟的成本優化，是在「穩定」與「節省」之間找到那個動態平衡點——而這個平衡點，會隨著你的業務不斷移動。
希望這篇指南能成為你在 2026 年成本優化路上的實用地圖。如果你想繼續深入某個主題（例如 ScaledJob 的進階配置、Karpenter 的多雲策略、或是 FinOps 儀表板的實作），歡迎在論壇上繼續討論，也期待看到你分享自己的實戰數字。
本文由雅寶社區 · 頂客論壇編輯部整理，內容基於 2025 年底至 2026 年初的實務經驗。技術細節可能隨版本更新而變化，請以官方文件為準。
```