KubeVela+KEDA有什么作用

本篇內(nèi)容介紹了“KubeVela+KEDA有什么作用”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

伸縮 Kubernetes

當(dāng)管理 Kubernetes 集群和應(yīng)用程序時(shí)，你需要仔細(xì)監(jiān)視各種事情，比如：

• 集群容量——我們是否有足夠的可用資源來運(yùn)行我們的工作負(fù)載？

• 應(yīng)用程序工作負(fù)載——應(yīng)用程序有足夠的可用資源嗎？它能跟上待完成的工作嗎？(像隊(duì)列深度）

為了實(shí)現(xiàn)自動(dòng)化，你通常會(huì)設(shè)置警報(bào)以獲得通知，甚至使用自動(dòng)伸縮。Kubernetes 是一個(gè)很好的平臺(tái)，它可以幫助你實(shí)現(xiàn)這個(gè)即時(shí)可用的功能。  通過使用 Cluster Autoscaler 組件可以輕松地伸縮集群，該組件將監(jiān)視集群，以發(fā)現(xiàn)由于資源短缺而無法調(diào)度的 pod，并開始相應(yīng)地添加/刪除節(jié)點(diǎn)。  因?yàn)?Cluster Autoscaler 只在 pod 調(diào)度過度時(shí)才會(huì)啟動(dòng)，所以你可能會(huì)有一段時(shí)間間隔，在此期間你的工作負(fù)載沒有啟動(dòng)和運(yùn)行。  Virtual Kubelet（一個(gè) CNCF 沙箱項(xiàng)目）是一個(gè)巨大的幫助，它允許你向 Kubernetes 集群添加一個(gè)“虛擬節(jié)點(diǎn)”，pod 可以在其上調(diào)度。  

通過這樣做，平臺(tái)供應(yīng)商（如阿里巴巴、Azure、HashiCorp 和其他）允許你將掛起的 pod 溢出到集群之外，直到它提供所需的集群容量來緩解這個(gè)問題。  除了伸縮集群，Kubernetes 還允許你輕松地伸縮應(yīng)用程序：

• Horizontal Pod Autoscaler（HPA）允許你添加/刪除更多的 Pod 到你的工作負(fù)載中，以 scale in/out（添加或刪除副本）。

• Vertical Pod Autoscaler（VPA）允許你添加/刪除資源到你的 Pod 以 scale up/down（添加或刪除 CPU 或內(nèi)存）。

所有這些為你伸縮應(yīng)用程序提供了一個(gè)很好的起點(diǎn)。

HPA 的局限性

雖然 HPA 是一個(gè)很好的起點(diǎn)，但它主要關(guān)注 pod 本身的指標(biāo)，允許你基于 CPU 和內(nèi)存伸縮它。也就是說，你可以完全配置它應(yīng)該如何自動(dòng)縮放，這使它強(qiáng)大。  雖然這對(duì)于某些工作負(fù)載來說是理想的，但你通常想要基于其他地方如 Prometheus、Kafka、云供應(yīng)商或其他事件上的指標(biāo)進(jìn)行伸縮。  多虧了外部指標(biāo)支持，用戶可以安裝指標(biāo)適配器，從外部服務(wù)中提供各種指標(biāo)，并通過使用指標(biāo)服務(wù)器對(duì)它們進(jìn)行自動(dòng)伸縮。  但是，有一點(diǎn)需要注意，你只能在集群中運(yùn)行一個(gè)指標(biāo)服務(wù)器，這意味著你必須選擇自定義指標(biāo)的來源。  

你可以使用 Prometheus 和工具，比如 Promitor，從其他提供商那里獲取你的指標(biāo)，并將其作為單一的真相來源來進(jìn)行伸縮，但這需要大量的管道（plumbing）和工作來進(jìn)行擴(kuò)展。  肯定有更簡單的方法……是的，使用 Kubernetes Event-Driven Autoscaling（KEDA）！

KEDA 是什么？

Kubernetes Event-Driven Autoscaling（KEDA）是一個(gè)用于 Kubernetes 的單用途事件驅(qū)動(dòng)自動(dòng)伸縮器，可以很容易地將其添加到 Kubernetes 集群中以伸縮應(yīng)用程序。  它的目標(biāo)是使應(yīng)用程序自動(dòng)擴(kuò)展非常簡單，并通過支持伸縮到零（scale-to-zero）來優(yōu)化成本。  KEDA 去掉了所有的伸縮基礎(chǔ)設(shè)施，并為你管理一切，允許你在 30 多個(gè)系統(tǒng)上進(jìn)行伸縮或使用自己的伸縮器進(jìn)行擴(kuò)展。  用戶只需要?jiǎng)?chuàng)建 ScaledObject 或 ScaledJob 來定義你想要伸縮的對(duì)象和你想要使用的觸發(fā)器；KEDA 會(huì)處理剩下的一切！  

你可以伸縮任何東西；即使它是你正在使用的另一個(gè)工具的 CRD，只要它實(shí)現(xiàn)/scale 子資源。  那么，KEDA 重新發(fā)明輪子了嗎？不！相反，它通過在底層使用 HPA 來擴(kuò)展 Kubernetes，HPA 使用我們的外部指標(biāo)，這些指標(biāo)由我們自己的指標(biāo)適配器提供，該適配器取代了所有其他適配器。  

去年，KEDA 加入了 CNCF，作為 CNCF 沙箱項(xiàng)目，計(jì)劃今年晚些時(shí)候提案升級(jí)到孵化階段。

阿里巴巴基于 OAM/KubeVela 和 KEDA 的實(shí)踐

企業(yè)分布式應(yīng)用服務(wù)（EDAS）作為阿里云上的主要企業(yè) PaaS 產(chǎn)品，多年來以巨大的規(guī)模服務(wù)于公有云上的無數(shù)開發(fā)者。從架構(gòu)的角度來看，EDAS 是與 KubeVela 項(xiàng)目一起構(gòu)建的。其總體架構(gòu)如下圖所示。  

在生產(chǎn)上，EDAS 在阿里云上集成了 ARMS 監(jiān)控服務(wù)，提供監(jiān)控和應(yīng)用的細(xì)粒度指標(biāo)。EDAS 團(tuán)隊(duì)在 KEDA 項(xiàng)目中添加了一個(gè) ARMS Scaler 來執(zhí)行自動(dòng)縮放。他們還添加了一些特性，并修復(fù)了 KEDA v1 版本中的一些 bug。包括：

• 當(dāng)有多個(gè)觸發(fā)器時(shí)，這些值將被求和，而不是作為單獨(dú)的值留下。

• 當(dāng)創(chuàng)建 KEDA HPA 時(shí)，名稱的長度將被限制為 63 個(gè)字符，以避免觸發(fā) DNS 投訴。

• 不能禁用觸發(fā)器，這可能會(huì)在生產(chǎn)中引起麻煩。

EDAS 團(tuán)隊(duì)正在積極地將這些修復(fù)程序發(fā)送給上游 KEDA，盡管其中一些已經(jīng)添加到 V2 版本中。

為什么阿里云將 KEDA 標(biāo)準(zhǔn)化為其應(yīng)用的自動(dòng)伸縮器

當(dāng)涉及到自動(dòng)擴(kuò)展特性時(shí)，EDAS 最初使用上游 Kubernetes HPA 的 CPU 和內(nèi)存作為兩個(gè)指標(biāo)。然而，隨著用戶群的增長和需求的多樣化，EDAS 團(tuán)隊(duì)很快發(fā)現(xiàn)了上游 HPA 的局限性：

1. 對(duì)定制指標(biāo)的支持有限，特別是對(duì)應(yīng)用程序級(jí)細(xì)粒度指標(biāo)的支持。上游 HPA 主要關(guān)注容器級(jí)指標(biāo)，比如 CPU 和內(nèi)存，這些指標(biāo)對(duì)于應(yīng)用程序來說太粗糙了。反映應(yīng)用程序負(fù)載的指標(biāo)（如 RT 和 QPS）不受現(xiàn)成支持。是的，HPA 可以擴(kuò)展。然而，當(dāng)涉及到應(yīng)用程序級(jí)指標(biāo)時(shí)，這種能力是有限的。EDAS 團(tuán)隊(duì)在嘗試引入細(xì)粒度的應(yīng)用程序級(jí)指標(biāo)時(shí)，經(jīng)常被迫分叉代碼。

2. 不支持伸縮到零。當(dāng)他們的微服務(wù)沒有被使用時(shí)，許多用戶都有將規(guī)模伸縮到零的需求。這一需求不僅限于 FaaS/無服務(wù)器工作負(fù)載。它為所有用戶節(jié)省成本和資源。目前，上游 HPA 不支持此功能。

3. 不支持預(yù)定的伸縮。EDAS 用戶的另一個(gè)強(qiáng)烈需求是預(yù)定的伸縮能力。同樣，上游 HPA 不提供此功能，EDAS 團(tuán)隊(duì)需要尋找非供應(yīng)商鎖定的替代方案。

基于這些需求，EDAS 團(tuán)隊(duì)開始規(guī)劃 EDAS 自動(dòng)伸縮特性的新版本。與此同時(shí)，EDAS 在 2020 年初引入了 OAM，對(duì)其底層核心組件進(jìn)行了徹底改革。OAM 為 EDAS 提供了標(biāo)準(zhǔn)化的、可插入的應(yīng)用程序定義，以取代其內(nèi)部的 Kubernetes 應(yīng)用程序 CRD。該模型的可擴(kuò)展性使 EDAS 能夠輕松地與 Kubernetes 社區(qū)的任何新功能集成。在這種情況下，EDAS 團(tuán)隊(duì)試圖將對(duì) EDAS 新的自動(dòng)伸縮特性的需求與 OAM 自動(dòng)伸縮特性的標(biāo)準(zhǔn)實(shí)現(xiàn)相結(jié)合。  基于用例，EDAS 團(tuán)隊(duì)總結(jié)了三個(gè)標(biāo)準(zhǔn)：

1. 自動(dòng)伸縮特性應(yīng)該將自己呈現(xiàn)為一個(gè)簡單的原子功能，而不需要附加任何復(fù)雜的解決方案。

2. 指標(biāo)應(yīng)該是可插入的，因此 EDAS 團(tuán)隊(duì)可以對(duì)其進(jìn)行定制，并在其之上構(gòu)建以支持各種需求。

3. 它需要開箱即用地支持伸縮到零。

經(jīng)過詳細(xì)的評(píng)估，EDAS 團(tuán)隊(duì)選擇了 KEDA 項(xiàng)目，該項(xiàng)目是由微軟和紅帽開源的，已捐贈(zèng)給 CNCF。KEDA 默認(rèn)提供了幾個(gè)有用的 Scaler，并開箱即用地支持伸縮到零。它為應(yīng)用程序提供了細(xì)粒度的自動(dòng)伸縮。它具有 Scalar 和 Metric 適配器的概念，支持強(qiáng)大的插件架構(gòu)，同時(shí)提供統(tǒng)一的 API 層。最重要的是，KEDA 的設(shè)計(jì)只關(guān)注自動(dòng)伸縮，這樣就可以輕松地將其集成為 OAM 特性?？偟膩碚f，KEDA 非常適合 EDAS。

“KubeVela+KEDA有什么作用”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！