概述
KEDA (Kubernetes Event Driven Autoscaling) 是一个基于事件驱动的自动缩放器,支持将工作负载缩容到0个副本,这是传统HPA无法实现的重要功能。
核心特性
1. 零副本缩放
- 完全释放资源: 当没有事件触发时,Pod数量可以缩放到0,不消耗任何计算资源
- 快速响应: 当检测到触发条件时,立即从0扩容到所需副本数
- 成本优化: 在空闲时间完全停止工作负载,显著降低云资源成本
2. 事件驱动机制
KEDA支持多种触发器类型:
- Cron触发器: 基于时间调度的扩缩容
- 消息队列: Redis、RabbitMQ、Kafka等
- HTTP请求: 基于HTTP请求数量
- 数据库: MySQL、PostgreSQL等查询结果
- 云服务: AWS SQS、Azure Service Bus等
配置示例分析
Deployment配置
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: keda-test
namespace: default
spec:
replicas: 0 # 初始副本数设为0,由KEDA控制
selector:
matchLabels:
app: keda-test
template:
metadata:
labels:
app: keda-test
spec:
containers:
- name: keda-test
image: busybox
command: ["sh", "-c", "echo Hello KEDA; sleep 30"]关键点:
replicas: 0: 初始状态设为0副本- 由KEDA的ScaledObject来控制实际的副本数量
ScaledObject配置
yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: keda-cron-scaledobject
namespace: default
spec:
scaleTargetRef:
name: keda-test # 目标Deployment名称
pollingInterval: 15 # 每15秒检查一次触发条件
cooldownPeriod: 30 # 触发结束后30秒开始缩容
minReplicaCount: 0 # 最小副本数为0(关键配置)
maxReplicaCount: 2 # 最大副本数为2
triggers:
- type: cron
metadata:
timezone: "Asia/Shanghai"
start: "0 * * * *" # 每小时第0分钟开始扩容
end: "30 * * * *" # 每小时第30分钟停止扩容
desiredReplicas: "1" # 扩容时的目标副本数核心参数说明
minReplicaCount: 0
- 这是实现缩容到0的关键配置
- 当没有触发条件满足时,副本数会缩放到0
- 传统HPA的最小值通常是1
pollingInterval
- KEDA检查触发条件的频率
- 设置过短会增加API服务器负载
- 设置过长会影响响应速度
cooldownPeriod
- 触发条件不满足后,等待多长时间开始缩容
- 防止频繁的扩缩容操作
- 给工作负载足够的时间完成当前任务
工作流程
- 初始状态: Deployment副本数为0,没有Pod运行
- 触发检测: KEDA每15秒检查一次cron触发条件
- 扩容阶段: 当时间匹配
start条件时,扩容到1个副本 - 运行阶段: Pod执行任务,KEDA持续监控
- 缩容阶段: 当时间超过
end条件后,等待30秒后缩容到0
观察过程
初始时,KEDA会将Deployment的副本数保持在0,直到触发条件满足。 
应用keda-test的ScaledObject后,开始创建pod。


结束之后开始销毁pod 
整个执行流程 
使用场景
1. 定时任务
- 数据备份作业
- 报表生成
- 系统维护任务
2. 事件驱动处理
- 消息队列处理
- 文件上传处理
- API请求突发处理
3. 成本优化
- 开发/测试环境的资源节约
- 非业务高峰期的资源释放
- 按需付费的云环境优化
优势对比
| 特性 | 传统HPA | KEDA |
|---|---|---|
| 最小副本数 | 1 | 0 |
| 触发器类型 | CPU/内存 | 60+种事件源 |
| 资源消耗 | 始终占用资源 | 可完全释放 |
| 响应速度 | 分钟级 | 秒级 |
| 成本效益 | 一般 | 极高 |
注意事项
- 冷启动延迟: 从0扩容需要额外的Pod启动时间
- 状态保存: 确保应用是无状态的,或妥善处理状态恢复
- 监控告警: 需要监控KEDA组件本身的健康状态
- 权限配置: KEDA需要适当的RBAC权限来管理工作负载
最佳实践
- 合理设置时间间隔: 根据实际需求调整pollingInterval和cooldownPeriod
- 资源限制: 设置合适的CPU和内存限制
- 健康检查: 配置适当的readiness和liveness探针
- 日志监控: 监控KEDA和应用的日志以便故障排查
- 测试验证: 在生产环境部署前充分测试扩缩容行为
总结
KEDA的缩容到0功能是其最具价值的特性之一,特别适合事件驱动和间歇性工作负载。通过合理配置,可以在保证服务可用性的同时显著降低资源成本。