Kubernetes HPA 与 KEDA 事件驱动伸缩（指标、队列与验证）

## 概述 HPA基于资源或自定义指标进行伸缩, KEDA以触发器驱动事件型伸缩。二者结合可同时覆盖CPU、内存等资源波动与消息队列堆积等事件压力, 提升系统弹性与成本效率。 ## 关键实践与参数 - HPA资源指标: `targetCPUUtilizationPercentage=60` 或 `resource.memory` - HPA副本边界: `minReplicas=2` `maxReplicas=20` - KEDA触发器: `rabbitmq` `kafka` `prometheus` 等, 队列长度阈值按峰值设定 - 冷启动与预热: 关键路径副本下限提高并配合就绪探针 - 稳定窗口与回落: 合理 `stabilizationWindowSeconds` 与 `behavior.scaleDown` ## 示例/配置/实现 ```yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: api-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 behavior: scaleDown: stabilizationWindowSeconds: 120 policies: - type: Percent value: 20 periodSeconds: 60 ``` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: worker-queue spec: scaleTargetRef: name: worker minReplicaCount: 1 maxReplicaCount: 50 triggers: - type: rabbitmq metadata: host: amqp://user:pass@rabbitmq:5672/ queueName: jobs queueLength: "100" ``` ## 验证 - 资源型伸缩: 压测提高CPU占用, 观察HPA在稳定窗口内渐进扩容与回落 - 事件型伸缩: 向队列写入消息使长度超过阈值, 观察KEDA副本数上升至上限并在处理完成后回落 - 服务可用性: 结合就绪与存活探针, 扩缩容期间请求成功率保持稳定 - 成本与效率: 在日间与夜间流量下比较副本平均值与处理耗时, 确认弹性带来的资源节约 ## 注意事项 - 队列阈值需结合峰值与处理速率, 防止过度抖动 - 工作负载需幂等, 在并发扩容时确保任务处理安全 - 与PodDisruptionBudget协同, 防止缩容影响可用性 - 在多触发器场景下配置上限与优先级, 防止资源竞争