KEDA 以事件驱动的方式实现 Kubernetes Pod 的动态自动扩容机制，以满足不同的负载需求，从而提高应用可伸缩性和弹性。原文: Dynamic Scaling with Kubernetes Event-driven Autoscaling (KEDA)
Kubernetes 是容器编排平台的事实标准，已经彻底改变了部署和管理应用的方式。对应用进行有效扩容的关键挑战之一是确保基础设施适应工作负载的动态需求，这就是 Kubernetes pod autoscaling 发挥作用的地方，可以根据预定义指标自动调整 pod 数量。虽然 Kubernetes 提供了内置的自动缩放功能，但 Kubernetes 事件驱动自动缩放(KEDA, Kubernetes Event-driven Autoscaling)项目提供了更强大的解决方案来增强和扩展自动缩放功能。本文将探讨 Kubernetes 和 KEDA 中内置自动缩放的区别，重点介绍 KEDA 的优缺点，并提供真实用例来展示其潜力。
Kubernetes 内置自动缩放
Kubernetes 提供了一种称为水平 Pod 自动缩放(HPA，Horizontal Pod Autoscaler)的本地自动缩放机制。HPA 可以定义指标(例如 CPU 利用率或基于指标服务器的自定义指标)，从而让 Kubernetes 根据指定阈值自动调整 pod 副本数量。这种内置解决方案适用于许多场景，但在事件驱动的工作负载或基于自定义指标的扩展方面存在局限性。
Kubernetes 事件驱动自动缩放(KEDA，Kubernetes Event-driven Autoscaling)
KEDA(Kubernetes 事件驱动自动缩放)项目，是一个开源项目，将 Kubernetes 的自动缩放功能扩展到更广泛的工作负载。KEDA 充当事件源(如消息队列或流平台)与 Kubernetes 之间的桥梁，支持基于事件驱动触发器的自动扩容。利用 KEDA，可以实时扩展应用 pod，对传入事件做出反应并优化资源利用率。
KEDA 优缺点
与 Kubernetes 内置的自动缩放功能相比，KEDA 有如下优势:
- 事件驱动扩容: KEDA 支持基于各种事件源的自动扩容，可以处理突发工作负载或适应不可预测的需求峰值。
- 支持自定义指标: 与 HPA 不同，KEDA 可以基于自定义指标进行扩容，从而在定义特定于应用需求的扩容触发器时提供更多灵活性。
- 资源效率: 当没有工作负载时，KEDA 可以缩容到零副本，从而有效降低资源消耗和成本。
- 可扩展架构: KEDA 与各种事件源无缝集成，并通过可插拔架构进行扩展，可以根据特定需求进行调整。
尽管有很多好处，但使用 KEDA 也有一些注意事项:
- 额外的复杂性: 集成和配置 KEDA 需要额外设置和管理开销，需要根据应用复杂性进行权衡。
- 学习曲线: KEDA 引入了新的概念和工具，对于新的项目开发人员和运维人员来说，可能需要一些学习。
通过 Helm 3 安装 KEDA
- 添加 Helm repo
helm repo add kedacore https://kedacore.github.io/charts
复制代码
- 更新 Helm repo
helm repo update
复制代码
- 安装
KEDAHelm chart
kubectl create namespace keda helm install keda kedacore/keda --namespace keda
复制代码
用例
基于 Azure 服务总线队列长度的 Kubernetes pod 自动伸缩
在这个用例中，我们有一个微服务应用程序，负责处理来自 Azure 服务总线队列的消息。工作负载是偶尔发生的，根据传入流量具有不同的队列长度。我们希望动态扩展 Kubernetes pod，以便通过 KEDA 有效的处理消息。
前置条件
- 安装了 KEDA 的 Kubernetes 集群。
- 访问队列的 Azure 服务总线和凭据。
步骤 1: 部署示例应用程序。首先部署应用，侦听 Azure 服务总线队列并处理消息。我们用一个简单的 Python 应用程序进行演示。
# app.py from azure.servicebus import ServiceBusClient, ServiceBusMessage def process_message(message): # Process the message here print(f"Processing message: {message}") # Configure Azure Service Bus connection string connection_string = "your-connection-string" # Create a Service Bus client service_bus_client = ServiceBusClient.from_connection_string(connection_string) # Create a receiver to listen to the queue receiver = service_bus_client.get_queue_receiver(queue_name="your-queue-name") # Start receiving and processing messages with receiver: for message in receiver: process_message(message) message.complete() # Mark the message as completed after processing
复制代码
将上述代码部署为 Kubernetes 中的容器化应用程序。
步骤 2: 配置 KEDA 支持自动缩放。为了使 KEDA 能够监控队列长度并触发自动缩放，需要创建 ScaledObject 并进行相应部署。
# scaledobject.yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: queue-scaler spec: scaleTargetRef: deploymentName: your-deployment-name triggers: - type: azure-servicebus metadata: connection: "your-connection-string" queueName: "your-queue-name" name: queue-length-trigger queueLength: "5" # Scale when the queue length is greater than or equal to 5
复制代码
# deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: your-deployment-name spec: replicas: 1 # Initial number of replicas template: spec: containers: - name: your-container-name image: your-container-image
复制代码
将上述 YAML 文件应用到 Kubernetes 集群，以创建 ScaledObject 和部署。
步骤 3: 现在，当消息到达 Azure 服务总线队列时，KEDA 将监控队列长度并根据定义的阈值触发自动缩放(在本例中，阈值为队列长度大于或等于 5)。
可以通过监控部署的副本数量来观察自动伸缩:
kubectl get deployment your-deployment-name
复制代码
当队列长度超过定义的阈值时，KEDA 将自动扩展副本数量以处理增加的工作负载。一旦队列长度减少，KEDA 将相应的减少副本，从而优化资源利用率。
这个用例演示了 KEDA 如何根据 Azure 服务总线队列的长度自动扩展 Kubernetes pod。通过利用 KEDA 的可扩展性和事件驱动的扩展功能，可以确保有效的资源利用和对不同工作负载的响应。示例说明了 KEDA 在基于自定义指标动态调整 pod 数量方面的强大功能，使其成为一种有价值的扩展工具。
结论
Kubernetes pod 自动伸缩是有效管理动态工作负载的基本特性。Kubernetes 通过 HPA 提供了内置的自动缩放功能，KEDA 为事件驱动缩放和自定义指标提供了强大扩展。通过将 KEDA 整合到 Kubernetes 集群中，可以释放实时自动扩展的潜力，使应用程序能够无缝适应不断变化的需求。虽然 KEDA 引入了额外的复杂性，但有助于提高应用集群的资源效率、可扩展性和可伸缩性。
你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。微信公众号：DeepNoMind
