一、创新看点
传统 HPA | KEDA (Kubernetes Event-Driven Autoscaler) |
仅基于 CPU / 内存指标触发 | 支持 50+ 事件源：Kafka、Prometheus、Redis、HTTP QPS… |
采样周期 ≥15s，响应慢 | 秒级拉起新 Pod，平峰可自动归零 |
每个资源写一份 HPA YAML | 单一 ScaledObject 即可完成尺度策略 |
无法对非 Deployment 资源 | 支持 Job / StatefulSet / Cron |
二、整体架构
┌───────────────┐ metrics ┌─────────────┐
│ Event Source │────────────│ KEDA Scaler │
│ (Kafka / SQS) │ └──────┬──────┘
└───────────────┘ │
Creates HPA │
▼
┌──────────────┐
│ Workload │
│(Deployment) │
└──────────────┘
三、环境要求
- Kubernetes 1.26+
- Helm 3.10+
- 示例事件源：Redis5、Prometheus2.46
- 4C8G以上测试节点
四、实战落地 7步
步骤1：安装 KEDA Operator
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --namespace keda --create-namespace
步骤2：部署示例应用
kubectl create ns demo
kubectl apply -n demo -f https://raw.githubusercontent.com/kedacore/keda/main/examples/redis/redis-deploy.yaml
kubectl apply -n demo -f https://raw.githubusercontent.com/kedacore/keda/main/examples/redis/consumer-deploy.yaml
- redis：事件源
- consumer：耗时 100ms 模拟业务处理
步骤3：创建 ScaledObject（Redis 队列长度）
scaledobject.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: redis-scaler
namespace: demo
spec:
scaleTargetRef:
name: consumer
minReplicaCount: 0
maxReplicaCount: 30
triggers:
- type: redis
metadata:
address: redis.demo:6379
listName: jobs
listLength: "5"
kubectl apply -f scaledobject.yaml
步骤4：压测注入消息
for i in {1..500}; do
kubectl exec deploy/redis -n demo -- \
redis-cli LPUSH jobs "task-$i"
done
观察：
watch kubectl get hpa,deploy -n demo
- 队列 >5 时，Pod 秒级扩容
- 消费完毕自动缩回 0
步骤5：改造 HTTP QPS 触发
安装 Prometheus Adapter：
helm install adapter prometheus-community/kube-prometheus-stack \
-n monitoring --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false
定义自定义指标：
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: api-scaler
namespace: demo
spec:
scaleTargetRef:
name: api
cooldownPeriod: 60
pollingInterval: 15
maxReplicaCount: 20
triggers:
- type: prometheus
metadata:
serverAddress: http://prometheus.monitoring:9090
query: |
sum(rate(http_requests_total{app="api"}[1m]))
threshold: "150"
步骤6：开启预热（Warm-up）
advanced:
restoreToOriginalReplicaCount: true
horizontalPodAutoscalerConfig:
behavior:
scaleUp:
stabilizationWindowSeconds: 0
policies:
- type: Pods
value: 5
periodSeconds: 30
防止冷启动导致高延迟。
步骤7：生产级优化
项 | 建议 |
日志 | kubectl logs -n keda deploy/keda-operator 快速定位规则 |
可观测 | 导入官方 Grafana Dashboard 12465 监控 Scaler 延迟 |
HA | KEDA Operator 副本数调 3，LeaderElection on |
多租户 | triggerAuthentication 绑定独立 Secret，避免凭据串用 |
五、效果对比
场景 | 原始 3Pod 固定 | KEDA 动态 0-30 | 资源节省 |
平峰（QPS10） | 3Pod × 100m = 300m | 0Pod | 100% |
高峰（QPS800） | 3Pod CPU 饱和，延迟 800ms | 25Pod，延迟 120ms | 延迟 ↓85% |
六、总结
借助 KEDA，“扩容”不再局限 CPU/内存，而真正以“业务事件”驱动，让你的 Kubernetes 集群 按需呼吸。跟着本指南 7步，你就能在 30分钟内完成落地，最多节省 70% 资源账单，还能在高峰时刻保持丝滑体验。赶快把 HPA 升级到 Event-Driven 时代吧！