9.3 极致弹性：基于 KEDA 与 Prometheus 的业务指标扩容实战

9.3 极致弹性：基于 KEDA 与 Prometheus 的业务指标扩容实战

1. 引言：CPU 指标的局限性

传统的 HPA 基于 CPU/Memory 指标扩容，但在很多场景下，CPU 低不代表系统负载低。

典型场景：

• 消息队列堆积：Consumer 处理慢，CPU 只有 10%，但 Kafka 里堆积了 100 万条消息
• 数据库连接池耗尽：CPU 正常，但连接池满了，新请求被拒绝
• HTTP 请求延迟：CPU 正常，但响应时间变慢（可能是下游服务慢）

这些场景下，基于 CPU 的 HPA 不会扩容，导致服务不可用。

KEDA（Kubernetes Event-driven Autoscaling）的出现，解决了这个问题。它支持基于业务指标（如消息队列长度、HTTP 延迟、数据库连接数）进行扩容。

2. KEDA 核心概念

2.1 什么是 KEDA？

KEDA 是 CNCF 项目，专门用于事件驱动的自动伸缩。

核心思想：

• 将外部系统（如 Kafka、Redis、Prometheus）的指标转换为 K8s 的 HPA 指标
• KEDA 不替代 HPA，而是增强HPA

2.2 架构

外部系统 (Kafka/Redis/Prometheus) ↓ (指标) KEDA ScaledObject ↓ (转换为 HPA 指标) HPA ↓ (扩容/缩容) Deployment

3. 实战一：基于 Kafka Lag 扩容

3.1 场景

Consumer 处理 Kafka 消息，当消息堆积时自动扩容。

3.2 部署 KEDA

helm repoaddkedacore https://kedacore.github.io/charts helminstallkeda kedacore/keda --namespace keda-system --create-namespace

3.3 创建 ScaledObject

apiVersion:keda.sh/v1alpha1kind:ScaledObjectmetadata:name:kafka-scaledobjectspec:scaleTargetRef:name:message-consumerminReplicaCount:1maxReplicaCount:10triggers:-type:kafkametadata:bootstrapServers