Kubernetes 自动伸缩对决：HPA vs. VPA vs. Karpenter vs. KEDA
Source: Dev.to
两层伸缩
在分析具体工具之前，必须先了解 Kubernetes 的伸缩发生在两个不同的层面：
- Pod 伸缩（应用层）： 调整 Pod 副本数量或单个 Pod 的规模。这关系到应用的容量。
- Node 伸缩（基础设施层）： 调整集群中虚拟机（节点）的数量，以支撑 Pod。它关系到计算资源的容量。
如果你只伸缩 Pod 而没有可供放置的节点，伸缩会失败（Pending Pods）。如果只伸缩节点而 Pod 并未利用它们，则会浪费金钱。伸缩的艺术在于同步这两个层面。
第 1 层：Pod 级别伸缩
1. Horizontal Pod Autoscaler (HPA)
工作原理
HPA 定期（默认 15 秒）查询 metrics server（或自定义指标 API）。它将当前指标值（例如 CPU 利用率）与 HorizontalPodAutoscaler 资源中定义的目标值进行比较。如果当前使用率超过目标，HPA 计算所需的副本数并更新 Deployment 或 StatefulSet 的 scale 子资源。
公式
优势
- 原生且简单： 基本的 CPU/Memory 伸缩不需要外部 CRD。
- 弹性： 通过在更多实例间分配负载，完美应对流量突增。
- 零停机： 扩容不需要重启已有 Pod。
劣势
- 冷启动： HPA 属于被动响应。如果你的应用启动需要约 60 秒（例如 JVM 应用），在突发流量时 HPA 可能来不及及时扩容。
- 抖动： 若未正确配置
stabilizationWindowSeconds，HPA 可能快速上下波动，导致不稳定。 - 受节点容量限制： HPA 只伸缩 Pod，不伸缩节点。如果集群已满，HPA 会产生 Pending Pod 并停在此处。
适用场景
无状态微服务、Web 服务器以及负载可水平分摊的应用。
2. Vertical Pod Autoscaler (VPA)
工作原理
VPA 自动调整 Pod 的 CPU 与内存 requests/limits，使其匹配实际使用情况。它由三个组件组成：
- Recommender（推荐器）： 监控历史资源使用。
- Updater（更新器）： 驱逐需要新资源限制的 Pod。
- Admission Controller（准入控制器）： 拦截 Pod 创建并注入正确的资源请求。
VPA 模式
| 模式 | 描述 |
|---|---|
| Off | 仅计算推荐，不应用（用于“干运行”）。 |
| Initial | 仅在 Pod 首次创建时应用资源。 |
| Recreate | 若请求与推荐差距显著，立即驱逐 Pod。 |
| Auto | 当前行为类似于 Recreate。 |
优势
- 精准调配： 适合纠正人为错误。开发者常凭经验估算资源（例如 “给它 2 GB RAM”），VPA 能基于实际情况进行修正。
- 遗留应用： 对无法轻易水平扩展的单体应用（不能横向伸缩）非常适用。
劣势
- 中断： 更改 Pod 资源需要重启，除非配合严格的 Pod Disruption Budget（PDB）和高可用设计，否则会产生停机。
- 与 HPA 冲突： 通常 不能 同时在同一指标（CPU/Memory）上使用 HPA 与 VPA。它们会相互争夺——HPA 增加 Pod 数量，而 VPA 试图提升单个 Pod 的限制。
适用场景
有状态工作负载、单体应用以及 “Goldilocks” 分析（使用 VPA 的 Off 模式生成理想资源尺寸报告）。
3. KEDA（Kubernetes Event‑Driven Autoscaling）
工作原理
KEDA 安装一个控制器和一个 operator，充当 HPA 的“Metrics Server”。你定义一个 ScaledObject，其中引用触发器（例如 Kafka topic 延迟、SQS 队列深度、Prometheus 查询）。KEDA 监控事件源：
- 0 → 1 伸缩： 若无事件，KEDA 将部署缩至 0（节省费用）。有事件到来时，伸缩至 1。
- 1 → N 伸缩： Pod 运行后，KEDA 将事件指标提供给原生 HPA，以实现从 1 到 N 的伸缩。
优势
- Scale‑to‑Zero： 对开发环境或零星批处理任务可大幅降低成本。
- 主动伸缩： 基于队列长度在 CPU 爆表前进行伸缩。
- 生态丰富： 支持 50+ 扩展器（Azure Service Bus、Redis、Postgres、AWS SQS 等）。
劣势
- 复杂度： 增加了额外的 CRD 与控制器需要管理。
- 延迟： 从 0 到 1 的伸缩会产生冷启动惩罚，因为需要调度并启动 Pod。
适用场景
事件驱动架构、基于队列的工作者以及 Kubernetes 上的无服务器式工作负载。
第 2 层：Node 级别伸缩
4. Cluster Autoscaler (CA)
工作原理
Cluster Autoscaler 是一个控制循环，直接与云提供商的自动伸缩组交互（AWS 的 ASG、Azure 的 VMSS 等）。它检查两种情况：
- 向上伸缩： 是否有 Pod 因资源不足而处于 Pending 状态？若是，则请求云提供商添加节点。
- 向下伸缩： 是否有节点利用率低，可被合并？若是，则将 Pod 驱逐到其他节点并终止空闲节点。
优势
- 成熟且稳定： 多年在生产环境中经受考验。
- 云无关： 在 AWS、GCP、Azure 等平台上均可使用，只需少量配置。
劣势
- 慢速： 受限于云提供商的节点组。启动节点通常涉及云 API、创建 EC2 实例、注册到集群、拉取镜像等步骤，耗时 2–5 分钟不等。
- 刚性： 只能基于预先定义的“节点组”伸缩。如果需要 GPU 节点但仅配置了通用节点组，CA 无法自动提供 GPU 节点，除非事先配置相应的 GPU 节点组。
- 成本低效： 它不会主动寻找最具性价比的实例类型，只在已有的节点组内部增删节点。
(文章对 Karpenter 的讨论被截断，故此处省略。)