HPA 與 KPA 雙軌並行：流量突波時該靠指標還靠請求？

本文對比 Kubernetes 原生 HPA（指標驅動）與 Knative KPA（流量驅動）在突發流量下的擴縮容機制，解析兩者觀測對象、計算公式、穩定與恐慌窗口的運作差異，並提供依服務特性選型的決策框架。

兩種擴縮容邏輯的根本差異：指標 vs. 流量
HPA：以資源指標為核心的保守擴縮容
HPA v2 behavior 欄位：把「抖動」與「速度」交給策略控制
KPA：以即時並發請求為核心的積極擴縮容
KPA 雙模式機制：Stable window 與 Panic window 的協作邏輯
選型決策矩陣：流量特徵、冷啟動容忍度與運維成本的權衡

兩種擴縮容邏輯的根本差異：指標 vs. 流量

要比較 Kubernetes 原生 HPA 與 Knative KPA 的差異，第一步是回到兩者各自「觀察什麼」這個根本問題。根據 Kubernetes 官方文件，HPA 控制器運行於控制平面中，會週期性地調整目標工作負載（例如 Deployment）的期望副本數，使其符合觀測到的指標，例如平均 CPU 使用率、平均記憶體使用率，或是使用者自訂的其他指標。換言之，HPA 的決策依據是資源層級的量化指標，而非請求本身。

KPA 的觀測對象則不同。依據阿里雲所引用的 Knative 文件說明，KPA 根據即時流量進行擴縮容，監控每個 Pod 的並發請求數（concurrency）與每秒請求數（RPS）來決定最適合的 Pod 數量。此外，當流量降為零時，KPA 預設會將 Pod 縮減至零，以消除閒置資源成本；當流量恢復時，再依需求建立 Pod。這是與 HPA 以資源指標為核心的邏輯根本不同的起點。

把兩段定義並排閱讀，可以清楚看到「指標驅動」與「流量驅動」的分界：HPA 問的是「目前的 Pod 資源用得多滿」，KPA 問的是「現在有多少請求正在被處理」。值得注意的是，以上兩份文件都只描述了各自的機制，並未宣稱哪一種在所有情境下更優越。因此本文後續的對比，應被理解為機制層面的梳理，而非通用的優劣排名。

這個差異在實務上意味著什麼？可以這樣思考一個假設性的選擇：若一個服務的瓶頸明確落在 CPU 或記憶體消耗上，以資源指標作為伸縮依據是直觀的對應；反之，若關心的核心是「有多少請求在排隊等待」，並發請求數才是更貼近問題的訊號。兩種觀測對象回答的是不同問題，本節僅建立這條基線，至於各自的保守機制、參數調校方式與選型權衡，留待後續段落逐一拆解。

HPA：以資源指標為核心的保守擴縮容

先從 HPA 的基本運作方式說起。根據 Kubernetes 官方文件，HPA 控制器運行於控制平面中，會週期性地調整目標工作負載的期望副本數，使其符合觀測到的指標，例如平均 CPU 使用率、平均記憶體使用率，或使用者自訂的其他指標。也就是說，HPA 的計算起點是「資源使用率」這類量化數值。

當同時設定多個指標時，文件描述的處理方式是：對每個指標各自計算期望副本數，然後取其中最大的值。此外，如果某個指標因故無法換算成副本數（例如從 metrics API 抓取資料時出錯），而其餘可取到的指標傾向縮容，那麼這次伸縮會被直接略過；但只要任一可用指標算出的副本數高於現值，擴容仍然可以進行。

對於資料不完整的狀況，官方文件同樣給出了具體的處理規則。若有指標缺失，控制平面會重新計算平均值：在縮容情境下，假設那些缺少數據的 Pod 正以 100% 的期望值在消耗資源；在擴容情境下，則假設其消耗為 0%。文件說明這麼做是為了壓低本次伸縮的幅度。同樣地，若存在尚未就緒的 Pod，而在不考慮缺失指標與未就緒 Pod 的情況下工作負載本應擴容，控制器會假定這些未就緒 Pod 的消耗占期望值的 0%，進一步縮小擴容幅度。

HPA v2 behavior 欄位：把「抖動」與「速度」交給策略控制

behavior 欄位提供兩類調控手段。其一，依據官方文件的描述，可以指定 stabilization window，用來防止縮放目標的副本數來回抖動（flapping）；其二，scaling policies 則讓使用者控制擴縮容過程中副本數的變化速率。前者管的是「穩不穩」，後者管的是「快不快」——兩個維度在機制上是分開的。

把這兩個手段對應到實務問題，可以這樣思考：流量起伏頻繁的服務，副本數若跟著指標忽上忽下，真正帶來困擾的往往不是擴容太慢，而是反覆抖動造成的干擾；這時 stabilization window 處理的就是這一側的問題。反之，若服務在縮容時需要循序漸進、避免一次砍掉大量副本，scaling policies 控制的變化速率才是對應的旋鈕。兩者解決的是不同性質的問題，調校前應先確認自己卡在哪一項。

需要釐清的限制是：文件僅說明這些欄位「可以」分開調控擴縮容行為，並未提供各參數的建議值或適用情境，也未宣稱設定後能消除所有抖動。因此，behavior 欄位應被理解為一把交給使用者的調控介面，而非一勞永逸的保證。實際該把穩定窗口設多長、變化速率壓多低，文件沒有替任何人預設答案——這個判斷得回到各自服務的流量特徵與可接受的陣痛程度，由團隊自行驗證取捨。

KPA：以即時並發請求為核心的積極擴縮容

KPA 的核心邏輯是直接把流量換算成 Pod 數。根據阿里雲所引用的 Knative 文件說明，Knative Pod Autoscaler（KPA）依據即時流量進行擴縮容，監控每個 Pod 的並發請求數（concurrency）與每秒請求數（RPS）來決定最適合的 Pod 數量。也就是說，它的觀測訊號不是 CPU 或記憶體，而是請求本身。

在計算上，同一來源給出的公式是：Pod 數等於並發請求數除以「每個 Pod 的最大並發請求數乘以目標利用率」。其預設值為：每個 Pod 最多處理一百個並發請求，目標利用率為百分之七十。這組公式與預設值，構成了本節關於 KPA 計算方式的全部已驗證事實。

舉個假設性情境來讀這條公式：若團隊把「每 Pod 最大並發數」設定得較低，在同樣的並發請求量下，公式算出的目標 Pod 數就會較高。這是讀者可以自行代入自己服務數字來檢視的結構關係；不過文件並未說明該把這兩個參數設成多少才「合理」，實際設定仍須回到各自的服務特徵去驗證，文件本身不提供通用答案。

至於「縮容至零」，是 KPA 另一個文件明確記載的行為：當流量降為零時，KPA 預設會將 Pod 縮減至零，以消除閒置資源成本；當流量恢復時，再依需求建立 Pod。

這個「歸零再建立」的特性，在實務上是一個取捨點：文件只陳述了「不付閒置成本、需要時才建立」的機制，沒有討論從零到可用之間的過程對使用者的影響。因此，是否適合開啟這個預設行為，取決於服務能否接受流量恢復時「現場建立 Pod」這件事——這屬於讀者須自行評估的條件，而非文件給出的結論。至於 KPA 如何用穩定窗口與恐慌窗口處理突波節奏，屬於下一節的範圍。

KPA 雙模式機制：Stable window 與 Panic window 的協作邏輯

KPA 採雙窗口機制處理流量波動：穩定窗口預設 60 秒，對所有 Pod 的並發請求取平均，作為常態擴縮容依據；恐慌窗口則取穩定窗口的 10%（即 6 秒），用於捕捉瞬間尖峰。

恐慌模式的觸發門檻預設為 200%，換算為當前就緒 Pod 數的兩倍。只有當恐慌窗口內的計算 Pod 數達到或超過這個倍數，KPA 才會切換至恐慌模式並依其結果擴容；否則沿用穩定模式的較平緩結果。

由上至下為：監控並發請求、穩定窗口60秒平均、恐慌窗口6秒平均、是否達200%門檻、依恐慌模式擴容、沿用穩定模式結果；箭頭：監控並發請求到穩定窗口60秒平均、監控並發請求到恐慌窗口6秒平均、穩定窗口60秒平均到是否達200%門檻、恐慌窗口6秒平均到是否達200%門檻、是否達200%門檻到依恐慌模式擴容、是否達200%門檻到沿用穩定模式結果

選型決策矩陣：流量特徵、冷啟動容忍度與運維成本的權衡

Kubernetes 原生 HPA 依據控制平面定期收集的 CPU、記憶體或自訂指標來調整期望副本數；Knative KPA 則直接監控即時的並發請求數與每秒請求率，並在流量歸零時將 Pod 縮減至零，流量恢復時再按需建立。

HPA 在指標缺失或 Pod 尚未就緒時會採取保守假設：縮容時視缺失 Pod 為滿載、擴容時視為零載，並可透過 v2 behavior 欄位分別設定擴容與縮容的穩定窗口與速率策略，以抑制抖動或加快反應。

KPA 採用雙窗口機制：預設 60 秒的穩定窗口對所有 Pod 的並發取平均，6 秒的恐慌窗口（0.1 倍穩定窗口）捕捉瞬間尖峰；只有當恐慌模式計算出的 Pod 數達到當前就緒 Pod 數的 200%（即兩倍）時才切換至恐慌模式進行擴容。

根據上述機制，團隊可依服務屬性做初步選型：若流量呈現劇烈突發且業務能接受冷啟動延遲，KPA 的流量驅動與縮零特性可降低閒置成本；若已建立完善指標管線且重視擴縮容節奏的可預期性，HPA 的指標模型搭配 behavior 微調能提供較平穩的副本變化。若同一叢集同時運行狀態服務與無狀態 API，可考慮對前者套用 HPA、對後者套用 KPA，但需自行評估冷啟動延遲是否在可接受範圍，以及指標鮮度是否足以支撐 HPA 的反應速度。

摘要引用 HPA 觀測指標、v2 behavior、KPA 並發與 RPS、穩定及恐慌窗口

參考資料10

Haeng-un Services

把方法落到實際品牌系統

從策略到執行，選擇你現在最需要補強的一環。

網站設計與 SEO網站體驗、搜尋能見度與內容結構 攝影與短影音品牌影像、人物內容與社群短影音 社群內容與行銷內容企劃、社群節奏與轉換設計

想在 Google 搜尋與 AI 搜尋中優先看到 Haeng-un？

可將 haeng-un.com 設為 Google 偏好來源。

加入 Google 偏好來源

Work with Haeng-un

把下一步做得更清楚。

需要網站、影像或社群內容一起整理，我們可以從現在最重要的問題開始。

合作洽詢