## 作者

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

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

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

## 引言

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

## 什麼是 HPA

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

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

## 傳統 HPA 的問題

HPA 也並不完美：

1. **如何配置**：HPA 執行的效果取決於使用者資源的配置（target、minReplicas、maxReplicas 等等）。配置過於激進可能導致應用可用性、穩定性受影響，配置過於保守彈性的效果就大打折扣。如何合理的配置是用好 HPA 的關鍵。

2. **彈性不夠及時**：原生 HPA 是對監控資料的被動響應，此外應用本身啟動、預熱也需要一定時間，這使得HPA天生具有滯後性，進而可能影響業務穩定。這也是很多使用者不信任、不敢用HPA的一個重要原因。

3. **可觀測性低**：HPA 沒法透過類似 Dryrun 方式測試，一旦使用便會實際修改應用的例項數量，存在風險；而且彈性過程也難以觀測。

## 時間序列預測

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

![](https://qcloudimg.tencent-cloud.cn/raw/0d6f3b1e609cd349011ce1316db2efa3.png)

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

## Effective HPA 是什麼

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

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

![](https://qcloudimg.tencent-cloud.cn/raw/b9b9910a0ac5f61da94679e114a8a384.png)

### 架構

EHPA 的主要架構如下：

![](https://qcloudimg.tencent-cloud.cn/raw/8b638ce1a6cf7d5b98ca9f2135f8a483.jpeg)

- 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 取最大值，所以並不會立即縮容，從而避免無效縮容。

使用者可以透過配置以下指標：
```yaml
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 設定如下：
```yaml
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 能力存在一些不足之處：

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

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

![](https://qcloudimg.tencent-cloud.cn/raw/63b2077ef54b2c0b2f3614c626122aab.jpeg)

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

#### 彈性結果預覽

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

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

```yaml
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 後的落地效果。

**![image](https://qcloudimg.tencent-cloud.cn/raw/2459fc50cacf2f08d35217be979e5d70.png)**

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

**![image](https://qcloudimg.tencent-cloud.cn/raw/3e729e571844346635997f25cf30caa8.png)**

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

## 衍生閱讀：什麼是 Crane

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

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

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

## 參考連結

1. Crane 開源專案地址：【https://github.com/gocrane/crane/】
2. Crane 官網: 【https://docs.gocrane.io/】
3. Effective HPA 使用文件：【https://docs.gocrane.io/dev/zh/tutorials/using-effective-hpa-to-scaling-with-effectiveness/】

## 關於我們

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

#### 福利：

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

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

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

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

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

相關文章