建站
咨詢
售后
建站咨詢
新聞中心
Hello folks，我是 Luga，今天我們來聊一下云原生生態(tài)領(lǐng)域相關(guān)的技術(shù) - Auto Scaling ，即 “彈性伸縮” 。
十載專注成都網(wǎng)站制作，企業(yè)網(wǎng)站建設(shè)，個人網(wǎng)站制作服務(wù)，為大家分享網(wǎng)站制作知識、方案，網(wǎng)站設(shè)計流程、步驟,成功服務(wù)上千家企業(yè)。為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁設(shè)計及定制高端網(wǎng)站建設(shè)服務(wù),專注于企業(yè)網(wǎng)站建設(shè),高端網(wǎng)頁制作,對主動防護(hù)網(wǎng)等多個領(lǐng)域，擁有多年建站經(jīng)驗。
在當(dāng)今的云原生生態(tài)系統(tǒng)中，基于波動的工作負(fù)載和動態(tài)的流量模式已經(jīng)成為常態(tài)，傳統(tǒng)的IT基礎(chǔ)設(shè)施面臨著巨大的挑戰(zhàn)。這種不可預(yù)測的行為使得我們需要重新思考基礎(chǔ)設(shè)施管理的方式。
與傳統(tǒng)的靜態(tài)基礎(chǔ)設(shè)施不同，現(xiàn)代云原生解決方案提供了更加靈活和自動化的彈性伸縮能力。通過運用容器化技術(shù)和編排工具，如 Kubernetes，我們可以根據(jù)負(fù)載需求的變化自動進(jìn)行伸縮，實現(xiàn)資源的彈性調(diào)配。
一、什么是 Kubernetes Autoscaling ?
Kubernetes Autoscaling 是 Kubernetes 容器編排系統(tǒng)中的一項動態(tài)功能，可以根據(jù)工作負(fù)載需求自動調(diào)整計算資源。這一功能通過平衡和優(yōu)化資源分配，既能維持應(yīng)用程序的性能，又能避免財務(wù)浪費。通過增加資源來處理流量激增，確保最佳性能，并在空閑期間部署較少的資源以節(jié)省成本。
Kubernetes Autoscaling 的好處包括最大限度地提高資源利用率、提供成本效益以及保證應(yīng)用程序的持續(xù)可用性。任何使用 Kubernetes 的組織都可以從 Autoscaling 中獲益，尤其是當(dāng)應(yīng)用程序在繁忙和空閑時期之間切換時。
Autoscaling 的關(guān)鍵優(yōu)勢之一是提供了彈性和敏捷性，可以根據(jù)實際需求動態(tài)調(diào)整資源。當(dāng)負(fù)載增加時，Autoscaling 能夠快速響應(yīng)并自動擴(kuò)展應(yīng)用程序的副本數(shù)量，以滿足當(dāng)前的需求。這種擴(kuò)展能力可確保應(yīng)用程序具備足夠的資源來處理高負(fù)載情況，從而避免性能瓶頸和用戶體驗下降。相反，在負(fù)載減少時，Autoscaling 可以自動縮減應(yīng)用程序的副本數(shù)量，以節(jié)省成本并提高資源利用率。
此外，Autoscaling 還帶來了更好的成本效益。通過根據(jù)實際需求調(diào)整資源配置，可以避免不必要的資源浪費。在高峰期間，通過增加資源來滿足需求，可以確保最佳性能，但在空閑期間，可以減少資源并節(jié)省資金。這種動態(tài)的資源管理策略能夠?qū)崿F(xiàn)資源的最佳利用，提高成本效益。
二、Kubernetes 原生 H/VPA Autoscaling 存在的弊端
盡管 Kubernetes 的 HPA(Horizontal Pod Autoscaler)和 VPA(Vertical Pod Autoscaler)提供了 Autoscaling 能力，但它們也存在一些潛在的瓶頸和限制，具體如下所示：
1. 延遲和響應(yīng)時間
HPA 和 VPA 的 Autoscaling 過程需要一定的時間來監(jiān)測指標(biāo)并作出調(diào)整，從而可能會導(dǎo)致在負(fù)載突然增加或減少時出現(xiàn)一定的延遲，無法立即響應(yīng)變化。這種延遲可能會導(dǎo)致性能下降或資源浪費。
2. 指標(biāo)選擇和配置
同時，HPA 和 VPA 的 Autoscaling 依賴于指標(biāo)的選擇和配置。選擇不合適的指標(biāo)或錯誤地配置指標(biāo)閾值可能導(dǎo)致擴(kuò)縮容的不準(zhǔn)確性。因此，正確選擇和配置指標(biāo)是確保 Autoscaler 有效運行的重要因素。
3. 基礎(chǔ)設(shè)施強(qiáng)綁
HPA 和 VPA 依賴于底層基礎(chǔ)設(shè)施的可擴(kuò)展性和彈性。如果底層基礎(chǔ)設(shè)施無法滿足自動擴(kuò)縮容的需求，例如，底層節(jié)點資源有限或網(wǎng)絡(luò)帶寬不足，那么自動彈性伸縮的效果將受到限制。
4. 應(yīng)用程序設(shè)計限制
在實際的業(yè)務(wù)場景中，往往存在某些應(yīng)用程序可能不適合自動擴(kuò)縮容，特別是具有持久性狀態(tài)或特定調(diào)度要求的應(yīng)用程序。這些應(yīng)用程序可能需要采取額外的措施來處理自動擴(kuò)縮容引起的狀態(tài)管理或數(shù)據(jù)持久性問題。
5. 實施的復(fù)雜性
通常而言，為 H/VPA 創(chuàng)建自定義指標(biāo)可能并非易事。這個過程需要對 Kubernetes 內(nèi)部結(jié)構(gòu)有一定的了解，并需要開發(fā)人員深入研究相關(guān)接口和進(jìn)行復(fù)雜的代碼修改。因此，對于沒有相關(guān)經(jīng)驗的開發(fā)人員來說，這可能是一個具有挑戰(zhàn)性的任務(wù)。從長遠(yuǎn)角度來看，這種額外的復(fù)雜性可能會導(dǎo)致維護(hù)困難。
三、什么是 KEDA 以及 KEDA 解決了哪些痛點 ?
前面我們提到了 Kubernetes 內(nèi)置提供的解決方案在開銷或?qū)嵱眯苑矫婺芰κ欠浅Ｓ邢薜摹Ｈ绻覀兿敫鼉?yōu)雅地擴(kuò)展事件驅(qū)動的應(yīng)用程序，此時，則需要另尋他路?；蛟S，KEDA 是一種不可多得的選擇。
那么，KEDA 到底是什么?
KEDA(基于 Kubernetes 的事件驅(qū)動自動縮放器)是一個由微軟和紅帽創(chuàng)建的開源項目，目前已從云原生計算基金會(CNCF)畢業(yè)，采用 Apache 2.0 許可證。KEDA 的主要目標(biāo)是為在 Kubernetes 上運行的事件驅(qū)動應(yīng)用程序提供更好的擴(kuò)展選項。
在目前的 Kubernetes 環(huán)境中，水平 Pod 自動縮放器(HPA)僅對基于資源的指標(biāo)作出反應(yīng)，例如 CPU 或內(nèi)存使用情況，或者自定義指標(biāo)。然而，對于那些可能經(jīng)歷突發(fā)數(shù)據(jù)流的事件驅(qū)動應(yīng)用程序來說，HPA 的擴(kuò)展速度可能相當(dāng)緩慢。此外，一旦數(shù)據(jù)流減緩，HPA必須縮小規(guī)模并刪除多余的 Pod，導(dǎo)致不必要的資源繼續(xù)產(chǎn)生費用。
KEDA 的出現(xiàn)填補(bǔ)了這一缺失，通過引入事件驅(qū)動的自動彈性伸縮機(jī)制，使得在 Kubernetes 上運行的事件驅(qū)動應(yīng)用程序可以更加高效地擴(kuò)展。KEDA 可以根據(jù)事件流的速率和規(guī)模動態(tài)地調(diào)整應(yīng)用程序的副本數(shù)量，以滿足負(fù)載需求。這意味著在應(yīng)用程序需要處理大量事件時，KEDA 可以快速擴(kuò)展并自動添加 Pod 實例，以確保高吞吐量和低延遲。
另一個 KEDA 的優(yōu)勢是它支持多種事件源，如 Azure 隊列、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://: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 指標(biāo)來配置 KEDA Autoscaling。部署對象“keda-devops-demo”將根據(jù) Prometheus 指標(biāo)“sum(irate(by_path_counter_total{}[60s]))”來監(jiān)控 HTTP 請求的數(shù)量。如果該指標(biāo)的值超過 50，則 KEDA 將根據(jù)需要創(chuàng)建新的 Pod 來處理請求。如果該指標(biāo)的值低于 50，則 KEDA 將根據(jù)需要刪除多余的 Pod，以確保資源利用率的最大化。
該示例展示了如何使用 KEDA 來根據(jù) Prometheus 指標(biāo)來動態(tài)縮放應(yīng)用程序的規(guī)模。KEDA 提供了靈活的配置選項，可以滿足不同的業(yè)務(wù)需求。
通過這種配置，系統(tǒng)能夠根據(jù)實際的 HTTP 請求負(fù)載情況來動態(tài)調(diào)整應(yīng)用程序的規(guī)模。當(dāng)負(fù)載增加時，Autoscaling 機(jī)制將創(chuàng)建更多的 Pod 來處理請求，從而保持應(yīng)用程序的性能和可用性。一旦負(fù)載減輕，Autoscaling 機(jī)制便將適時地縮減 Pod 的數(shù)量，以節(jié)省資源和成本。
那么，KEDA 幫助 SRE 和 DevOps 團(tuán)隊解決了哪些問題或痛點?如下為一些參考，具體：
1.降低成本
KEDA 在事件驅(qū)動應(yīng)用程序的 Autoscaling 方面提供了更高的靈活性和精確性。它能夠根據(jù)事件的到達(dá)速率和規(guī)模來動態(tài)調(diào)整應(yīng)用程序的副本數(shù)量，從而更好地適應(yīng)不斷變化的負(fù)載情況。在沒有待處理的事件時，KEDA 具有將 Pod 數(shù)量減少到零的能力。相比之下，使用標(biāo)準(zhǔn) HPA 很難實現(xiàn)這一點。這種功能對于確保資源的有效利用和成本優(yōu)化非常有幫助，最終可以降低云計算費用。
2.提高可用性
截至目前，KEDA 已經(jīng)支持了 59 個內(nèi)置縮放器和 4 個外部縮放器。這些外部縮放器包括 KEDA HTTP 和 KEDA Scaler for Oracle DB 等。通過使用外部事件作為觸發(fā)器，KEDA 能夠?qū)崿F(xiàn)高效的自動縮放，尤其適用于消息驅(qū)動的微服務(wù)，如支付網(wǎng)關(guān)或訂單系統(tǒng)。
此外，由于 KEDA 的靈活性，可以無縫融入任何 DevOps 工具鏈。無論我們使用的是 Jenkins、GitLab、Prometheus 還是其他 DevOps 工具，KEDA 可以與之進(jìn)行集成，使得 Autoscaling 成為整個開發(fā)和部署流程的一部分。這樣，我們可以在保持流程的連續(xù)性和一致性的同時，充分利用 KEDA 的自動擴(kuò)縮容能力，實現(xiàn)高效的應(yīng)用程序管理。
3.提升性能
借助 KEDA，SRE 和 DevOps 團(tuán)隊可以根據(jù)負(fù)載波動情況來動態(tài)調(diào)整應(yīng)用程序的資源配置。通過快速響應(yīng)和自動擴(kuò)縮容的能力，KEDA 確保應(yīng)用程序始終具備足夠的資源來應(yīng)對負(fù)載變化，從而保持系統(tǒng)高性能運行。同時，監(jiān)控和指標(biāo)收集功能使得 SRE 和 DevOps 團(tuán)隊能夠?qū)崟r監(jiān)測和優(yōu)化應(yīng)用程序的性能。
四、KEDA 是如何工作的 ?
作為 Kubernetes 的事件驅(qū)動 Autoscaling 工具，KEDA 可以根據(jù)應(yīng)用程序的事件源來自動調(diào)整 Pod 的數(shù)量。KEDA 部署簡單，只需在 Kubernetes 集群中創(chuàng)建一個 ScaledObject 對象即可。ScaledObject 對象包含 KEDA 的配置信息，包括事件源、縮放規(guī)則等。
在部署 KEDA 后，縮放器將會像一個哨兵一樣，持續(xù)監(jiān)視事件源，并在發(fā)生任何觸發(fā)事件時將指標(biāo)傳遞給指標(biāo)適配器。指標(biāo)適配器會像一個翻譯員一樣，將指標(biāo)調(diào)整為控制器組件可以理解的格式，并將其提供給控制器組件。控制器組件會根據(jù) ScaledObject 中設(shè)置的擴(kuò)展規(guī)則來做出擴(kuò)大或縮小的決策，并將決策執(zhí)行到 Pod 上。
通常來講，KEDA 與 Kubernetes 水平 Pod 自動縮放器(Horizontal Pod Autoscaler，HPA)、外部事件源以及 Kubernetes 的數(shù)據(jù)存儲之間的協(xié)作關(guān)系，可參考如下圖所示：
上述參考流程圖描述了 KEDA 如何與 HPA 配合應(yīng)用 Pod 進(jìn)行自動彈性伸縮，這里，針對此實現(xiàn)架構(gòu)圖進(jìn)行簡要解析，具體實現(xiàn)流程如下：
- Kubernetes API Server 充當(dāng) KEDA 和 Kubernetes 之間集成的橋梁，將 KEDA 的自動彈性伸縮功能與 Kubernetes 的資源管理功能相結(jié)合。KEDA 通過 ScaledObject 對象將自動彈性伸縮的機(jī)制與 Kubernetes 資源對象相結(jié)合。KEDA 的核心組件包括指標(biāo)適配器、控制器、縮放器和準(zhǔn)入 Webhooks。
- Metrics Adapter 和準(zhǔn)入 Webhooks 從外部觸發(fā)源收集指標(biāo)，具體取決于 ScaledObject 對象中定義的觸發(fā)器類型。Metrics Adapter 將指標(biāo)轉(zhuǎn)換為 Kubernetes 指標(biāo)，并將其暴露給 Controller。準(zhǔn)入 Webhooks 負(fù)責(zé)驗證和修改 ScaledObject 對象，以確保 KEDA 能夠正確地進(jìn)行自動彈性伸縮。
- Controller 和 Scaler 負(fù)責(zé)根據(jù) Metrics Adapter 收集的指標(biāo)來進(jìn)行自動彈性伸縮。Controller 負(fù)責(zé)將彈性任務(wù)發(fā)送給 Scaler。Scaler 負(fù)責(zé)將縮放任務(wù)應(yīng)用到 Kubernetes 資源對象。
- 外部觸發(fā)源可以是任何可以提供指標(biāo)數(shù)據(jù)的來源，例如 Apache Kafka、Prometheus、AWS CloudWatch 等。外部觸發(fā)源負(fù)責(zé)直接從正在運行的服務(wù)收集系統(tǒng)指標(biāo)。如果工作負(fù)載很高，Pod 將會被橫向擴(kuò)展。如果工作負(fù)載較低，則對 Pod 進(jìn)行縮容。如果完全沒有工作負(fù)載，則將刪除 Pod，以最終優(yōu)化基礎(chǔ)設(shè)施資源。
通常而言，KEDA 核心由三個關(guān)鍵組成部分組成，具體涉及如下：
1.Metrics Adapter
KEDA 中的 Metrics Adapter 是負(fù)責(zé)將事件數(shù)據(jù)轉(zhuǎn)換為 Kubernetes 指標(biāo)的組件。Metrics Adapter 采用了“事件驅(qū)動”的設(shè)計理念，將事件數(shù)據(jù)轉(zhuǎn)換為 Kubernetes 指標(biāo)，并通過 Kubernetes 的 API Server 暴露給水平 Pod 自動縮放器。
2.Admission Webhooks
KEDA 中的 Admission Webhooks 是負(fù)責(zé)驗證和修改 Kubernetes 對象的組件。Admission Webhooks 可以用于驗證和修改 ScaledObject 對象，以確保 KEDA 能夠正確地進(jìn)行自動縮放。
KEDA 提供了兩種 Admission Webhook 聯(lián)系，一種是用于驗證和修改 ScaledObject 對象的 ScaledObject Admission Webhook 類型，另一種則是用于驗證和修改 Trigger 對象的 Trigger Admission Webhook 類型。
3.Agent
KEDA 中的 Agent 是負(fù)責(zé)監(jiān)控事件源并將事件數(shù)據(jù)傳遞給 KEDA 控制器的組件。KEDA 提供了多種 Agent，可以滿足不同的事件源需求。通常情況下，在沒有事件的情況下，Agent 組件會將部署調(diào)整至零副本，以免浪費資源。
在不斷發(fā)展的云原生應(yīng)用程序環(huán)境中，適應(yīng)動態(tài)工作負(fù)載是至關(guān)重要的。Kubernetes 提供了 HPA 和 VPA 等本機(jī)工具來實現(xiàn)自動縮放，但它們在應(yīng)對非 CPU 和 RAM 指標(biāo)驅(qū)動的負(fù)載時存在局限性。
KEDA 是 Kubernetes 的擴(kuò)展，克服了 HPA 和 VPA 的局限性，并提供了更靈活和全面的自動縮放解決方案。KEDA 可以根據(jù)任何指標(biāo)進(jìn)行縮放，包括 HTTP 請求數(shù)、消息隊列長度、數(shù)據(jù)庫連接數(shù)等。此外，KEDA 還支持縮小到零、觸發(fā) Kubernetes Job、發(fā)出用于診斷的實時事件以及通過身份驗證提供程序維護(hù)安全連接。
與 HPA 和 VPA 相比，KEDA 具有以下優(yōu)勢：
- 更靈活：KEDA 可以根據(jù)任何指標(biāo)進(jìn)行縮放，而 HPA 和 VPA 僅限于 CPU 和 RAM 指標(biāo)。
- 更全面：KEDA 支持縮小到零、觸發(fā) Kubernetes Job、發(fā)出用于診斷的實時事件以及通過身份驗證提供程序維護(hù)安全連接。
- 更易于使用：KEDA 的配置更簡單，減少了用戶在使用 Kubernetes 自定義指標(biāo)時面臨的典型障礙。
以上為 KEDA 的相關(guān)解析，更多內(nèi)容可參考后續(xù)文章所述，謝謝!
Reference ：[1] https://keda.sh/docs/2.12/concepts/
本文題目：一文搞懂使用KEDA實現(xiàn)Kubernetes自動彈性伸縮
文章分享：http://fisionsoft.com.cn/article/coopcjo.html
