在邊緣應用中，實現 Kubernetes 的主動擴縮容

作者 | Rajeev Kallayil Ravi

譯者 | 張衛濱

過去十年間，Kubernetes 已經演變為現代 IT 基礎設施的核心平臺之一。它通過可擴展的架構與聲明式的資源定義模型，讓企業能夠管理大規模、高度分布式的容器化負載，并能夠自動化各類運維任務。

因此，它提供了一種高度可擴展的分布式工作負載管理方法。許多組織都在云環境中運行 Kubernetes 部署，這樣能夠提供無限的處理能力，但是在向邊緣計算環境轉變的過程中，Kubernetes 用戶面臨著新的運維需求。

邊緣計算 需要在靠近數據生成位置的設備或服務器上運行應用，而非集中式地部署在云端。運行在邊緣的應用必須滿足極低延遲的要求，具備高度的彈性，并在面對大量且不可預測的工作負載峰值時表現穩定。

由于邊緣應用的處理能力、內存和網絡帶寬都是有限的，高效使用這些資源并快速擴縮容邊緣應用，對于維持終端用戶的體驗質量與服務可靠性至關重要。

Kubernetes 提供了 Horizontal Pod Autoscaler（HPA） 的功能，它可以基于當前的資源使用率（包括 CPU、內存和自定義指標）動態調整部署中的 Pod 數量。

HPA 在應對云環境中觀測到的流量模式時非常有效；但在管理動態、突發式的邊緣工作負載時效果明顯要差一些，在這類場景中，KEDA 或自定義擴縮器等替代方案會更合適。

圖 1：HPA 的工作原理

HPA 具有僵化性，依賴滯后的指標，而且缺乏上下文感知，這通常會導致 Pod 數量擴容得過多、過少或反復震蕩。在資源受限的環境中，這些行為可能代價高昂，甚至存在風險。

我們基于 Custom Pod Autoscaler（CPA） 為邊緣計算構建了一款自定義的擴縮器，以部分解決 HPA 的局限性。CPA 使工程師能夠開發自定義算法、使用多種指標組合、快速響應系統狀態變化，并根據集群中運行的應用特性調整擴縮容方式。

1 Kubernetes HPA 在邊緣場景下的局限性

HPA 的功能是使用一種公式化的比例方法計算應用期望的副本數，公式如下：

desiredReplicas = currentReplicas * currentMetricValue / desiredMetricValue

該公式被硬編碼在 Kubernetes 系統中。因此，工程師無法重寫公式、調整擴縮容的激進程度，也無法添加任何特定領域的邏輯，除非為環境重新構建一整套的擴縮器。

雖然這適用于云原生應用，但對延遲敏感、流量多變的邊緣應用而言可能就會存在問題。

2 算法的靈活性不足

物聯網（Internet of things，IoT）網關和游戲邊緣服務器的工作負載通常與資源不是簡單的等比關系。換句話說，IoT 網關可能在短時間內使用率暴增十倍（例如，收到大量傳感器事件），而游戲邊緣服務器需要在用戶加入游戲前就擴容，而不能等到 CPU 升高后。

HPA 無法編碼時間感知或預測邏輯。它不支持漸進縮容，無法限制擴容的速率，也無法在不大量改造應用的情況下基于多種指標做出決策。

在邊緣環境中，HPA 處理短期峰值的低效性會導致如下的問題：

• 設備注冊風暴（Registration bursts from devices）

• 用戶連接洪峰（Floods of user connections）

• 媒體轉碼激增（Spikes in media transcoding）

• 網關波動引發的 API 流量激增（API surges resulting from gateway churn）

HPA 將所有突發流量視為持續負載，導致系統擴容過快，遠超處理短期峰值所需規模。

圖 2：表示突發流量的短期峰值

這種快速變化會造成 Pod 浪費，消耗小型節點上寶貴的 CPU 和內存資源，最終加劇節點壓力，甚至引發 驅逐風暴（eviction storm）。

3 自定義指標帶來的運維開銷

Kubernetes 在autoscaling/v2中增加了對自定義指標的支持，但需要：

• 指標服務器

• 自定義指標 API

• Prometheus

• 導出器（Exporter）

• 適配器（Adapter）

這套架構雖然成熟且得到了廣泛應用，但需要引入額外的資源開銷與運維復雜度，在部分資源受限環境中極具挑戰性。

圖 3：使用自定義指標與指標服務器的 HPA 擴縮容

上圖展示了支持外部指標的 autoscaling/v2 版 HPA。在示例中，集群配置了以下依賴：

• 部署自定義指標適配器（Istio）以查詢指標

• 生成的適配器將自身注冊為“custom.metrics.k8s.io”

• 在集群中部署 Prometheus 社區版

• 生成的 Prometheus Pod 會抓取 Pod 端點以獲取執行所需的指標

• 第一步部署的 Istio 適配器配置為查詢集群內運行的 Prometheus 實例

• 查詢邏輯寫入 HPA 配置中，下方代碼片段展示了查詢每個 Pod 請求數的邏輯

通過施加負載，我們可借助 Grafana 控評估抓取到的請求數量，并觀察擴縮容行為。

4 邊緣架構概述

邊緣計算環境的通用結構通常需要圍繞多個物理上靠近終端用戶的自治邊緣工作節點來構建，并在遠端云或數據中心中部署中央控制器。

每個邊緣節點會獨立運行，處理大量的本地流量，并執行管理流量所需的許多功能，因此需要一套可快速、高效、基于當前狀態擴縮容的邏輯系統。由于邊緣到云端的回傳帶寬通常非常有限，往返通信成本很高。

可運行在邊緣計算平臺的示例應用包括：

• 游戲引擎平臺

• 實時視頻處理

• AR/VR 低延遲計算

• IoT 網關數據聚合

• 機器學習推理

• 本地內容緩存 / 代理服務

這些應用的擴縮容模式均與 HPA 傳統基于 CPU 的算法所優化的模式有所差異。

5 設計自定義的 Pod 自動擴縮器

為克服 HPA 基于少數僵化行為進行擴縮容的不足，人們設計出了 CPA，以滿足以下需求：

• 允許系統監控任意指標（比如，CPU、延遲、隊列長度、自定義 KPI）

• 將指標監控與擴縮容算法解耦

• 支持基于預測或補償的主動擴縮容

• 通過安全縮容策略防止 震蕩

• 保留足夠的 CPU 余量以應對邊緣工作負載的突發波動

• 在保持穩定的前提下比 HPA 響應更快

圖 4：CPA 的架構

CPA 的開發解除了 Kubernetes 原生擴縮器的限制，允許開發者定義自定義擴縮容的邏輯，同時可以使用可擴展的 Kubernetes 原生控制器。

CPA 評估算法

擴縮容評估會從指標采集模塊獲取標準化的指標，并據此做出決策。在早期原型中，評估組件基于固定的 CPU 閾值擴容副本，每達到一個閾值就按固定值增加。這種方式雖然易于實現，但無法反映真實環境中擴縮容系統的行為，也無法滿足邊緣工作負載的運維需求。

與之不同的是，最新的實現包含一套基于云服務商、游戲網絡后端和運行大規模低延遲平臺的 SRE 團隊最佳實踐的擴縮容模型。新模式使用三種核心工作負載狀態信號替代了僵化的數值閾值，即 CPU 余量（CPU headroom）、延遲 SLO 感知（latency SLO awareness）、Pod 啟動補償（pod startup compensation）。

CPU 余量

當存在足夠 CPU 余量時，可以吸收邊緣工作負載峰值所需的 CPU，避免排隊或延遲損失。擴縮器會設定目標利用率安全區，通常會在 70%–80%，以維持余量緩沖。如果所有 Pod 的平均 CPU 使用率持續高于余量閾值，擴縮器會計算需要增加多少副本才能恢復緩沖空間。

延遲 SLO 感知

如果應用能夠導出延遲數據（例如，95 分位的響應時間 p95），CPA 會使用該數據做出擴縮容決策。 當 p95 延遲接近或超過延遲服務目標（比如，交互式邊緣工作負載 60ms）時，擴縮器會按延遲 SLO 超標程度成比例增加副本數。由此，擴縮器會避免將 CPU 作為唯一性能指標，這在 IO 密集型和混合工作負載中尤為重要。

Pod 啟動補償

與中心化云環境中較快的容器啟動速度不同，邊緣節點因磁盤吞吐量較低或鏡像冷啟動，容器啟動時間通常會更長。為解決長啟動時間的問題，擴縮器會根據估算得到 Pod 的啟動時間（基于本地觀察得出該數據），并對即將到來的負載進行預判擴容。 如果 CPU 使用上升速度過快，那么很可能在 Pod 啟動完成前就耗盡了可用容量，擴縮器將觸發主動擴容。

這三種輸入信號共同提供了復合的擴縮容建議，使 CPA 比 Kubernetes 默認的固定 HPA 算法更具上下文感知能力：

• 所有信號正常，則不進行擴縮容

• 某一個信號超出了閾值，則適度擴容

• 兩個及以上信號超標，則 CPA 按照信號的嚴重程度大幅擴容

縮容設計為緩慢執行，并需要一段穩定窗口，以避免 HPA 常見的震蕩行為。

由此，CPA 從簡單的“閾值監控”響應式擴縮器，轉變為了可有效管理真實邊緣工作負載的上下文感知擴縮容引擎。

6 實現與負載生成

CPA 使用了開源的 Custom Pod Autoscaler Framework，這是一個 Kubernetes 原生控制器，支持使用 Python 開發自定義 Pod 擴縮容邏輯。

Custom Pod Autoscaler 框架負責與 Kubernetes 通信。開發者只需要提供兩個 Python 腳本：

• metric.py— 采集 / 獲取指標

• evaluate.py— 計算期望的副本數

按用戶定義的間隔（默認 15 秒），Kubernetes 會調用 CPA 控制器?？刂破鬟\行指標腳本，將 JSON 輸出管道傳遞給評估腳本，然后根據評估結果擴縮容 Pod。

CPA 配置文件

每個自定義擴縮容器都通過 config.yaml 進行配置，定義指標源、評估邏輯、目標工作負載、擴縮容限制和執行間隔：

  maxReplicas: 20

指標采集腳本

指標腳本負責獲取 CPU 使用率、延遲或自定義信號。本實現中，由 Prometheus 采集 CPU 和 p95 延遲。

    main()

評估腳本

以下 評估算法 實現了一套基于 CPU、延遲 SLO、Pod 啟動時間以及安全擴縮容約束的擴縮容邏輯。

    output(target_replicas)

7 驗證與評估

增強的擴縮容邏輯在所有測試場景中均表現更優。基于 CPU 閾值余量的擴縮容邏輯比早期原型的固定閾值邏輯更成熟、更穩定。

持續壓力

基于 CPU 余量邏輯的持續負載使 CPA 能夠平滑擴縮容，同時保持了可預測的資源利用率，避免不必要的副本膨脹。

短期峰值

CPA 中的 Pod 啟動補償與保守縮容規則避免了 HPA 對短期性能增長的典型過度反應。

漸進增長的負載

延遲感知的擴縮容使擴縮器在達到 CPU 硬限制前就能檢測到性能下降，響應更快、更精準。

通過調整余量等級、動態設置延遲 SLO 閾值與冷卻間隔，我們可以生成隨機負載模式，模擬不規則的真實流量行為。

圖 5：生成的隨機負載

圖 6：部署的 Pod 數量

與 HPA 相比，CPA 表現出以下特點：

• 震蕩幅度更低

• 啟動副本更少

• 更快恢復穩態

• 平均延遲更穩定

• CPU 浪費減少

圖 7：HPA vs. CPA

8 經驗總結

新的擴縮容邏輯帶來以下優勢，它們都是與邊緣應用高度相關的：

• 單一指標無法適配所有場景。CPU 只是決定性能、延遲和 Pod 啟動時間的眾多指標之一。

• 預測式擴縮容有助于減少不穩定行為。使用 Pod 啟動補償能夠預判集群未來請求可能會飽和，這有助于減少突發飽和事件。

• 支持延遲縮容。突然縮容會造成系統震蕩，導致用戶體驗下降，緩慢縮容會提供用戶習慣的平滑行為。

• 在計算與內存資源有限的邊緣環境中，HPA 的激進副本擴縮容可能帶來意外的副作用，比如，內存壓力、Pod 驅逐和限流。

• 更高的靈活性。CPA 架構將指標采集與使用指標的邏輯分離。隨著應用產生更高級的遙測數據，這種分離使擴縮容邏輯可獨立于采集指標演進。

9 結論

通過使用基于 CPU 余量目標、延遲感知評估和 Pod 啟動時間補償的策略替代固定閾值擴縮容，Custom Pod Autoscaler（CPA）成為了一種靈活且可擴展的解決方案。CPA 為工程師提供了創建滿足應用性能需求的擴縮容策略的能力，同時解決了 Kubernetes HPA 在邊緣計算中的可擴展性局限。盡管基于 CPA 的策略正確實施后能帶來諸多收益，但它也需要大量調優、嚴謹的運維文化和高質量的指標。

因此，雖然 CPA 可以與 Kubernetes 原生擴縮容能力配合使用，但基于 CPA 的策略最適合那些擴縮容會直接影響性能與用戶體驗的應用。

最近，Kubernetes 事件驅動擴縮容（KEDA） 與 HPA 的結合發展，極大豐富了基于事件與外部信號對各類工作負載進行擴縮容的選擇。

CPA 是專門為存在啟動延遲、資源限制和多性能指標共同影響擴縮容決策的場景而設計的，這使其尤其適合邊緣環境。通過合理調優與監控，CPA 為在邊緣環境實現可預測、高效率、對性能敏感的擴縮容提供了一套可落地、可擴展的方案。

Proactive Autoscaling for Edge Applications in Kubernetes（https://www.infoq.com/articles/proactive-autoscaling-edge-kubernetes/）