聯合作者 |
Yan Xun，阿裡雲 EDAS 團隊進階工程師
Andy Shi，阿裡雲開發者倡導者
Tom Kerkhove，Codit 容器化業務負責人兼 Azure 架構師、KEDA 維護者、CNCF 大使
來源 |
阿裡巴巴雲原生公衆号
當你在伸縮 Kubernetes 時，你會想到一些領域，但是如果你是 Kubernetes 的新手，你可能會覺得有些難以應付。
在這篇博文中，我們将簡要解釋需要考慮的領域，
KEDA如何使應用自動伸縮變得簡單，以及為什麼阿裡雲
企業分布式應用服務（EDAS）在 KEDA 上完全标準化。
伸縮 Kubernetes
當管理 Kubernetes 叢集和應用程式時，你需要仔細監視各種事情，比如：
- 叢集容量——我們是否有足夠的可用資源來運作我們的工作負載？
- 應用程式工作負載——應用程式有足夠的可用資源嗎？它能跟上待完成的工作嗎？(像隊列深度）
為了實作自動化，你通常會設定警報以獲得通知，甚至使用自動伸縮。Kubernetes 是一個很好的平台，它可以幫助你實作這個即時可用的功能。
通過使用
Cluster Autoscaler元件可以輕松地伸縮叢集，該元件将監視叢集，以發現由于資源短缺而無法排程的 pod，并開始相應地添加/删除節點。
因為 Cluster Autoscaler 隻在 pod 排程過度時才會啟動，是以你可能會有一段時間間隔，在此期間你的工作負載沒有啟動和運作。
Virtual Kubelet（一個 CNCF 沙箱項目）是一個巨大的幫助，它允許你向 Kubernetes 叢集添加一個“虛拟節點”，pod 可以在其上排程。
通過這樣做，
平台供應商（如阿裡巴巴、Azure、HashiCorp 和其他）允許你将挂起的 pod 溢出到叢集之外，直到它提供所需的叢集容量來緩解這個問題。
除了伸縮叢集，Kubernetes 還允許你輕松地伸縮應用程式：
- Horizontal Pod Autoscaler（ HPA ）允許你添加/删除更多的 Pod 到你的工作負載中，以 scale in/out（添加或删除副本）。
- Vertical Pod Autoscaler（ VPA ）允許你添加/删除資源到你的 Pod 以 scale up/down（添加或删除 CPU 或記憶體）。
所有這些為你伸縮應用程式提供了一個很好的起點。
HPA 的局限性
雖然 HPA 是一個很好的起點，但它主要關注 pod 本身的名額，允許你基于 CPU 和記憶體伸縮它。也就是說，你可以完全配置它應該如何自動縮放，這使它強大。
雖然這對于某些工作負載來說是理想的，但你通常想要基于其他地方如 Prometheus、Kafka、雲供應商或其他事件上的名額進行伸縮。
多虧了
外部名額支援，使用者可以安裝名額擴充卡，從外部服務中提供各種名額，并通過使用名額伺服器對它們進行自動伸縮。
但是，有一點需要注意，你隻能在叢集中運作一個名額伺服器，這意味着你必須選擇自定義名額的來源。
你可以使用 Prometheus 和工具，比如 Promitor，從其他提供商那裡擷取你的名額，并将其作為單一的真相來源來進行伸縮，但這需要大量的管道（plumbing）和工作來進行擴充。
肯定有更簡單的方法……是的，使用 Kubernetes Event-Driven Autoscaling（KEDA）！
KEDA 是什麼？
Kubernetes Event-Driven Autoscaling（KEDA）是一個用于 Kubernetes 的單用途事件驅動自動伸縮器，可以很容易地将其添加到 Kubernetes 叢集中以伸縮應用程式。
它的目标是使應用程式自動擴充非常簡單，并通過支援伸縮到零（scale-to-zero）來優化成本。
KEDA 去掉了所有的伸縮基礎設施，并為你管理一切，允許你在 30 多個系統上進行伸縮或使用自己的伸縮器進行擴充。
使用者隻需要建立 ScaledObject 或 ScaledJob 來定義你想要伸縮的對象和你想要使用的觸發器；KEDA 會處理剩下的一切！
你可以伸縮任何東西；即使它是你正在使用的另一個工具的 CRD，隻要它實作/scale 子資源。
那麼，KEDA 重新發明輪子了嗎？不！相反，它通過在底層使用 HPA 來擴充 Kubernetes，HPA 使用我們的外部名額，這些名額由我們自己的名額擴充卡提供，該擴充卡取代了所有其他擴充卡。
去年，KEDA 加入了 CNCF，作為 CNCF 沙箱項目，計劃今年晚些時候提案更新到孵化階段。
阿裡巴巴基于 OAM/KubeVela 和 KEDA 的實踐
企業分布式應用服務（EDAS）作為阿裡雲上的主要企業 PaaS 産品，多年來以巨大的規模服務于公有雲上的無數開發者。從架構的角度來看，EDAS 是與
KubeVela 項目一起建構的。其總體架構如下圖所示。
在生産上，EDAS 在阿裡雲上內建了 ARMS 監控服務，提供監控和應用的細粒度名額。EDAS 團隊在 KEDA 項目中添加了一個 ARMS Scaler 來執行自動縮放。他們還添加了一些特性，并修複了 KEDA v1 版本中的一些 bug。包括：
- 當有多個觸發器時，這些值将被求和，而不是作為單獨的值留下。
- 當建立 KEDA HPA 時，名稱的長度将被限制為 63 個字元，以避免觸發 DNS 投訴。
- 不能禁用觸發器，這可能會在生産中引起麻煩。
EDAS 團隊正在積極地将這些修複程式發送給上遊 KEDA，盡管其中一些已經添加到 V2 版本中。
為什麼阿裡雲将 KEDA 标準化為其應用的自動伸縮器
當涉及到自動擴充特性時，EDAS 最初使用上遊 Kubernetes HPA 的 CPU 和記憶體作為兩個名額。然而，随着使用者群的增長和需求的多樣化，EDAS 團隊很快發現了上遊 HPA 的局限性：
- 對定制名額的支援有限，特别是對應用程式級細粒度名額的支援。上遊 HPA 主要關注容器級名額，比如 CPU 和記憶體，這些名額對于應用程式來說太粗糙了。反映應用程式負載的名額（如 RT 和 QPS）不受現成支援。是的，HPA 可以擴充。然而，當涉及到應用程式級名額時，這種能力是有限的。EDAS 團隊在嘗試引入細粒度的應用程式級名額時，經常被迫分叉代碼。
- 不支援伸縮到零。當他們的微服務沒有被使用時，許多使用者都有将規模伸縮到零的需求。這一需求不僅限于 FaaS/無伺服器工作負載。它為所有使用者節省成本和資源。目前，上遊 HPA 不支援此功能。
- 不支援預定的伸縮。EDAS 使用者的另一個強烈需求是預定的伸縮能力。同樣，上遊 HPA 不提供此功能，EDAS 團隊需要尋找非供應商鎖定的替代方案。
基于這些需求，EDAS 團隊開始規劃 EDAS 自動伸縮特性的新版本。與此同時，EDAS 在 2020 年初引入了 OAM，對其底層核心元件進行了徹底改革。OAM 為 EDAS 提供了标準化的、可插入的應用程式定義，以取代其内部的 Kubernetes 應用程式 CRD。該模型的可擴充性使 EDAS 能夠輕松地與 Kubernetes 社群的任何新功能內建。在這種情況下，EDAS 團隊試圖将對 EDAS 新的自動伸縮特性的需求與 OAM 自動伸縮特性的标準實作相結合。
基于用例，EDAS 團隊總結了三個标準：
- 自動伸縮特性應該将自己呈現為一個簡單的原子功能，而不需要附加任何複雜的解決方案。
- 名額應該是可插入的，是以 EDAS 團隊可以對其進行定制，并在其之上建構以支援各種需求。
- 它需要開箱即用地支援伸縮到零。
經過詳細的評估，EDAS 團隊選擇了 KEDA 項目，該項目是由微軟和紅帽開源的，已捐贈給 CNCF。KEDA 預設提供了幾個有用的 Scaler，并開箱即用地支援伸縮到零。它為應用程式提供了細粒度的自動伸縮。它具有 Scalar 和 Metric 擴充卡的概念，支援強大的插件架構，同時提供統一的 API 層。最重要的是，KEDA 的設計隻關注自動伸縮，這樣就可以輕松地将其內建為 OAM 特性。總的來說，KEDA 非常适合 EDAS。
展望未來
下一步，阿裡巴巴正在積極推動由 AIOps 驅動的 KEDA 特性，目标是為其自動伸縮行為帶來智能決策。這将從本質上實作基于專家系統和曆史資料分析的自動伸縮決策，利用阿裡巴巴的 KEDA 元件中新實作的應用 QoS 觸發器和資料庫度量觸發器等。是以，我們期待一個更強大、更智能、更穩定的基于 KEDA 的自動伸縮功能将很快在 KEDA 中釋出。