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 ↓ (扩容/缩容) Deployment3. 实战一：基于 Kafka Lag 扩容
3.1 场景
Consumer 处理 Kafka 消息，当消息堆积时自动扩容。
3.2 部署 KEDA
helm repoaddkedacore https://kedacore.github.io/charts helminstallkeda kedacore/keda --namespace keda-system --create-namespace3.3 创建 ScaledObject
apiVersion:keda.sh/v1alpha1kind:ScaledObjectmetadata:name:kafka-scaledobjectspec:scaleTargetRef:name:message-consumerminReplicaCount:1maxReplicaCount:10triggers:-type:kafkametadata:bootstrapServers
