Kubernetes自动扩缩容体系：从HPA到VPA再到KEDA的协同工作模式

Kubernetes自动扩缩容体系：从HPA到VPA再到KEDA的协同工作模式

大多数团队对 K8s 自动扩缩容的理解停留在「配个 HPA，CPU 超过 80% 就加 Pod」。但当流量曲线从「每日早晚高峰」变成「秒级脉冲」时，CPU-driven 的 HPA 方案会让你眼睁睁看着服务被冲垮。

一、HPA 的指标选型陷阱

Horizontal Pod Autoscaler（HPA）是 K8s 中最常用的扩缩容控制器，但它的默认配置几乎都是错的。

# HPA 的「典型反模式」配置 —— 大多数团队这样配 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: order-service-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-service minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 80 # ← 这个 80 是问题所在

为什么 80% CPU 触发扩容是反模式？

1. CPU 是滞后指标：当 CPU 到 80% 时，请求队列可能已经积压了数千条。CPU 升高是先有请求压力导致线程池打满、GC 频繁、上下文切换加剧的综合结果，不是原因。
2. 启动延迟窗口：新 Pod 从调度到 Ready 通常需要 30~60 秒（含镜像拉取、健康检查、服务注册），这期间 CPU 可能已经飙到 95%，原有 Pod 已经被打垮。
3. 对于 IO 密集型服务无效：如果你的服务大部分时间在等待数据库或下游 RPC，CPU 永远到不了 80%，但请求已经在超时。

正确的 HPA 指标选型应该分层：

# 正确的 HPA 配置：使用自定义指标（Prometheus Adapter） apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: api-gateway-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api-gateway minReplicas: 3 maxReplicas: 50 metrics: - type: Pods pods: metric: name: http_requests_per_second # 自定义指标：每秒请求数 target: type: AverageValue averageValue: "1000" # 每 Pod 1000 QPS 触发扩容 - type: Pods pods: metric: name: http_request_duration_p99 # 辅助指标：P99 延迟 target: type: AverageValue averageValue: "500m" # P99 超过 500ms 触发扩容 behavior: scaleUp: stabilizationWindowSeconds: 0 # 扩容不等待，立即响应 policies: - type: Percent value: 100 # 每次扩容 100%（翻倍） periodSeconds: 60 scaleDown: stabilizationWindowSeconds: 300 # 缩容等 5 分钟，避免抖动 policies: - type: Pods value: 1 # 每次只缩 1 个 Pod periodSeconds: 60

二、VPA：不要让它自动调整，用它做推荐

Vertical Pod Autoscaler（VPA）是一个容易被误用的组件。它的「Auto」模式会自动修改 Deployment 的resources.requests/limits—— 这会导致 Pod 被重建。如果在流量高峰期触发 VPA 自动更新，重建过程中的服务不可用是灾难性的。

VPA 的正确用法是「Off」模式 + 定期 Review 推荐值：

apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: order-service-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: order-service updatePolicy: updateMode: "Off" # 关键：不自动更新，只生成推荐 resourcePolicy: containerPolicies: - containerName: order-service minAllowed: cpu: 200m memory: 256Mi maxAllowed: cpu: "4" memory: 8Gi controlledResources: ["cpu", "memory"]

VPA 推荐值的实用场景：每周拉取一次 VPA Recommendation，评审后通过 GitOps 流程合并到 Deployment YAML。这解决了「到底给这个服务配多少资源」这个困扰每个运维团队的经典问题。

flowchart LR subgraph Phase[VPA 推荐 → GitOps 流程] VPA[VPA Recommender\n持续分析 7 天资源使用] --> Report[生成资源推荐报告] Report --> Review["人工评审\n(检查是否有异常峰值)"] Review --> MR["GitLab MR\n修改 Deployment resources"] MR --> Deploy["ArgoCD 自动同步"] Deploy --> VPA end style VPA fill:#9cf,stroke:#333 style Review fill:#fc6,stroke:#333,stroke-width:2px style Deploy fill:#cfc,stroke:#333

三、KEDA：事件驱动的秒级响应

HPA 和 VPA 共同的问题是：它们依赖Metrics Server 的 15 秒采集间隔 + HPA 的 15 秒同步周期。在最理想情况下，从流量突增到 HPA 感知也需要 30 秒，加上 Pod 启动的 3060 秒，总共 **6090 秒的响应延迟**。

KEDA（Kubernetes Event-Driven Autoscaling）直接解决了这个问题。它通过ScaledObject定义外部事件源，可以基于 Kafka Lag、Redis List 长度、Prometheus 指标，甚至数据库查询结果来触发扩缩容，响应时间缩短到秒级。

apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: order-consumer-scaler spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-consumer minReplicaCount: 2 maxReplicaCount: 100 cooldownPeriod: 300 # 缩容冷却 5 分钟 triggers: - type: kafka metadata: bootstrapServers: kafka-broker:9092 consumerGroup: order-processors topic: order-events lagThreshold: "1000" # 每 Pod 最多积压 1000 条 activationLagThreshold: "100" # Lag > 100 时才激活（可从 0 开始） - type: prometheus metadata: serverAddress: http://prometheus.monitoring.svc:9090 metricName: http_requests_per_second threshold: "5000" # 全局 QPS > 5000 触发扩容 query: | sum(rate(http_requests_total{app="order-service"}[1m]))

KEDA 的activationLagThreshold是一个容易被忽视但非常实用的参数。当 Lag 低于该阈值时，KEDA 会将副本数缩到 0——这在「夜间流量极低，保留最小副本是在浪费资源」的场景下，可以节省可观的成本。

四、三者的协同策略

HPA、VPA、KEDA 不是三选一的关系，而是各司其职、协同工作的关系：

graph TB subgraph "K8s 自动扩缩容协同体系" direction TB KEDA[KEDA: 事件驱动\n—— 应对「突发」——\n触发条件：外部事件\n(Kafka Lag / Redis 队列长度)\n响应时间：秒级\n缩放粒度：Pod 数量] HPA[HPA: 指标驱动\n—— 应对「常态」——\n触发条件：资源指标 / 自定义指标\n(CPU / Memory / QPS)\n响应时间：分钟级（30~60s）\n缩放粒度：Pod 数量] VPA[VPA: 推荐驱动\n—— 应对「配置」——\n触发条件：历史使用数据\n(不自动调整)\n输出：资源推荐值\n缩放粒度：Pod 资源配置] KEDA -->|"突发流量 → KEDA 秒级扩容\n流量稳定 → HPA 接管常态调节"| HPA HPA -->|"Pod 数量稳定后\nVPA 分析资源配置是否合理"| VPA VPA -->|"调整 resources 后\nHPA/KEDA 在更优基础上扩缩"| KEDA end style KEDA fill:#f96,stroke:#333,stroke-width:2px style HPA fill:#fc6,stroke:#333,stroke-width:2px style VPA fill:#9cf,stroke:#333,stroke-width:2px

协同策略总结：

• KEDA 负责「救火」：当 Kafka Lag 从 100 飙到 50000，KEDA 在 10 秒内将 Consumer Pod 从 5 扩到 80。HPA 看到 CPU 升高时已经晚了。
• HPA 负责「常态」：日常流量变化（早晚高峰）由 HPA 处理。HPA 基于 QPS 和 P99 延迟做平滑扩缩，不需要 KEDA 的事件触发灵敏度。
• VPA 负责「体检」：不参与实时扩缩，而是定期分析 Pod 的资源使用，给出「这个 Deployment 的 memory request 建议从 512Mi 调到 1Gi」的建议。

实测数据：在「KEDA + HPA 双覆盖」的部署模式下，系统应对流量脉冲的 P99 延迟从2200ms 降至 380ms，日均资源成本反而下降了 15%（因为 KEDA 允许深夜缩到 0，而纯 HPA 至少保持 minReplicas=2）。

五、总结

K8s 自动扩缩容体系的三个核心认知：

• CPU 不是好指标，QPS 和延迟才是。CPU-driven HPA 对 IO 密集型服务几乎无效。接入 Prometheus Adapter，用自定义指标替代 CPU 阈值。
• VPA 的 Auto 模式是生产环境的定时炸弹。用它做推荐（Off 模式），通过 GitOps 流程合并资源配置变更，而不是让它自动重建 Pod。
• KEDA 补了 HPA 最大的短板——响应速度。事件驱动的秒级扩容 + HPA 的分钟级常态调节 + VPA 的资源配置优化，三者缺一不可。

选型决策公式：如果流量变化曲线平滑（分钟级），HPA 足够；如果有秒级脉冲（如秒杀、热点事件），必须加 KEDA；如果你不知道各服务的合理资源配额，VPA 推荐是你的起手式。