![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/e050bbc34a2a4b5c92eb5263393c955d.png)

聯合作者 | 
Yan Xun，阿里雲 EDAS 團隊高階工程師
Andy Shi，阿里雲開發者倡導者
Tom Kerkhove，Codit 容器化業務負責人兼 Azure 架構師、KEDA 維護者、CNCF 大使
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/NoF1HBzBwHebtMDen8tFgg)

當你在伸縮 Kubernetes 時，你會想到一些領域，但是如果你是 Kubernetes 的新手，你可能會覺得有些難以應付。

在這篇博文中，我們將簡要解釋需要考慮的領域，[KEDA](https://keda.sh/) 如何使應用自動伸縮變得簡單，以及為什麼阿里雲[企業分散式應用服務（EDAS）](https://cn.aliyun.com/product/edas)在 KEDA 上完全標準化。

## 伸縮 Kubernetes

當管理 Kubernetes 叢集和應用程式時，你需要仔細監視各種事情，比如：

- 叢集容量——我們是否有足夠的可用資源來執行我們的工作負載？
- 應用程式工作負載——應用程式有足夠的可用資源嗎？它能跟上待完成的工作嗎？(像佇列深度）

為了實現自動化，你通常會設定警報以獲得通知，甚至使用自動伸縮。Kubernetes 是一個很好的平臺，它可以幫助你實現這個即時可用的功能。

透過使用 [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) 元件可以輕鬆地伸縮叢集，該元件將監視叢集，以發現由於資源短缺而無法排程的 pod，並開始相應地新增/刪除節點。

因為 Cluster Autoscaler 只在 pod 排程過度時才會啟動，所以你可能會有一段時間間隔，在此期間你的工作負載沒有啟動和執行。

[Virtual Kubelet](https://virtual-kubelet.io/)（一個 CNCF 沙箱專案）是一個巨大的幫助，它允許你向 Kubernetes 叢集新增一個“虛擬節點”，pod 可以在其上排程。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/b684bb265e184e1dbb3c2245551be97f.png)

透過這樣做，[平臺供應商](https://github.com/virtual-kubelet/virtual-kubelet#providers)（如阿里巴巴、Azure、HashiCorp 和其他）允許你將掛起的 pod 溢位到叢集之外，直到它提供所需的叢集容量來緩解這個問題。

除了伸縮叢集，Kubernetes 還允許你輕鬆地伸縮應用程式：

- Horizontal Pod Autoscaler（[HPA](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)）允許你新增/刪除更多的 Pod 到你的工作負載中，以 scale in/out（新增或刪除副本）。
- Vertical Pod Autoscaler（[VPA](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)）允許你新增/刪除資源到你的 Pod 以 scale up/down（新增或刪除 CPU 或記憶體）。

所有這些為你伸縮應用程式提供了一個很好的起點。

## HPA 的侷限性

雖然 HPA 是一個很好的起點，但它主要關注 pod 本身的指標，允許你基於 CPU 和記憶體伸縮它。也就是說，你可以完全配置它應該如何自動縮放，這使它強大。

雖然這對於某些工作負載來說是理想的，但你通常想要基於其他地方如 Prometheus、Kafka、雲供應商或其他事件上的指標進行伸縮。

多虧了[外部指標支援](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-external-metrics.md)，使用者可以安裝指標介面卡，從外部服務中提供各種指標，並透過使用指標伺服器對它們進行自動伸縮。

但是，有一點需要注意，你只能在叢集中執行一個指標伺服器，這意味著你必須選擇自定義指標的來源。

![2.jpg](https://ucc.alicdn.com/pic/developer-ecology/41977924b9704aba9ad3a647db56dcca.jpg)

你可以使用 Prometheus 和工具，比如 Promitor，從其他提供商那裡獲取你的指標，並將其作為單一的真相來源來進行伸縮，但這需要大量的管道（plumbing）和工作來進行擴充套件。

肯定有更簡單的方法……是的，使用 Kubernetes Event-Driven Autoscaling（KEDA）！

## KEDA 是什麼？

Kubernetes Event-Driven Autoscaling（KEDA）是一個用於 Kubernetes 的單用途事件驅動自動伸縮器，可以很容易地將其新增到 Kubernetes 叢集中以伸縮應用程式。

它的目標是使應用程式自動擴充套件非常簡單，並透過支援伸縮到零（scale-to-zero）來最佳化成本。

KEDA 去掉了所有的伸縮基礎設施，併為你管理一切，允許你在 30 多個系統上進行伸縮或使用自己的伸縮器進行擴充套件。

使用者只需要建立 ScaledObject 或 ScaledJob 來定義你想要伸縮的物件和你想要使用的觸發器；KEDA 會處理剩下的一切！

![3.jpg](https://ucc.alicdn.com/pic/developer-ecology/c6e4f7e4a20a40348cdfc37175168b13.jpg)

你可以伸縮任何東西；即使它是你正在使用的另一個工具的 CRD，只要它實現/scale 子資源。

那麼，KEDA 重新發明輪子了嗎？不！相反，它透過在底層使用 HPA 來擴充套件 Kubernetes，HPA 使用我們的外部指標，這些指標由我們自己的指標介面卡提供，該介面卡取代了所有其他介面卡。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/b6d13b5059a94da99b12caea06af8106.png)

去年，KEDA 加入了 CNCF，作為 CNCF 沙箱專案，計劃今年晚些時候提案升級到孵化階段。

## 阿里巴巴基於 OAM/KubeVela 和 KEDA 的實踐

企業分散式應用服務（EDAS）作為阿里雲上的主要企業 PaaS 產品，多年來以巨大的規模服務於公有云上的無數開發者。從架構的角度來看，EDAS 是與 [KubeVela 專案](https://kubevela.io/)一起構建的。其總體架構如下圖所示。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/2f69b229f42841278e71dabd5766b784.png)

在生產上，EDAS 在阿里雲上整合了 ARMS 監控服務，提供監控和應用的細粒度指標。EDAS 團隊在 KEDA 專案中新增了一個 ARMS Scaler 來執行自動縮放。他們還新增了一些特性，並修復了 KEDA v1 版本中的一些 bug。包括：

- 當有多個觸發器時，這些值將被求和，而不是作為單獨的值留下。
- 當建立 KEDA HPA 時，名稱的長度將被限制為 63 個字元，以避免觸發 DNS 投訴。
- 不能禁用觸發器，這可能會在生產中引起麻煩。

EDAS 團隊正在積極地將這些修復程式傳送給上游 KEDA，儘管其中一些已經新增到 V2 版本中。

## 為什麼阿里雲將 KEDA 標準化為其應用的自動伸縮器

當涉及到自動擴充套件特性時，EDAS 最初使用上游 Kubernetes HPA 的 CPU 和記憶體作為兩個指標。然而，隨著使用者群的增長和需求的多樣化，EDAS 團隊很快發現了上游 HPA 的侷限性：

1. **對定製指標的支援有限，特別是對應用程式級細粒度指標的支援**。上游 HPA 主要關注容器級指標，比如 CPU 和記憶體，這些指標對於應用程式來說太粗糙了。反映應用程式負載的指標（如 RT 和 QPS）不受現成支援。是的，HPA 可以擴充套件。然而，當涉及到應用程式級指標時，這種能力是有限的。EDAS 團隊在嘗試引入細粒度的應用程式級指標時，經常被迫分叉程式碼。
1. **不支援伸縮到零**。當他們的微服務沒有被使用時，許多使用者都有將規模伸縮到零的需求。這一需求不僅限於 FaaS/無伺服器工作負載。它為所有使用者節省成本和資源。目前，上游 HPA 不支援此功能。
1. **不支援預定的伸縮**。EDAS 使用者的另一個強烈需求是預定的伸縮能力。同樣，上游 HPA 不提供此功能，EDAS 團隊需要尋找非供應商鎖定的替代方案。

基於這些需求，EDAS 團隊開始規劃 EDAS 自動伸縮特性的新版本。與此同時，EDAS 在 2020 年初引入了 OAM，對其底層核心元件進行了徹底改革。OAM 為 EDAS 提供了標準化的、可插入的應用程式定義，以取代其內部的 Kubernetes 應用程式 CRD。該模型的可擴充套件性使 EDAS 能夠輕鬆地與 Kubernetes 社群的任何新功能整合。在這種情況下，EDAS 團隊試圖將對 EDAS 新的自動伸縮特性的需求與 OAM 自動伸縮特性的標準實現相結合。

基於用例，EDAS 團隊總結了三個標準：

1. 自動伸縮特性應該將自己呈現為一個簡單的原子功能，而不需要附加任何複雜的解決方案。
1. 指標應該是可插入的，因此 EDAS 團隊可以對其進行定製，並在其之上構建以支援各種需求。
1. 它需要開箱即用地支援伸縮到零。

經過詳細的評估，EDAS 團隊選擇了 KEDA 專案，該專案是由微軟和紅帽開源的，已捐贈給 CNCF。KEDA 預設提供了幾個有用的 Scaler，並開箱即用地支援伸縮到零。它為應用程式提供了細粒度的自動伸縮。它具有 Scalar 和 Metric 介面卡的概念，支援強大的外掛架構，同時提供統一的 API 層。最重要的是，KEDA 的設計只關注自動伸縮，這樣就可以輕鬆地將其整合為 OAM 特性。總的來說，KEDA 非常適合 EDAS。

## 展望未來

下一步，阿里巴巴正在積極推動由 AIOps 驅動的 KEDA 特性，目標是為其自動伸縮行為帶來智慧決策。這將從本質上實現基於專家系統和歷史資料分析的自動伸縮決策，利用阿里巴巴的 KEDA 元件中新實現的應用 QoS 觸發器和資料庫度量觸發器等。因此，我們期待一個更強大、更智慧、更穩定的基於 KEDA 的自動伸縮功能將很快在 KEDA 中釋出。

KubeVela + KEDA：為應用帶來“與生俱來”的彈性伸縮能力

相關文章