一文搞懂使用 KEDA 实现 Kubernetes 自动弹性伸缩

Hello folks，我是 Luga，今天我们来聊一下云原生生态领域相关的技术 - Auto Scaling ，即 “弹性伸缩” 。

在当今的云原生生态系统中，基于波动的工作负载和动态的流量模式已经成为常态，传统的IT基础设施面临着巨大的挑战。这种不可预测的行为使得我们需要重新思考基础设施管理的方式。

与传统的静态基础设施不同，现代云原生解决方案提供了更加灵活和自动化的弹性伸缩能力。通过运用容器化技术和编排工具，如 Kubernetes，我们可以根据负载需求的变化自动进行伸缩，实现资源的弹性调配。

— 01 —

什么是 Kubernetes Autoscaling ？

Kubernetes Autoscaling 是 Kubernetes 容器编排系统中的一项动态功能，可以根据工作负载需求自动调整计算资源。这一功能通过平衡和优化资源分配，既能维持应用程序的性能，又能避免财务浪费。通过增加资源来处理流量激增，确保最佳性能，并在空闲期间部署较少的资源以节省成本。

Kubernetes Autoscaling 的好处包括最大限度地提高资源利用率、提供成本效益以及保证应用程序的持续可用性。任何使用 Kubernetes 的组织都可以从 Autoscaling 中获益，尤其是当应用程序在繁忙和空闲时期之间切换时。

Autoscaling 的关键优势之一是提供了弹性和敏捷性，可以根据实际需求动态调整资源。当负载增加时，Autoscaling 能够快速响应并自动扩展应用程序的副本数量，以满足当前的需求。这种扩展能力可确保应用程序具备足够的资源来处理高负载情况，从而避免性能瓶颈和用户体验下降。相反，在负载减少时，Autoscaling 可以自动缩减应用程序的副本数量，以节省成本并提高资源利用率。

此外，Autoscaling 还带来了更好的成本效益。通过根据实际需求调整资源配置，可以避免不必要的资源浪费。在高峰期间，通过增加资源来满足需求，可以确保最佳性能，但在空闲期间，可以减少资源并节省资金。这种动态的资源管理策略能够实现资源的最佳利用，提高成本效益。

关于 ‍‍Kubernetes Autoscaling 更多详细内容可参考如下链接文章，具体：

— 02 —

Kubernetes 原生 H/VPA Autoscaling 存在的弊端‍‍

尽管 Kubernetes 的 HPA（Horizontal Pod Autoscaler）和 VPA（Vertical Pod Autoscaler）提供了 Autoscaling 能力，但它们也存在一些潜在的瓶颈和限制，具体如下所示：

1. 延迟和响应时间

HPA 和 VPA 的 Autoscaling 过程需要一定的时间来监测指标并作出调整，从而可能会导致在负载突然增加或减少时出现一定的延迟，无法立即响应变化。这种延迟可能会导致性能下降或资源浪费。

2. 指标选择和配置

同时，HPA 和 VPA 的 Autoscaling 依赖于指标的选择和配置。选择不合适的指标或错误地配置指标阈值可能导致扩缩容的不准确性。因此，正确选择和配置指标是确保 Autoscaler 有效运行的重要因素。

3. 基础设施强绑

HPA 和 VPA 依赖于底层基础设施的可扩展性和弹性。如果底层基础设施无法满足自动扩缩容的需求，例如，底层节点资源有限或网络带宽不足，那么自动弹性伸缩的效果将受到限制。

4. 应用程序设计限制

在实际的业务场景中，往往存在某些应用程序可能不适合自动扩缩容，特别是具有持久性状态或特定调度要求的应用程序。这些应用程序可能需要采取额外的措施来处理自动扩缩容引起的状态管理或数据持久性问题。

5. 实施的复杂性

通常而言，为 H/VPA 创建自定义指标可能并非易事。这个过程需要对 Kubernetes 内部结构有一定的了解，并需要开发人员深入研究相关接口和进行复杂的代码修改。因此，对于没有相关经验的开发人员来说，这可能是一个具有挑战性的任务。从长远角度来看，这种额外的复杂性可能会导致维护困难。

— 03 —

什么是 KEDA 以及 KEDA 解决了哪些痛点 ？

前面我们提到了 Kubernetes 内置提供的解决方案在开销或实用性方面能力是非常有限的。如果我们想更优雅地扩展事件驱动的应用程序，此时，则需要另寻他路。或许，KEDA 是一种不可多得的选择。

那么，KEDA 到底是什么？

KEDA（基于 Kubernetes 的事件驱动自动缩放器）是一个由微软和红帽创建的开源项目，目前已从云原生计算基金会（CNCF）毕业，采用 Apache 2.0 许可证。KEDA 的主要目标是为在 Kubernetes 上运行的事件驱动应用程序提供更好的扩展选项。

在目前的 Kubernetes 环境中，水平 Pod 自动缩放器（HPA）仅对基于资源的指标作出反应，例如 CPU 或内存使用情况，或者自定义指标。然而，对于那些可能经历突发数据流的事件驱动应用程序来说，HPA 的扩展速度可能相当缓慢。此外，一旦数据流减缓，HPA必须缩小规模并删除多余的 Pod，导致不必要的资源继续产生费用。

KEDA 的出现填补了这一缺失，通过引入事件驱动的自动弹性伸缩机制，使得在 Kubernetes 上运行的事件驱动应用程序可以更加高效地扩展。KEDA 可以根据事件流的速率和规模动态地调整应用程序的副本数量，以满足负载需求。这意味着在应用程序需要处理大量事件时，KEDA 可以快速扩展并自动添加 Pod 实例，以确保高吞吐量和低延迟。

另一个 KEDA 的优势是它支持多种事件源，如 Azure 队列、Kafka、RabbitMQ 等，使得应用程序能够从不同来源接收事件。这为开发人员提供了更大的灵活性和选择性，可以根据应用程序的需求选择适当的事件源。

如下为基于 KEDA 使用 Prometheus 指标触发 Autoscaling 机制的示例，具体：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: prometheus-scaledobject
  namespace: devops
spec:
  scaleTargetRef:
    apiVersion: argoproj.io/v1alpha1
    kind: Rollout
    name: keda-devops-demo
  triggers:
    - type: prometheus
      metadata:
      serverAddress:  http://<prometheus-host>:9090
      metricName: http_request_total
      query: envoy_cluster_upstream_rq{appId="300", cluster_name="300-0", container="envoy", namespace="demo3", response_code="200" }
      threshold: "50"
  idleReplicaCount: 0                       
  minReplicaCount: 1
  maxReplicaCount: 10

在上述 ScaledObject 对象和 KEDA 定义中，我们指定了一个 ScaledObject 的示例，使用 Prometheus 指标来配置 KEDA Autoscaling。部署对象“keda-devops-demo”将根据 Prometheus 指标“sum(irate(by_path_counter_total{}[60s]))”来监控 HTTP 请求的数量。如果该指标的值超过 50，则 KEDA 将根据需要创建新的 Pod 来处理请求。如果该指标的值低于 50，则 KEDA 将根据需要删除多余的 Pod，以确保资源利用率的最大化。

该示例展示了如何使用 KEDA 来根据 Prometheus 指标来动态缩放应用程序的规模。KEDA 提供了灵活的配置选项，可以满足不同的业务需求。

通过这种配置，系统能够根据实际的 HTTP 请求负载情况来动态调整应用程序的规模。当负载增加时，Autoscaling 机制将创建更多的 Pod 来处理请求，从而保持应用程序的性能和可用性。一旦负载减轻，Autoscaling 机制便将适时地缩减 Pod 的数量，以节省资源和成本。

那么，KEDA 帮助 SRE 和 DevOps 团队解决了哪些问题或痛点？如下为一些参考，具体：

1、降低成本

KEDA 在事件驱动应用程序的 Autoscaling 方面提供了更高的灵活性和精确性。它能够根据事件的到达速率和规模来动态调整应用程序的副本数量，从而更好地适应不断变化的负载情况。在没有待处理的事件时，KEDA 具有将 Pod 数量减少到零的能力。相比之下，使用标准 HPA 很难实现这一点。这种功能对于确保资源的有效利用和成本优化非常有帮助，最终可以降低云计算费用。

2、提高可用性

截至目前，KEDA 已经支持了 59 个内置缩放器和 4 个外部缩放器。这些外部缩放器包括 KEDA HTTP 和 KEDA Scaler for Oracle DB 等。通过使用外部事件作为触发器，KEDA 能够实现高效的自动缩放，尤其适用于消息驱动的微服务，如支付网关或订单系统。

此外，由于 KEDA 的灵活性，可以无缝融入任何 DevOps 工具链。无论我们使用的是 Jenkins、GitLab、Prometheus 还是其他 DevOps 工具，KEDA 可以与之进行集成，使得 Autoscaling 成为整个开发和部署流程的一部分。这样，我们可以在保持流程的连续性和一致性的同时，充分利用 KEDA 的自动扩缩容能力，实现高效的应用程序管理。

3、提升性能

借助 KEDA，SRE 和 DevOps 团队可以根据负载波动情况来动态调整应用程序的资源配置。通过快速响应和自动扩缩容的能力，KEDA 确保应用程序始终具备足够的资源来应对负载变化，从而保持系统高性能运行。同时，监控和指标收集功能使得 SRE 和 DevOps 团队能够实时监测和优化应用程序的性能。

— 04 —

KEDA 是如何工作的 ？

作为 Kubernetes 的事件驱动 Autoscaling 工具，KEDA 可以根据应用程序的事件源来自动调整 Pod 的数量。KEDA 部署简单，只需在 Kubernetes 集群中创建一个 ScaledObject 对象即可。ScaledObject 对象包含 KEDA 的配置信息，包括事件源、缩放规则等。

在部署 KEDA 后，缩放器将会像一个哨兵一样，持续监视事件源，并在发生任何触发事件时将指标传递给指标适配器。指标适配器会像一个翻译员一样，将指标调整为控制器组件可以理解的格式，并将其提供给控制器组件。控制器组件会根据 ScaledObject 中设置的扩展规则来做出扩大或缩小的决策，并将决策执行到 Pod 上。

通常来讲，KEDA 与 Kubernetes 水平 Pod 自动缩放器（Horizontal Pod Autoscaler，HPA）、外部事件源以及 Kubernetes 的数据存储之间的协作关系，可参考如下图所示：

上述参考流程图描述了 KEDA 如何与 HPA 配合应用 Pod 进行自动弹性伸缩，这里，针对此实现架构图进行简要解析，具体实现流程如下：

1、 Kubernetes API Server 充当 KEDA 和 Kubernetes 之间集成的桥梁，将 KEDA 的自动弹性伸缩功能与 Kubernetes 的资源管理功能相结合。KEDA 通过 ScaledObject 对象将自动弹性伸缩的机制与 Kubernetes 资源对象相结合。KEDA 的核心组件包括指标适配器、控制器、缩放器和准入 Webhooks。

2、Metrics Adapter 和准入 Webhooks 从外部触发源收集指标，具体取决于 ScaledObject 对象中定义的触发器类型。Metrics Adapter 将指标转换为 Kubernetes 指标，并将其暴露给 Controller。准入 Webhooks 负责验证和修改 ScaledObject 对象，以确保 KEDA 能够正确地进行自动弹性伸缩。

3、Controller 和 Scaler 负责根据 Metrics Adapter 收集的指标来进行自动弹性伸缩。Controller 负责将弹性任务发送给 Scaler。Scaler 负责将缩放任务应用到 Kubernetes 资源对象。

4、外部触发源可以是任何可以提供指标数据的来源，例如 Apache Kafka、Prometheus、AWS CloudWatch 等。外部触发源负责直接从正在运行的服务收集系统指标。如果工作负载很高，Pod 将会被横向扩展。如果工作负载较低，则对 Pod 进行缩容。如果完全没有工作负载，则将删除 Pod，以最终优化基础设施资源。

通常而言，KEDA 核心由三个关键组成部分组成，具体涉及如下：

1、Metrics Adapter

KEDA 中的 Metrics Adapter 是负责将事件数据转换为 Kubernetes 指标的组件。Metrics Adapter 采用了“事件驱动”的设计理念，将事件数据转换为 Kubernetes 指标，并通过 Kubernetes 的 API Server 暴露给水平 Pod 自动缩放器。

2、Admission Webhooks

KEDA 中的 Admission Webhooks 是负责验证和修改 Kubernetes 对象的组件。Admission Webhooks 可以用于验证和修改 ScaledObject 对象，以确保 KEDA 能够正确地进行自动缩放。

KEDA 提供了两种 Admission Webhook 联系，一种是用于验证和修改 ScaledObject 对象的 ScaledObject Admission Webhook 类型，另一种则是用于验证和修改 Trigger 对象的 Trigger Admission Webhook 类型。

3、Agent

KEDA 中的 Agent 是负责监控事件源并将事件数据传递给 KEDA 控制器的组件。KEDA 提供了多种 Agent，可以满足不同的事件源需求。通常情况下，在没有事件的情况下，Agent 组件会将部署调整至零副本，以免浪费资源。

在不断发展的云原生应用程序环境中，适应动态工作负载是至关重要的。Kubernetes 提供了 HPA 和 VPA 等本机工具来实现自动缩放，但它们在应对非 CPU 和 RAM 指标驱动的负载时存在局限性。

KEDA 是 Kubernetes 的扩展，克服了 HPA 和 VPA 的局限性，并提供了更灵活和全面的自动缩放解决方案。KEDA 可以根据任何指标进行缩放，包括 HTTP 请求数、消息队列长度、数据库连接数等。此外，KEDA 还支持缩小到零、触发 Kubernetes Job、发出用于诊断的实时事件以及通过身份验证提供程序维护安全连接。

与 HPA 和 VPA 相比，KEDA 具有以下优势：

1、更灵活：KEDA 可以根据任何指标进行缩放，而 HPA 和 VPA 仅限于 CPU 和 RAM 指标。

2、更全面：KEDA 支持缩小到零、触发 Kubernetes Job、发出用于诊断的实时事件以及通过身份验证提供程序维护安全连接。

3、更易于使用：KEDA 的配置更简单，减少了用户在使用 Kubernetes 自定义指标时面临的典型障碍。

以上为 KEDA 的相关解析，更多内容可参考后续文章所述，谢谢！

Reference ：

[1] https://keda.sh/docs/2.12/concepts/

Adiós !