Effective HPA：預測未來的彈性伸縮產品

2022 年 4 月 20 日
筆記
docker, istio, k8s, Kubernetes, Prometheus, TKE, 雲原生, 雲計算, 容器, 騰訊雲原生

作者

胡啟明，騰訊雲專家工程師，專註 Kubernetes、降本增效等雲原生領域，Crane 核心開發工程師，現負責成本優化開源項目 Crane 開源治理和彈性能力落地工作。

余宇飛，騰訊雲專家工程師，專註雲原生可觀測性、成本優化等領域，Crane 核心開發者，現負責 Crane 資源預測、推薦落地、運營平台建設等相關工作。

田奇，騰訊高級工程師，專註分散式資源管理和調度，彈性，混部，Kubernetes Contributor，現負責 Crane 相關研發工作。

引言

業務的穩定性和成本之間的矛盾由來已久。在雲原生時代，按需付費的成本模型催生出了自動彈性伸縮技術——通過動態申請、歸還雲上資源，在滿足業務需求的前提下，降低成本。

什麼是 HPA

談到雲原生中的彈性，大家自然想到 Kubernetes 的各種自動伸縮（Auto Scaling）技術，其中最具代表性的當屬水平 Pod 自動伸縮（HPA）。

HPA 作為 Kubernetes 的內建功能，具有一系列優點：

兼顧業務高峰穩定、低谷降本的訴求。
功能穩定，社區中立：隨著 kubernetes 版本的迭代，其本身的功能也在不斷地豐富和完善，但 HPA 的核心機制一直保持穩定，這也說明它可以滿足最通用的彈性伸縮場景。
順應 Serverless 趨勢：隨著各個大廠發布 Serverless 容器產品，以及虛擬節點池技術的提出，HPA 很大程度上覆蓋了集群自動伸縮（CA）的功能，使得自動伸縮更輕量、更敏捷。
完善的擴展機制：提供諸如 custom_metrics、external_metric 等擴展指標，用戶可以根據實際情況配置最適合業務的 HPA。

傳統 HPA 的問題

HPA 也並不完美：

如何配置：HPA 運行的效果取決於用戶資源的配置（target、minReplicas、maxReplicas 等等）。配置過於激進可能導致應用可用性、穩定性受影響，配置過於保守彈性的效果就大打折扣。如何合理的配置是用好 HPA 的關鍵。
彈性不夠及時：原生 HPA 是對監控數據的被動響應，此外應用本身啟動、預熱也需要一定時間，這使得HPA天生具有滯後性，進而可能影響業務穩定。這也是很多用戶不信任、不敢用HPA的一個重要原因。
可觀測性低：HPA 沒法通過類似 Dryrun 方式測試，一旦使用便會實際修改應用的實例數量，存在風險；而且彈性過程也難以觀測。

時間序列預測

HPA 通常被應用於負載具有潮汐性的業務，如果從流量或者資源消耗等指標的時間維度來看，會發現很明顯的波峰、波谷形態。進一步觀察，這類具有波動性的業務往往天然地在時間序列上也有著明顯周期性，尤其是那些直接或間接服務於「人」的業務。

這種周期性是由人們的作息規律決定的，例如，人們習慣中午、晚上叫外賣；早晚會有出行高峰；即時是搜索這種業務時段不明顯的服務，夜裡的請求量也會大大低於白天。對於此類業務，一個很自然的想法，就是通過過去幾天的數據預測出今天的數據。有了預測的數據（例如：未來24小時的業務 CPU 的使用情況），我們就可以對彈性伸縮做出某種「超前部署」，這也是 Effective HPA 能夠克服原生 HPA 實時性不足的關鍵所在。

Effective HPA 是什麼

Effective HPA（簡稱 EHPA）是開源項目 Crane 中的彈性伸縮產品，它基於社區 HPA 做底層的彈性控制，支援更豐富的彈性觸發策略（預測，監控，周期），讓彈性更加高效，並保障了服務的品質：

提前擴容，保證服務品質：通過演算法預測未來的流量洪峰提前擴容，避免擴容不及時導致的雪崩和服務穩定性故障。
減少無效縮容：通過預測未來可減少不必要的縮容，穩定工作負載的資源使用率，消除突刺誤判。
支援 Cron 配置：支援 Cron-based 彈性配置，應對大促等異常流量洪峰。
兼容社區：使用社區 HPA 作為彈性控制的執行層，能力完全兼容社區。

架構

EHPA 的主要架構如下：

EHPA Controller: 負責 EHPA 對象的控制邏輯，包括 EHPA 的增刪改查和 HPA 的同步
Metric Adapter：負責預測指標以及其他相關指標的生成
Predictor：負責主要用於時序數據分析和預測
TimeSeriesPrediction：時序數據預測 CRD，主要供 EHPA 和 MetricAdapter 進行消費
HPA Controller: 社區原生 HPA 控制器，EHPA 對此完全兼容，允許用戶有已經配置的 HPA
KubeApiServer：社區原生 Kubernetes ApiServer
Metric Server：社區原生 Metric Server

主要功能

基於預測的彈性

EHPA 充分挖掘 Workload 的相關指標，對於資源消耗和流量有明顯周期性的 Workload，預測其在未來一段時間窗口的時序指標，利用該預測窗口數據，HPA 獲取到的指標會帶有一定的前瞻性，當前 EHPA 會取未來窗口期內指標的最大值，作為當前 HPA 的觀測指標。

這樣當未來流量上升超過 HPA 容忍度的時候，HPA 就可以在當下完成提前擴容，而當未來短時間內有流量降低，但是其實是短時抖動，此時由於 EHPA 取最大值，所以並不會立即縮容，從而避免無效縮容。

用戶可以通過配置以下指標：

apiVersion: autoscaling.crane.io/v1alpha1
kind: EffectiveHorizontalPodAutoscaler
spec:
  # Metrics 定義了彈性閾值，希望 workload 的資源使用保持在一個水平線上
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  # Prediction 定義了預測配置
  # 如果不設置，則不開啟彈性預測
  prediction:
    predictionWindowSeconds: 3600   # PredictionWindowSeconds 定義了預測未來多久的時間窗口。
    predictionAlgorithm:
      algorithmType: dsp
      dsp:
        sampleInterval: "60s"
        historyLength: "3d"

MetricSpec: 配置和 HPA 是一致的，保持用戶一致的體驗
Prediction: 主要用來設置預測先關參數，包括預測窗口和演算法類型，未來對於窗口時序指標的處理策略，用戶可以自行訂製。
- PredictionWindowSeconds: 預測未來時間窗口長度
- Dsp: 該演算法是基於FFT（快速傅里葉變換）的時序分析演算法，針對周期性強的時序有不錯的預測效果，而且無需進行模型訓練，簡單高效

基於 Cron 的彈性

除了基於監控指標，有時候節假日彈性和工作日會有差異，簡單的預測演算法可能無法比較好的工作。那麼此時可以通過設置周末的 Cron 將其副本數設置更大一些，從而彌補預測的不足。

針對某些非 Web 流量型應用，比如有些應用會在周末的時候無需工作，此時希望工作副本縮容為1，也可以配置 Cron 進行縮容，降低用戶成本。

定時 Cron 彈性 Spec 設置如下：

apiVersion: autoscaling.crane.io/v1alpha1
kind: EffectiveHorizontalPodAutoscaler
spec:
  crons:
  - name: "cron1"
    description: "scale up"
    start: "0 6 ? * *"
    end: "0 9 ? * *"
    targetReplicas: 100
  - name: "cron2"
    description: "scale down"
    start: "00 9 ? * *"
    end: "00 11 ? * *"
    targetReplicas: 1

CronSpec: 可以設置多個 Cron 彈性配置，Cron 周期可以設置周期的開始時間和結束時間，在該時間範圍內可以持續保證 Workload 的副本數為設定的目標值。
- Name：Cron 標識符
- TargetReplicas：本 Cron 時間範圍內 Workload 的目標副本數
- Start：表示 Cron 的開始時間，時間格式是標準的 linux crontab 格式
- End: 表示 Cron 的結束時間，時間格式是標準的 linux crontab 格式

目前一些廠商和社區的彈性 Cron 能力存在一些不足之處：

Cron 能力是單獨提供的，彈性沒有全局觀，和 HPA 的兼容性差，會產生衝突
Cron 的語義和行為不是很匹配，甚至使用起來非常難以理解，容易造成用戶故障

下圖是當前 EHPA 的 Cron 彈性實現和其他 Cron 能力對比：

針對上述問題，EHPA 實現的 Cron 彈性，是在兼容 HPA 基礎上來設計的，Cron 作為 HPA 的指標，是和其他指標一樣共同作用於 Workload 對象的。另外，Cron 的設置也很簡單，單獨配置 Cron 的時候，不在激活時間範圍是不會對 Workload 進行默認伸縮的。

彈性結果預覽

EHPA 支援預覽(Dry-run)水平彈性的結果。在預覽模式下 EHPA 不會實際修改目標工作負載的副本數，所以你可以通過預覽EHPA彈性的效果來決定是否需要真的開始自動彈性。另外一種場景是當你希望臨時關閉自動彈性時，也可以通過調整到預覽模式來實現。

ScaleStrategy: Preview 為預覽模式，Auto 為自動彈性模式
SpecificReplicas: 在預覽模式時，可以通過設置 SpecificReplicas 指定工作負載的副本數

apiVersion: autoscaling.crane.io/v1alpha1
kind: EffectiveHorizontalPodAutoscaler
spec:
  scaleStrategy: Preview   # ScaleStrategy 彈性策略，支援 "Auto" 和 "Preview"。
  specificReplicas: 5      # SpecificReplicas 在 "Preview" 模式下，支援指定 workload 的副本數。
status:
  expectReplicas: 4        # expectReplicas 展示了 EHPA 計算後得到的最終推薦副本數，如果指定了 spec.specificReplicas，則等於 spec.specificReplicas.
  currentReplicas: 4       # currentReplicas 展示了 workload 實際的副本數。

實現原理：當 EHPA 處於預覽模式時，Ehpa-controller 會將底層的 HPA 對象指向一個 Substitute(替身) 對象，底層計算和執行彈性的 HPA 只會作用於替身，而實際的工作負載則不會被改變。

落地效果

目前 EHPA 已經在騰訊內部開始使用，支撐線上業務的彈性需求。這裡展示一個線上應用使用 EHPA 後的落地效果。

上圖顯示了該應用一天內的 CPU 使用。紅色曲線是實際使用量，綠色曲線是演算法預測出的使用量，可以看到演算法可以很好的預測出使用量的趨勢，並且根據參數實現一定的偏好（比如偏高）。

上圖顯示了該應用使用彈性後在一天內副本數的變化趨勢。紅色曲線是通過原生的 HPA 自動調整的副本數，而綠色曲線是通過 EHPA 自動調整的副本數，可以看到 EHPA 的彈性策略更加合理：提前彈和減少無效彈性。

衍生閱讀：什麼是 Crane

為推進雲原生用戶在確保業務穩定性的基礎上做到真正的極致降本，騰訊推出了業界第一個基於雲原生技術的成本優化開源項目 Crane（ Cloud Resource Analytics and Economics ）。Crane 遵循 FinOps 標準，旨在為雲原生用戶提供雲成本優化一站式解決方案。

Crane 的智慧水平彈性能力是基於 Effective HPA 實現。用戶在安裝 Crane 後即可直接使用 Effective HPA 開啟智慧彈性之旅。

當前 Crane 項目主要貢獻者包括有騰訊、小紅書、Google、eBay、微軟、特斯拉等知名公司的行業專家。

參考鏈接

Crane 開源項目地址：【//github.com/gocrane/crane/】
Crane 官網: 【//docs.gocrane.io/】
Effective HPA 使用文檔：【//docs.gocrane.io/dev/zh/tutorials/using-effective-hpa-to-scaling-with-effectiveness/】

關於我們

更多關於雲原生的案例和知識，可關注同名【騰訊雲原生】公眾號~

福利：

①公眾號後台回復【手冊】，可獲得《騰訊雲原生路線圖手冊》&《騰訊雲原生最佳實踐》~

②公眾號後台回復【系列】，可獲得《15個系列100+篇超實用雲原生原創乾貨合集》，包含Kubernetes 降本增效、K8s 性能優化實踐、最佳實踐等系列。

③公眾號後台回復【白皮書】，可獲得《騰訊雲容器安全白皮書》&《降本之源-雲原生成本管理白皮書v1.0》

④公眾號後台回復【光速入門】，可獲得騰訊雲專家5萬字精華教程，光速入門Prometheus和Grafana。

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多乾貨！！

Tags: docker istio k8s Kubernetes Prometheus TKE 雲原生雲計算容器騰訊雲原生