Kubernetes 事件驅動自動擴展(KEDA)是一個單一用途且輕量化的元件,使應用程式自動擴展變得簡單。 這是一個雲端原生運算基金會(CNCF)研究所的專案。 KEDA 採用事件驅動的自動擴展技術,透過「縮放至零」來持續且具成本效益地擴展您的應用程式,以滿足需求。
對大多數生產工作負載來說,AKS Automatic 是推薦的預設 AKS 體驗。 AKS Automatic 預設即可投入生產環境,且叢集中已預先設定 KEDA。 如果你使用 AKS 標準,可以透過管理的 KEDA 外掛來啟用 KEDA。
想了解更多關於 AKS 自動的資訊,請參閱 What is Azure Kubernetes Service (AKS) Automatic?
附註
KEDA 版本 2.15 及以上引入移除 Pod 身分識別支援的重大變更。 如果您使用 Pod 身分識別,我們建議您改用工作負載身分識別來進行驗證。 雖然 KEDA 管理外掛目前尚未執行 KEDA 2.15+ 版本,但該受管理外掛將在 AKS 預覽版 1.32 中開始運行 KEDA 2.15+。
如需有關如何使用工作負載身分識別安全地調整應用程式的詳細資訊,請參閱我們的 教學課程。 若要檢視 KEDA 的重大變更/淘汰原則,請閱讀其官方文件。
AKS 自動模式與 AKS 標準模式中的 KEDA
KEDA 支援兩種 AKS 叢集模式,但設定路徑不同:
- AKS 自動:KEDA 已預先配置並可使用。
- AKS 標準:啟用 AKS 管理附加元件以啟用 KEDA。
大多數生產場景建議從 AKS Automatic 開始,以使用生產準備預設並降低叢集管理負擔。
架構
KEDA 提供兩個主要元件:
-
KEDA 運算子,可讓使用者在支援 Kubernetes Deployments、Jobs、
StatefulSets,或任何定義/scale子資源的自定資源情況下,將工作負載從 0 擴充至 N 個執行個體。 - 計量伺服器會向 Kubernetes 中的 Horizontal Pod Autoscaler (HPA) 公開外部計量,以便進行自動調整,例如 Kafka 主題中的訊息,或 Azure 事件中樞中的事件數目。 由於上游限制,KEDA 必須是唯一安裝的外部計量配接器。
在官方 KEDA 文件中深入瞭解 KEDA 的運作方式。
安裝與啟用
AKS 自動化系统
KEDA 已在 AKS Automatic 中預先設定。 不需要另行進行 KEDA 附加元件安裝步驟。
AKS 標準
可透過以下方法之一啟用 AKS 標準上的 KEDA:
受控 KEDA 附加元件提供已整合 AKS 且受到完整支援的 KEDA 安裝。
能力與功能
KEDA 提供下列功能和特性:
- 當需求下降時,將工作負載調整到零。
- 用 Azure KEDA scalers 擴展應用程式工作負載以滿足需求。
- 使用例如 Deployments、
StatefulSets,或任何定義了/scale子資源的自訂資源等ScaledObjects,自動調整應用程式。 - 使用
ScaledJobs自動調整類作業工作負載的規模。 - 透過將自動擴展認證與工作負載解耦,使用生產級安全性。
- 帶上你自己的外部縮放器,做自訂的自動縮放邏輯。
- 與 Microsoft Entra 工作負載 ID 整合,以進行驗證。
在 AKS Automatic 中,因為叢集預設已設定 KEDA,所以您會獲得這些事件驅動的自動調整能力。
附註
如果你打算在 AKS Standard 上使用工作負載身份,請先 啟用工作負載身份 ,再啟用 KEDA 外掛。
生產指導方針
請參考以下指引選擇叢集模式:
- 當您想要具備已預先設定 KEDA 的可用於生產環境的預設體驗時,請選擇 AKS Automatic。
- 當你需要更深入的叢集層級自訂化和明確的附加元件管理時,選擇 AKS 標準。
- 在任一模式中,皆可使用 KEDA 對工作負載進行事件驅動的自動調整。
附加元件限制
KEDA AKS 附加元件具有下列限制:
- KEDA 用於擴展 HTTP 工作負載的 HTTP 附加元件(預覽版) 不會隨擴充功能一同安裝,但可以單獨部署。
- KEDA 的Azure Cosmos DB 外部擴縮程式可根據 Azure Cosmos DB 變更摘要來源進行擴縮;此程式不會隨擴充功能一同安裝,但可另行部署。
- Kubernetes 叢集中只允許一個外部計量伺服器。 因此,KEDA 附加元件應該是叢集內唯一的外部計量伺服器。
- 不支援多個 KEDA 安裝
- 不建議結合 KEDA
ScaledObject與水平 Pod 自動調整器 (HPA),以調整相同的工作負載。 它們相互競爭,因為 KEDA 在背景中使用水平 Pod 自動調整器 (HPA),結果導致異常調整行為。- 如果是先建立 HPA 後才建立 KEDA
ScaledObject,則將無法建立 KEDAScaledObject。 - 如果先建立 KEDA
ScaledObject,再建立 HPA,那麼 HPA 的建立不會被阻止。
- 如果是先建立 HPA 後才建立 KEDA
如需一般 KEDA 問題,建議您造訪常見問題概觀。
附註
如果您使用 Microsoft Entra 工作負載 ID,並且在啟用 Workload ID 之前先啟用 KEDA,則您需要重新啟動 KEDA operator Pod,才能注入正確的環境變數:
執行
kubectl rollout restart deployment keda-operator -n kube-system來重新啟動 Pod。使用
kubectl get pod -n kube-system,並尋找以keda-operator開頭的 Pod,以取得 KEDA Operator Pod。執行
kubectl describe pod <keda-operator-pod> -n kube-system,以確認成功插入環境變數。 在Environment下方,您應該會看到AZURE_TENANT_ID、AZURE_FEDERATED_TOKEN_FILE和AZURE_AUTHORITY_HOST的值。
支援的 Kubernetes 和 KEDA 版本
您的叢集 Kubernetes 版本會決定 AKS 叢集上安裝的 KEDA 版本。 若要查看哪些 KEDA 版本對應至每個 AKS 版本,請參閱 Kubernetes 元件版本資料表的 [AKS 受控附加元件] 資料行。
針對 GA Kubernetes 版本,AKS 會完整支援資料表中對應的 KEDA 次要版本。 客戶支援會以最大努力為準,部分涵蓋 Kubernetes 預覽版本和最新 KEDA 修補程式。 因此,這些功能不適合實際執行用途。 如需詳細資訊,請參閱下列支援文章: