天天看點

Kubernetes 事件驅動彈性伸縮最佳實踐-認識 KEDA

作者:不秃頭程式員
Kubernetes 事件驅動彈性伸縮最佳實踐-認識 KEDA

什麼是 KEDA ?

KEDA (Kubernetes-based Event-Driven Autoscaler) 是在 Kubernetes 中事件驅動的彈性伸縮器,功能非常強大。不僅支援根據基礎的 CPU 和記憶體名額進行伸縮,還支援根據各種消息隊列中的長度、資料庫中的資料統計、QPS、Cron 定時計劃以及您可以想象的任何其他名額進行伸縮,甚至還可以将副本縮到 0。

該項目于 2020.3 被 CNCF 接收,2021.8 開始孵化,最後在 2023.8 宣布畢業,目前已經非常成熟,可放心在生産環境中使用。

為什麼需要 KEDA ?

HPA 是 Kubernetes 自帶的 Pod 水準自動伸縮器,隻能根據監控名額對工作負載自動擴縮容,名額主要是工作負載的 CPU 和記憶體的使用率(Resource Metrics),如果需要支援其它自定義名額,一般是安裝 prometheus-adapter 來作為 HPA 的 Custom Metrics 和 External Metrics 的實作來将 Prometheus 中的監控資料作為自定義名額提供給 HPA。理論上,用 HPA + prometheus-adapter 也能實作 KEDA 的功能,但實作上會非常麻煩,比如想要根據資料庫中任務表裡記錄的待執行的任務數量統計進行伸縮,就需要編寫并部署 Exporter 應用,将統計結果轉換為 Metrics 暴露給 Prometheus 進行采集,然後 prometheus-adapter 再從 Prometheus 查詢待執行的任務數量名額來決定是否伸縮。

KEDA 的出現主要是為了解決 HPA 無法基于靈活的事件源進行伸縮的這個問題,内置了幾十種常見的 Scaler ,可直接跟各種第三方應用對接,比如各種開源和雲托管的關系型資料庫、時序資料庫、文檔資料庫、鍵值存儲、消息隊列、事件總線等,也可以使用 Cron 表達式進行定時自動伸縮,常見的伸縮常見基本都涵蓋了,如果發現有不支援的,還可以自己實作一個外部 Scaler 來配合 KEDA 使用。

KEDA 的原理

KEDA 并不是要替代 HPA,而是作為 HPA 的補充或者增強,事實上很多時候 KEDA 是配合 HPA 一起工作的,這是 KEDA 官方的架構圖:

Kubernetes 事件驅動彈性伸縮最佳實踐-認識 KEDA
  • 當要将工作負載的副本數縮到閑時副本數,或從閑時副本數擴容時,由 KEDA 通過修改工作負載的副本數實作(閑時副本數小于 minReplicaCount,包括 0,即可以縮到 0)。
  • 其它情況下的擴縮容由 HPA 實作,HPA 由 KEDA 自動管理,HPA 使用 External Metrics 作為資料源,而 External Metrics 後端的資料由 KEDA 提供。
  • KEDA 各種 Scalers 的核心其實就是為 HPA 暴露 External Metrics 格式的資料,KEDA 會将各種外部事件轉換為所需的 External Metrics 資料,最終實作 HPA 通過 External Metrics 資料進行自動伸縮,直接複用了 HPA 已有的能力,是以如果還想要控制擴縮容的行為細節(比如快速擴容,緩慢縮容),可以直接通過配置 HPA 的 behavior 字段來實作 (要求 Kubernetes 版本 >= 1.18)。

除了工作負載的擴縮容,對于任務計算類場景,KEDA 還可以根據排隊的任務數量自動建立 Job 來實作對任務的及時處理:

Kubernetes 事件驅動彈性伸縮最佳實踐-認識 KEDA

哪些場景适合使用 KEDA ?

下面羅列下适合使用 KEDA 的場景。

微服務多級調用

在微服務中,基本都存在多級調用的業務場景,壓力是逐級傳遞的,下面展示了一個常見的情況:

Kubernetes 事件驅動彈性伸縮最佳實踐-認識 KEDA

如果使用傳統的 HPA 根據負載擴縮容,使用者流量進入叢集後:

  1. Deploy A 負載升高,名額變化迫使 Deploy A 擴容。
  2. A 擴容之後,吞吐量變大,B 受到壓力,再次采集到名額變化,擴容 Deploy B。
  3. B 吞吐變大,C 受到壓力,擴容 Deploy C。

這個逐級傳遞的過程不僅緩慢,還很危險:每一級的擴容都是直接被 CPU 或記憶體的飙高觸發的,被 “沖垮” 的可能性是普遍存在的。這種被動、滞後的方式,很明顯是有問題的。

此時,我們可以利用 KEDA 來實作多級快速擴容:

  • Deploy A 可根據自身負載或網關記錄的 QPS 等名額擴縮容。
  • Deploy B 和 Deploy C 可根據 Deploy A 副本數擴縮容(各級服務副本數保持一定比例)。

任務執行(生産者與消費者)

如果有需要長時間執行的計算任務,如資料分析、ETL、機器學習等場景,從消息隊列或資料庫中取任務進行執行,需要根據任務數量來伸縮,使用 HPA 不太合适,用 KEDA 就非常友善,可以讓 KEDA 根據排隊中的任務數量對工作負載進行伸縮,也可以自動建立 Job 來消費任務。

Kubernetes 事件驅動彈性伸縮最佳實踐-認識 KEDA

周期性規律

如果業務有周期性的波峰波谷特征,可以使用 KEDA 配置定時伸縮,在波峰來臨之前先提前擴容,結束之後再緩慢縮容。