Hello folks，我是 Luga，今天我們來聊一下云原生生態領域相關的技術 - Auto Scaling ，即 “彈性伸縮” 。

在當今的云原生生態系統中，基于波動的工作負載和動態的流量模式已經成為常態，傳統的IT基礎設施面臨著巨大的挑戰。這種不可預測的行為使得我們需要重新思考基礎設施管理的方式。

與傳統的靜態基礎設施不同，現代云原生解決方案提供了更加靈活和自動化的彈性伸縮能力。通過運用容器化技術和編排工具，如 Kubernetes，我們可以根據負載需求的變化自動進行伸縮，實現資源的彈性調配。

一、什么是 Kubernetes Autoscaling ?

Kubernetes Autoscaling 是 Kubernetes 容器編排系統中的一項動態功能，可以根據工作負載需求自動調整計算資源。這一功能通過平衡和優化資源分配，既能維持應用程序的性能，又能避免財務浪費。通過增加資源來處理流量激增，確保最佳性能，并在空閑期間部署較少的資源以節省成本。

Kubernetes Autoscaling 的好處包括最大限度地提高資源利用率、提供成本效益以及保證應用程序的持續可用性。任何使用 Kubernetes 的組織都可以從 Autoscaling 中獲益，尤其是當應用程序在繁忙和空閑時期之間切換時。

Autoscaling 的關鍵優勢之一是提供了彈性和敏捷性，可以根據實際需求動態調整資源。當負載增加時，Autoscaling 能夠快速響應并自動擴展應用程序的副本數量，以滿足當前的需求。這種擴展能力可確保應用程序具備足夠的資源來處理高負載情況，從而避免性能瓶頸和用戶體驗下降。相反，在負載減少時，Autoscaling 可以自動縮減應用程序的副本數量，以節省成本并提高資源利用率。

此外，Autoscaling 還帶來了更好的成本效益。通過根據實際需求調整資源配置，可以避免不必要的資源浪費。在高峰期間，通過增加資源來滿足需求，可以確保最佳性能，但在空閑期間，可以減少資源并節省資金。這種動態的資源管理策略能夠實現資源的最佳利用，提高成本效益。

二、Kubernetes 原生 H/VPA Autoscaling 存在的弊端

盡管 Kubernetes 的 HPA(Horizontal Pod Autoscaler)和 VPA(Vertical Pod Autoscaler)提供了 Autoscaling 能力，但它們也存在一些潛在的瓶頸和限制，具體如下所示：

1. 延遲和響應時間

HPA 和 VPA 的 Autoscaling 過程需要一定的時間來監測指標并作出調整，從而可能會導致在負載突然增加或減少時出現一定的延遲，無法立即響應變化。這種延遲可能會導致性能下降或資源浪費。

2. 指標選擇和配置

同時，HPA 和 VPA 的 Autoscaling 依賴于指標的選擇和配置。選擇不合適的指標或錯誤地配置指標閾值可能導致擴縮容的不準確性。因此，正確選擇和配置指標是確保 Autoscaler 有效運行的重要因素。

3. 基礎設施強綁

HPA 和 VPA 依賴于底層基礎設施的可擴展性和彈性。如果底層基礎設施無法滿足自動擴縮容的需求，例如，底層節點資源有限或網絡帶寬不足，那么自動彈性伸縮的效果將受到限制。

4. 應用程序設計限制

在實際的業務場景中，往往存在某些應用程序可能不適合自動擴縮容，特別是具有持久性狀態或特定調度要求的應用程序。這些應用程序可能需要采取額外的措施來處理自動擴縮容引起的狀態管理或數據持久性問題。

5. 實施的復雜性

通常而言，為 H/VPA 創建自定義指標可能并非易事。這個過程需要對 Kubernetes 內部結構有一定的了解，并需要開發人員深入研究相關接口和進行復雜的代碼修改。因此，對于沒有相關經驗的開發人員來說，這可能是一個具有挑戰性的任務。從長遠角度來看，這種額外的復雜性可能會導致維護困難。

三、什么是 KEDA 以及 KEDA 解決了哪些痛點 ?

前面我們提到了 Kubernetes 內置提供的解決方案在開銷或實用性方面能力是非常有限的。如果我們想更優雅地擴展事件驅動的應用程序，此時，則需要另尋他路。或許，KEDA 是一種不可多得的選擇。

那么，KEDA 到底是什么?

KEDA(基于 Kubernetes 的事件驅動自動縮放器)是一個由微軟和紅帽創建的開源項目，目前已從云原生計算基金會(CNCF)畢業，采用 Apache 2.0 許可證。KEDA 的主要目標是為在 Kubernetes 上運行的事件驅動應用程序提供更好的擴展選項。

在目前的 Kubernetes 環境中，水平 Pod 自動縮放器(HPA)僅對基于資源的指標作出反應，例如 CPU 或內存使用情況，或者自定義指標。然而，對于那些可能經歷突發數據流的事件驅動應用程序來說，HPA 的擴展速度可能相當緩慢。此外，一旦數據流減緩，HPA必須縮小規模并刪除多余的 Pod，導致不必要的資源繼續產生費用。

KEDA 的出現填補了這一缺失，通過引入事件驅動的自動彈性伸縮機制，使得在 Kubernetes 上運行的事件驅動應用程序可以更加高效地擴展。KEDA 可以根據事件流的速率和規模動態地調整應用程序的副本數量，以滿足負載需求。這意味著在應用程序需要處理大量事件時，KEDA 可以快速擴展并自動添加 Pod 實例，以確保高吞吐量和低延遲。

另一個 KEDA 的優勢是它支持多種事件源，如 Azure 隊列、Kafka、RabbitMQ 等，使得應用程序能夠從不同來源接收事件。這為開發人員提供了更大的靈活性和選擇性，可以根據應用程序的需求選擇適當的事件源。

如下為基于 KEDA 使用 Prometheus 指標觸發 Autoscaling 機制的示例，具體：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: prometheus-scaledobject
  namespace: devops
spec:
  scaleTargetRef:
    apiVersion: argoproj.io/v1alpha1
    kind: Rollout
    name: keda-devops-demo
  triggers:
    - type: prometheus
      metadata:
      serverAddress:  http://<prometheus-host>:9090
      metricName: http_request_total
      query: envoy_cluster_upstream_rq{appId="300", cluster_name="300-0", container="envoy", namespace="demo3", response_code="200" }
      threshold: "50"
  idleReplicaCount: 0                       
  minReplicaCount: 1
  maxReplicaCount: 10

在上述 ScaledObject 對象和 KEDA 定義中，我們指定了一個 ScaledObject 的示例，使用 Prometheus 指標來配置 KEDA Autoscaling。部署對象“keda-devops-demo”將根據 Prometheus 指標“sum(irate(by_path_counter_total{}[60s]))”來監控 HTTP 請求的數量。如果該指標的值超過 50，則 KEDA 將根據需要創建新的 Pod 來處理請求。如果該指標的值低于 50，則 KEDA 將根據需要刪除多余的 Pod，以確保資源利用率的最大化。

該示例展示了如何使用 KEDA 來根據 Prometheus 指標來動態縮放應用程序的規模。KEDA 提供了靈活的配置選項，可以滿足不同的業務需求。

通過這種配置，系統能夠根據實際的 HTTP 請求負載情況來動態調整應用程序的規模。當負載增加時，Autoscaling 機制將創建更多的 Pod 來處理請求，從而保持應用程序的性能和可用性。一旦負載減輕，Autoscaling 機制便將適時地縮減 Pod 的數量，以節省資源和成本。

那么，KEDA 幫助 SRE 和 DevOps 團隊解決了哪些問題或痛點?如下為一些參考，具體：

1.降低成本

KEDA 在事件驅動應用程序的 Autoscaling 方面提供了更高的靈活性和精確性。它能夠根據事件的到達速率和規模來動態調整應用程序的副本數量，從而更好地適應不斷變化的負載情況。在沒有待處理的事件時，KEDA 具有將 Pod 數量減少到零的能力。相比之下，使用標準 HPA 很難實現這一點。這種功能對于確保資源的有效利用和成本優化非常有幫助，最終可以降低云計算費用。

2.提高可用性

截至目前，KEDA 已經支持了 59 個內置縮放器和 4 個外部縮放器。這些外部縮放器包括 KEDA HTTP 和 KEDA Scaler for Oracle DB 等。通過使用外部事件作為觸發器，KEDA 能夠實現高效的自動縮放，尤其適用于消息驅動的微服務，如支付網關或訂單系統。

此外，由于 KEDA 的靈活性，可以無縫融入任何 DevOps 工具鏈。無論我們使用的是 Jenkins、GitLab、Prometheus 還是其他 DevOps 工具，KEDA 可以與之進行集成，使得 Autoscaling 成為整個開發和部署流程的一部分。這樣，我們可以在保持流程的連續性和一致性的同時，充分利用 KEDA 的自動擴縮容能力，實現高效的應用程序管理。

3.提升性能

借助 KEDA，SRE 和 DevOps 團隊可以根據負載波動情況來動態調整應用程序的資源配置。通過快速響應和自動擴縮容的能力，KEDA 確保應用程序始終具備足夠的資源來應對負載變化，從而保持系統高性能運行。同時，監控和指標收集功能使得 SRE 和 DevOps 團隊能夠實時監測和優化應用程序的性能。

四、KEDA 是如何工作的 ?

作為 Kubernetes 的事件驅動 Autoscaling 工具，KEDA 可以根據應用程序的事件源來自動調整 Pod 的數量。KEDA 部署簡單，只需在 Kubernetes 集群中創建一個 ScaledObject 對象即可。ScaledObject 對象包含 KEDA 的配置信息，包括事件源、縮放規則等。

在部署 KEDA 后，縮放器將會像一個哨兵一樣，持續監視事件源，并在發生任何觸發事件時將指標傳遞給指標適配器。指標適配器會像一個翻譯員一樣，將指標調整為控制器組件可以理解的格式，并將其提供給控制器組件。控制器組件會根據 ScaledObject 中設置的擴展規則來做出擴大或縮小的決策，并將決策執行到 Pod 上。

通常來講，KEDA 與 Kubernetes 水平 Pod 自動縮放器(Horizontal Pod Autoscaler，HPA)、外部事件源以及 Kubernetes 的數據存儲之間的協作關系，可參考如下圖所示：

上述參考流程圖描述了 KEDA 如何與 HPA 配合應用 Pod 進行自動彈性伸縮，這里，針對此實現架構圖進行簡要解析，具體實現流程如下：

• Kubernetes API Server 充當 KEDA 和 Kubernetes 之間集成的橋梁，將 KEDA 的自動彈性伸縮功能與 Kubernetes 的資源管理功能相結合。KEDA 通過 ScaledObject 對象將自動彈性伸縮的機制與 Kubernetes 資源對象相結合。KEDA 的核心組件包括指標適配器、控制器、縮放器和準入 Webhooks。
• Metrics Adapter 和準入 Webhooks 從外部觸發源收集指標，具體取決于 ScaledObject 對象中定義的觸發器類型。Metrics Adapter 將指標轉換為 Kubernetes 指標，并將其暴露給 Controller。準入 Webhooks 負責驗證和修改 ScaledObject 對象，以確保 KEDA 能夠正確地進行自動彈性伸縮。
• Controller 和 Scaler 負責根據 Metrics Adapter 收集的指標來進行自動彈性伸縮。Controller 負責將彈性任務發送給 Scaler。Scaler 負責將縮放任務應用到 Kubernetes 資源對象。
• 外部觸發源可以是任何可以提供指標數據的來源，例如 Apache Kafka、Prometheus、AWS CloudWatch 等。外部觸發源負責直接從正在運行的服務收集系統指標。如果工作負載很高，Pod 將會被橫向擴展。如果工作負載較低，則對 Pod 進行縮容。如果完全沒有工作負載，則將刪除 Pod，以最終優化基礎設施資源。

通常而言，KEDA 核心由三個關鍵組成部分組成，具體涉及如下：

1.Metrics Adapter

KEDA 中的 Metrics Adapter 是負責將事件數據轉換為 Kubernetes 指標的組件。Metrics Adapter 采用了“事件驅動”的設計理念，將事件數據轉換為 Kubernetes 指標，并通過 Kubernetes 的 API Server 暴露給水平 Pod 自動縮放器。

2.Admission Webhooks

KEDA 中的 Admission Webhooks 是負責驗證和修改 Kubernetes 對象的組件。Admission Webhooks 可以用于驗證和修改 ScaledObject 對象，以確保 KEDA 能夠正確地進行自動縮放。

KEDA 提供了兩種 Admission Webhook 聯系，一種是用于驗證和修改 ScaledObject 對象的 ScaledObject Admission Webhook 類型，另一種則是用于驗證和修改 Trigger 對象的 Trigger Admission Webhook 類型。

3.Agent

KEDA 中的 Agent 是負責監控事件源并將事件數據傳遞給 KEDA 控制器的組件。KEDA 提供了多種 Agent，可以滿足不同的事件源需求。通常情況下，在沒有事件的情況下，Agent 組件會將部署調整至零副本，以免浪費資源。

在不斷發展的云原生應用程序環境中，適應動態工作負載是至關重要的。Kubernetes 提供了 HPA 和 VPA 等本機工具來實現自動縮放，但它們在應對非 CPU 和 RAM 指標驅動的負載時存在局限性。

KEDA 是 Kubernetes 的擴展，克服了 HPA 和 VPA 的局限性，并提供了更靈活和全面的自動縮放解決方案。KEDA 可以根據任何指標進行縮放，包括 HTTP 請求數、消息隊列長度、數據庫連接數等。此外，KEDA 還支持縮小到零、觸發 Kubernetes Job、發出用于診斷的實時事件以及通過身份驗證提供程序維護安全連接。

與 HPA 和 VPA 相比，KEDA 具有以下優勢：

• 更靈活：KEDA 可以根據任何指標進行縮放，而 HPA 和 VPA 僅限于 CPU 和 RAM 指標。
• 更全面：KEDA 支持縮小到零、觸發 Kubernetes Job、發出用于診斷的實時事件以及通過身份驗證提供程序維護安全連接。
• 更易于使用：KEDA 的配置更簡單，減少了用戶在使用 Kubernetes 自定義指標時面臨的典型障礙。

以上為 KEDA 的相關解析，更多內容可參考后續文章所述，謝謝!

Reference ：[1] https://keda.sh/docs/2.12/concepts/