KEDA-Kubernetes 中基于事件驅(qū)動(dòng)的自動(dòng)伸縮

事件驅(qū)動(dòng)計(jì)算并不是什么新的想法，在數(shù)據(jù)庫領(lǐng)域中就已經(jīng)使用數(shù)據(jù)庫觸發(fā)器有很多年了。這個(gè)概念很簡單：就是每當(dāng)你添加、更改或刪除數(shù)據(jù)時(shí)，就會(huì)觸發(fā)一個(gè)事件來執(zhí)行各種操作。這些類型的事件和觸發(fā)器在其他領(lǐng)域的應(yīng)用中也大量出現(xiàn)，例如自動(dòng)擴(kuò)展、自動(dòng)修復(fù)、容量規(guī)劃等等。事件驅(qū)動(dòng)架構(gòu)的核心是對(duì)系統(tǒng)上的各種事件做出反應(yīng)并執(zhí)行相應(yīng)的動(dòng)作。

自動(dòng)縮放已成為幾乎所有云平臺(tái)中不可或缺的組成部分，微服務(wù)或者容器也不例外。事實(shí)上，以靈活和解耦設(shè)計(jì)著稱的容器最適合自動(dòng)伸縮，因?yàn)樗鼈儽忍摂M機(jī)更容易創(chuàng)建。

可擴(kuò)展性是基于容器的應(yīng)用部署需要考慮的最重要方面之一。隨著容器編排平臺(tái)的發(fā)展，設(shè)計(jì)可伸縮性的解決方案變得非常簡單了。基于 Kubernetes 的事件驅(qū)動(dòng)自動(dòng)伸縮 KEDA（https://keda.sh/），允許用戶在 Kubernetes 上構(gòu)建自己的以事件驅(qū)動(dòng)的應(yīng)用程序。KEDA 處理觸發(fā)器以響應(yīng)其他服務(wù)中發(fā)生的事件，并根據(jù)需要擴(kuò)展工作負(fù)載。KEDA 使容器可以直接從源頭消費(fèi)事件，而不是通過 HTTP 進(jìn)行路由。

KEDA 可以在任何公有云或私有云以及企業(yè)內(nèi)部工作，包括 Azure Kubernetes 服務(wù)和 Red Hat 的OpenShift。有了它，開發(fā)人員現(xiàn)在還可以將微軟的無服務(wù)器平臺(tái) Azure Functions 作為容器部署在 Kubernetes 群集中，包括在 OpenShift 上。這看起來可能很簡單，但假設(shè)每天處理大量事務(wù)，真的能像下圖那樣手動(dòng)管理大量的應(yīng)用程序嗎?

KEDA 將自動(dòng)檢測新的部署應(yīng)用并開始監(jiān)聽事件源，利用實(shí)時(shí)監(jiān)控指標(biāo)來驅(qū)動(dòng)擴(kuò)展決策。

KEDA

KEDA 作為 Kubernetes 上的組件提供了兩個(gè)關(guān)鍵角色：

• 擴(kuò)展客戶端：用于激活和停止部署來擴(kuò)展配置的副本，并在沒有事件的情況下將副本縮減為零。
• Metrics Server：一種 Metrics 指標(biāo)服務(wù)，暴露了大量與事件相關(guān)的數(shù)據(jù)， 例如隊(duì)列長度，允許基于事件的擴(kuò)展，消耗特定類型的事件數(shù)據(jù)。

Metrics Server 與 HPA 進(jìn)行通信，以驅(qū)動(dòng) Kubernetes 部署副本的擴(kuò)展。然后由部署直接從源頭消費(fèi)事件。這樣可以保留豐富的事件集成，讓完成或丟棄隊(duì)列消息之類的可以立即使用。

Scaler

KEDA 使用 Scaler （縮放器）來檢測是否應(yīng)激活或取消激活部署，然后將其反饋送到特定事件源中。現(xiàn)在支持多個(gè)Scaler與特定支持的觸發(fā)器，例如 Kafka（觸發(fā)器: Kafka topic）、RabbitMQ（觸發(fā)器: RabbitMQ 隊(duì)列），并且還會(huì)支持更多。

除此之外，KEDA 還可以與 Azure Functions 工具集成在一起，原生擴(kuò)展 Azure 特定的縮放器，例如 Azure 存儲(chǔ)隊(duì)列、Azure 服務(wù) Bus 隊(duì)列、Azure 服務(wù) Bus 主題。

ScaledObject

ScaledObject 通過 Kubernetes CRD 的方式進(jìn)行部署，它具有將部署與事件源同步的功能。

一旦部署為 CRD，ScaledObject 即可進(jìn)行以下配置：

如上所述，支持不同的觸發(fā)器，下面顯示了一些示例：

事件驅(qū)動(dòng)的自動(dòng)伸縮實(shí)踐

KEDA 部署在 Kubernetes 中

帶有 KEDA 的 RabbitMQ 隊(duì)列縮放器

RabbitMQ 是一種稱為消息代理或隊(duì)列管理器的消息隊(duì)列應(yīng)用。簡單地說: 這是一個(gè)可以定義隊(duì)列的應(yīng)用，應(yīng)用程序可以連接到隊(duì)列并將消息傳輸?shù)皆撽?duì)列上。

在下面的示例中，在 Kubernetes 上將 RabbitMQ 通過 StatefulSet 進(jìn)行部署管理：

RabbitMQ 消費(fèi)者被部署為接受 RabbitMQ 服務(wù)器生成的隊(duì)列并模擬執(zhí)行動(dòng)作的 Deployment。

使用 RabbitMQ 觸發(fā)器創(chuàng)建 ScaledObject

除了上面的部署外，還提供了 ScaledObject 配置，該配置將由上面創(chuàng)建的 KEDA CRD 轉(zhuǎn)換，并在Kubernetes 上安裝 KEDA。

創(chuàng)建 ScaledObject 后，KEDA 控制器將自動(dòng)同步配置并開始監(jiān)聽上面創(chuàng)建的 Rabbitmq 消費(fèi)者。KEDA 無縫創(chuàng)建具有所需配置的 HPA 對(duì)象，并根據(jù)通過 ScaledObject 提供的觸發(fā)規(guī)則（在此示例中，隊(duì)列長度為5）擴(kuò)展副本。

由于尚無隊(duì)列，如下所示，rabbitmq-consumer 部署副本被設(shè)置為零。

通過 ScaledObject 和 HPA 配置，KEDA 將驅(qū)動(dòng)容器根據(jù)從事件源接收的信息進(jìn)行橫向擴(kuò)展。使用下面的 Kubernetes Job 配置發(fā)布一些隊(duì)列，這將產(chǎn)生10個(gè)隊(duì)列：

KEDA 會(huì)自動(dòng)將當(dāng)前rabbitmq-consumer應(yīng)用擴(kuò)展為兩個(gè)副本，以適應(yīng)隊(duì)列。

發(fā)布 10 個(gè)隊(duì)列-RabbitMQ Consumer 擴(kuò)展為兩個(gè)副本：

發(fā)布 200 個(gè)隊(duì)列-RabbitMQ 使用者擴(kuò)展到四十個(gè)副本：

發(fā)布 1000 個(gè)隊(duì)列-RabbitMQ Consumer 擴(kuò)展到100個(gè)副本，因?yàn)樽畲蟾北緮?shù)設(shè)置為100：

KEDA 提供了一個(gè)類似于 FaaS 的事件感知擴(kuò)展模型，在這種模型中，Kubernetes 部署可以基于需求和基于智能動(dòng)態(tài)地從零擴(kuò)展，而不會(huì)丟失數(shù)據(jù)和上下文。KEDA 還為 Azure Functions 提供了一個(gè)新的托管選項(xiàng)，可以將其部署為 Kubernetes 群集中的容器，從而將 Azure Functions 編程模型和擴(kuò)展控制器帶入任何 Kubernetes 實(shí)現(xiàn)中，無論是在云中還是在企業(yè)內(nèi)部。

KEDA 還為 Kubernetes 帶來了更多的事件源。隨著未來更多觸發(fā)器的加入，KEDA 有很大的潛力成為生產(chǎn)級(jí) Kubernetes 部署的必需品，從而使應(yīng)用程序自動(dòng)縮放成為應(yīng)用程序開發(fā)中的嵌入式組件。

原文鏈接：https://itnext.io/keda-kubernetes-based-event-driven-autoscaling-48491c79ec74