Hello folks，我是 Luga，今天我們來聊一下云原生生態(tài)領(lǐng)域相關(guān)的技術(shù) - Auto Scaling ，即 “彈性伸縮” 。

在當(dāng)今的云原生生態(tài)系統(tǒng)中，基于波動(dòng)的工作負(fù)載和動(dòng)態(tài)的流量模式已經(jīng)成為常態(tài)，傳統(tǒng)的IT基礎(chǔ)設(shè)施面臨著巨大的挑戰(zhàn)。這種不可預(yù)測(cè)的行為使得我們需要重新思考基礎(chǔ)設(shè)施管理的方式。

與傳統(tǒng)的靜態(tài)基礎(chǔ)設(shè)施不同，現(xiàn)代云原生解決方案提供了更加靈活和自動(dòng)化的彈性伸縮能力。通過運(yùn)用容器化技術(shù)和編排工具，如 Kubernetes，我們可以根據(jù)負(fù)載需求的變化自動(dòng)進(jìn)行伸縮，實(shí)現(xiàn)資源的彈性調(diào)配。

一、什么是 Kubernetes Autoscaling ?

Kubernetes Autoscaling 是 Kubernetes 容器編排系統(tǒng)中的一項(xiàng)動(dòng)態(tài)功能，可以根據(jù)工作負(fù)載需求自動(dòng)調(diào)整計(jì)算資源。這一功能通過平衡和優(yōu)化資源分配，既能維持應(yīng)用程序的性能，又能避免財(cái)務(wù)浪費(fèi)。通過增加資源來處理流量激增，確保最佳性能，并在空閑期間部署較少的資源以節(jié)省成本。

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

Autoscaling 的關(guān)鍵優(yōu)勢(shì)之一是提供了彈性和敏捷性，可以根據(jù)實(shí)際需求動(dòng)態(tài)調(diào)整資源。當(dāng)負(fù)載增加時(shí)，Autoscaling 能夠快速響應(yīng)并自動(dòng)擴(kuò)展應(yīng)用程序的副本數(shù)量，以滿足當(dāng)前的需求。這種擴(kuò)展能力可確保應(yīng)用程序具備足夠的資源來處理高負(fù)載情況，從而避免性能瓶頸和用戶體驗(yàn)下降。相反，在負(fù)載減少時(shí)，Autoscaling 可以自動(dòng)縮減應(yīng)用程序的副本數(shù)量，以節(jié)省成本并提高資源利用率。

此外，Autoscaling 還帶來了更好的成本效益。通過根據(jù)實(shí)際需求調(diào)整資源配置，可以避免不必要的資源浪費(fèi)。在高峰期間，通過增加資源來滿足需求，可以確保最佳性能，但在空閑期間，可以減少資源并節(jié)省資金。這種動(dòng)態(tài)的資源管理策略能夠?qū)崿F(xiàn)資源的最佳利用，提高成本效益。

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

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

1. 延遲和響應(yīng)時(shí)間

HPA 和 VPA 的 Autoscaling 過程需要一定的時(shí)間來監(jiān)測(cè)指標(biāo)并作出調(diào)整，從而可能會(huì)導(dǎo)致在負(fù)載突然增加或減少時(shí)出現(xiàn)一定的延遲，無法立即響應(yīng)變化。這種延遲可能會(huì)導(dǎo)致性能下降或資源浪費(fèi)。

2. 指標(biāo)選擇和配置

同時(shí)，HPA 和 VPA 的 Autoscaling 依賴于指標(biāo)的選擇和配置。選擇不合適的指標(biāo)或錯(cuò)誤地配置指標(biāo)閾值可能導(dǎo)致擴(kuò)縮容的不準(zhǔn)確性。因此，正確選擇和配置指標(biāo)是確保 Autoscaler 有效運(yùn)行的重要因素。

3. 基礎(chǔ)設(shè)施強(qiáng)綁

HPA 和 VPA 依賴于底層基礎(chǔ)設(shè)施的可擴(kuò)展性和彈性。如果底層基礎(chǔ)設(shè)施無法滿足自動(dòng)擴(kuò)縮容的需求，例如，底層節(jié)點(diǎn)資源有限或網(wǎng)絡(luò)帶寬不足，那么自動(dòng)彈性伸縮的效果將受到限制。

4. 應(yīng)用程序設(shè)計(jì)限制

在實(shí)際的業(yè)務(wù)場(chǎng)景中，往往存在某些應(yīng)用程序可能不適合自動(dòng)擴(kuò)縮容，特別是具有持久性狀態(tài)或特定調(diào)度要求的應(yīng)用程序。這些應(yīng)用程序可能需要采取額外的措施來處理自動(dòng)擴(kuò)縮容引起的狀態(tài)管理或數(shù)據(jù)持久性問題。

5. 實(shí)施的復(fù)雜性

通常而言，為 H/VPA 創(chuàng)建自定義指標(biāo)可能并非易事。這個(gè)過程需要對(duì) Kubernetes 內(nèi)部結(jié)構(gòu)有一定的了解，并需要開發(fā)人員深入研究相關(guān)接口和進(jìn)行復(fù)雜的代碼修改。因此，對(duì)于沒有相關(guān)經(jīng)驗(yàn)的開發(fā)人員來說，這可能是一個(gè)具有挑戰(zhàn)性的任務(wù)。從長(zhǎng)遠(yuǎn)角度來看，這種額外的復(fù)雜性可能會(huì)導(dǎo)致維護(hù)困難。

三、什么是 KEDA 以及 KEDA 解決了哪些痛點(diǎn) ?

前面我們提到了 Kubernetes 內(nèi)置提供的解決方案在開銷或?qū)嵱眯苑矫婺芰κ欠浅Ｓ邢薜摹Ｈ绻覀兿敫鼉?yōu)雅地?cái)U(kuò)展事件驅(qū)動(dòng)的應(yīng)用程序，此時(shí)，則需要另尋他路。或許，KEDA 是一種不可多得的選擇。

那么，KEDA 到底是什么?

KEDA(基于 Kubernetes 的事件驅(qū)動(dòng)自動(dòng)縮放器)是一個(gè)由微軟和紅帽創(chuàng)建的開源項(xiàng)目，目前已從云原生計(jì)算基金會(huì)(CNCF)畢業(yè)，采用 Apache 2.0 許可證。KEDA 的主要目標(biāo)是為在 Kubernetes 上運(yùn)行的事件驅(qū)動(dòng)應(yīng)用程序提供更好的擴(kuò)展選項(xiàng)。

在目前的 Kubernetes 環(huán)境中，水平 Pod 自動(dòng)縮放器(HPA)僅對(duì)基于資源的指標(biāo)作出反應(yīng)，例如 CPU 或內(nèi)存使用情況，或者自定義指標(biāo)。然而，對(duì)于那些可能經(jīng)歷突發(fā)數(shù)據(jù)流的事件驅(qū)動(dòng)應(yīng)用程序來說，HPA 的擴(kuò)展速度可能相當(dāng)緩慢。此外，一旦數(shù)據(jù)流減緩，HPA必須縮小規(guī)模并刪除多余的 Pod，導(dǎo)致不必要的資源繼續(xù)產(chǎn)生費(fèi)用。

KEDA 的出現(xiàn)填補(bǔ)了這一缺失，通過引入事件驅(qū)動(dòng)的自動(dòng)彈性伸縮機(jī)制，使得在 Kubernetes 上運(yùn)行的事件驅(qū)動(dòng)應(yīng)用程序可以更加高效地?cái)U(kuò)展。KEDA 可以根據(jù)事件流的速率和規(guī)模動(dòng)態(tài)地調(diào)整應(yīng)用程序的副本數(shù)量，以滿足負(fù)載需求。這意味著在應(yīng)用程序需要處理大量事件時(shí)，KEDA 可以快速擴(kuò)展并自動(dòng)添加 Pod 實(shí)例，以確保高吞吐量和低延遲。

另一個(gè) KEDA 的優(yōu)勢(shì)是它支持多種事件源，如 Azure 隊(duì)列、Kafka、RabbitMQ 等，使得應(yīng)用程序能夠從不同來源接收事件。這為開發(fā)人員提供了更大的靈活性和選擇性，可以根據(jù)應(yīng)用程序的需求選擇適當(dāng)?shù)氖录础?/p>

如下為基于 KEDA 使用 Prometheus 指標(biāo)觸發(fā) Autoscaling 機(jī)制的示例，具體：

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 對(duì)象和 KEDA 定義中，我們指定了一個(gè) ScaledObject 的示例，使用 Prometheus 指標(biāo)來配置 KEDA Autoscaling。部署對(duì)象“keda-devops-demo”將根據(jù) Prometheus 指標(biāo)“sum(irate(by_path_counter_total{}[60s]))”來監(jiān)控 HTTP 請(qǐng)求的數(shù)量。如果該指標(biāo)的值超過 50，則 KEDA 將根據(jù)需要?jiǎng)?chuàng)建新的 Pod 來處理請(qǐng)求。如果該指標(biāo)的值低于 50，則 KEDA 將根據(jù)需要?jiǎng)h除多余的 Pod，以確保資源利用率的最大化。

該示例展示了如何使用 KEDA 來根據(jù) Prometheus 指標(biāo)來動(dòng)態(tài)縮放應(yīng)用程序的規(guī)模。KEDA 提供了靈活的配置選項(xiàng)，可以滿足不同的業(yè)務(wù)需求。

通過這種配置，系統(tǒng)能夠根據(jù)實(shí)際的 HTTP 請(qǐng)求負(fù)載情況來動(dòng)態(tài)調(diào)整應(yīng)用程序的規(guī)模。當(dāng)負(fù)載增加時(shí)，Autoscaling 機(jī)制將創(chuàng)建更多的 Pod 來處理請(qǐng)求，從而保持應(yīng)用程序的性能和可用性。一旦負(fù)載減輕，Autoscaling 機(jī)制便將適時(shí)地縮減 Pod 的數(shù)量，以節(jié)省資源和成本。

那么，KEDA 幫助 SRE 和 DevOps 團(tuán)隊(duì)解決了哪些問題或痛點(diǎn)?如下為一些參考，具體：

1.降低成本

KEDA 在事件驅(qū)動(dòng)應(yīng)用程序的 Autoscaling 方面提供了更高的靈活性和精確性。它能夠根據(jù)事件的到達(dá)速率和規(guī)模來動(dòng)態(tài)調(diào)整應(yīng)用程序的副本數(shù)量，從而更好地適應(yīng)不斷變化的負(fù)載情況。在沒有待處理的事件時(shí)，KEDA 具有將 Pod 數(shù)量減少到零的能力。相比之下，使用標(biāo)準(zhǔn) HPA 很難實(shí)現(xiàn)這一點(diǎn)。這種功能對(duì)于確保資源的有效利用和成本優(yōu)化非常有幫助，最終可以降低云計(jì)算費(fèi)用。

2.提高可用性

截至目前，KEDA 已經(jīng)支持了 59 個(gè)內(nèi)置縮放器和 4 個(gè)外部縮放器。這些外部縮放器包括 KEDA HTTP 和 KEDA Scaler for Oracle DB 等。通過使用外部事件作為觸發(fā)器，KEDA 能夠?qū)崿F(xiàn)高效的自動(dòng)縮放，尤其適用于消息驅(qū)動(dòng)的微服務(wù)，如支付網(wǎng)關(guān)或訂單系統(tǒng)。

此外，由于 KEDA 的靈活性，可以無縫融入任何 DevOps 工具鏈。無論我們使用的是 Jenkins、GitLab、Prometheus 還是其他 DevOps 工具，KEDA 可以與之進(jìn)行集成，使得 Autoscaling 成為整個(gè)開發(fā)和部署流程的一部分。這樣，我們可以在保持流程的連續(xù)性和一致性的同時(shí)，充分利用 KEDA 的自動(dòng)擴(kuò)縮容能力，實(shí)現(xiàn)高效的應(yīng)用程序管理。

3.提升性能

借助 KEDA，SRE 和 DevOps 團(tuán)隊(duì)可以根據(jù)負(fù)載波動(dòng)情況來動(dòng)態(tài)調(diào)整應(yīng)用程序的資源配置。通過快速響應(yīng)和自動(dòng)擴(kuò)縮容的能力，KEDA 確保應(yīng)用程序始終具備足夠的資源來應(yīng)對(duì)負(fù)載變化，從而保持系統(tǒng)高性能運(yùn)行。同時(shí)，監(jiān)控和指標(biāo)收集功能使得 SRE 和 DevOps 團(tuán)隊(duì)能夠?qū)崟r(shí)監(jiān)測(cè)和優(yōu)化應(yīng)用程序的性能。

四、KEDA 是如何工作的 ?

作為 Kubernetes 的事件驅(qū)動(dòng) Autoscaling 工具，KEDA 可以根據(jù)應(yīng)用程序的事件源來自動(dòng)調(diào)整 Pod 的數(shù)量。KEDA 部署簡(jiǎn)單，只需在 Kubernetes 集群中創(chuàng)建一個(gè) ScaledObject 對(duì)象即可。ScaledObject 對(duì)象包含 KEDA 的配置信息，包括事件源、縮放規(guī)則等。

在部署 KEDA 后，縮放器將會(huì)像一個(gè)哨兵一樣，持續(xù)監(jiān)視事件源，并在發(fā)生任何觸發(fā)事件時(shí)將指標(biāo)傳遞給指標(biāo)適配器。指標(biāo)適配器會(huì)像一個(gè)翻譯員一樣，將指標(biāo)調(diào)整為控制器組件可以理解的格式，并將其提供給控制器組件。控制器組件會(huì)根據(jù) ScaledObject 中設(shè)置的擴(kuò)展規(guī)則來做出擴(kuò)大或縮小的決策，并將決策執(zhí)行到 Pod 上。

通常來講，KEDA 與 Kubernetes 水平 Pod 自動(dòng)縮放器(Horizontal Pod Autoscaler，HPA)、外部事件源以及 Kubernetes 的數(shù)據(jù)存儲(chǔ)之間的協(xié)作關(guān)系，可參考如下圖所示：

上述參考流程圖描述了 KEDA 如何與 HPA 配合應(yīng)用 Pod 進(jìn)行自動(dòng)彈性伸縮，這里，針對(duì)此實(shí)現(xiàn)架構(gòu)圖進(jìn)行簡(jiǎn)要解析，具體實(shí)現(xiàn)流程如下：

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

通常而言，KEDA 核心由三個(gè)關(guān)鍵組成部分組成，具體涉及如下：

1.Metrics Adapter

KEDA 中的 Metrics Adapter 是負(fù)責(zé)將事件數(shù)據(jù)轉(zhuǎn)換為 Kubernetes 指標(biāo)的組件。Metrics Adapter 采用了“事件驅(qū)動(dòng)”的設(shè)計(jì)理念，將事件數(shù)據(jù)轉(zhuǎn)換為 Kubernetes 指標(biāo)，并通過 Kubernetes 的 API Server 暴露給水平 Pod 自動(dòng)縮放器。

2.Admission Webhooks

KEDA 中的 Admission Webhooks 是負(fù)責(zé)驗(yàn)證和修改 Kubernetes 對(duì)象的組件。Admission Webhooks 可以用于驗(yàn)證和修改 ScaledObject 對(duì)象，以確保 KEDA 能夠正確地進(jìn)行自動(dòng)縮放。

KEDA 提供了兩種 Admission Webhook 聯(lián)系，一種是用于驗(yàn)證和修改 ScaledObject 對(duì)象的 ScaledObject Admission Webhook 類型，另一種則是用于驗(yàn)證和修改 Trigger 對(duì)象的 Trigger Admission Webhook 類型。

3.Agent

KEDA 中的 Agent 是負(fù)責(zé)監(jiān)控事件源并將事件數(shù)據(jù)傳遞給 KEDA 控制器的組件。KEDA 提供了多種 Agent，可以滿足不同的事件源需求。通常情況下，在沒有事件的情況下，Agent 組件會(huì)將部署調(diào)整至零副本，以免浪費(fèi)資源。

在不斷發(fā)展的云原生應(yīng)用程序環(huán)境中，適應(yīng)動(dòng)態(tài)工作負(fù)載是至關(guān)重要的。Kubernetes 提供了 HPA 和 VPA 等本機(jī)工具來實(shí)現(xiàn)自動(dòng)縮放，但它們?cè)趹?yīng)對(duì)非 CPU 和 RAM 指標(biāo)驅(qū)動(dòng)的負(fù)載時(shí)存在局限性。

KEDA 是 Kubernetes 的擴(kuò)展，克服了 HPA 和 VPA 的局限性，并提供了更靈活和全面的自動(dòng)縮放解決方案。KEDA 可以根據(jù)任何指標(biāo)進(jìn)行縮放，包括 HTTP 請(qǐng)求數(shù)、消息隊(duì)列長(zhǎng)度、數(shù)據(jù)庫連接數(shù)等。此外，KEDA 還支持縮小到零、觸發(fā) Kubernetes Job、發(fā)出用于診斷的實(shí)時(shí)事件以及通過身份驗(yàn)證提供程序維護(hù)安全連接。

與 HPA 和 VPA 相比，KEDA 具有以下優(yōu)勢(shì)：

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

以上為 KEDA 的相關(guān)解析，更多內(nèi)容可參考后續(xù)文章所述，謝謝!

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