直接回答：三层各管一个维度。HPA（水平 Pod 伸缩）：按 CPU/内存/自定义指标调整 Deployment 的副本数，应对流量波动，秒到分钟级生效。VPA（垂直伸缩）：分析历史用量推荐甚至自动调整单个 Pod 的 requests/limits，解决"规格定错"问题。Cluster Autoscaler：Pod 因资源不足 Pending 时扩节点，节点长期利用率低时缩节点，管的是集群容量本身。典型配合：CA 兜底容量，HPA 应对波动，VPA 校准规格。

展开解析：实践坑点密集。HPA 基于 metrics-server 的指标，应用没设 requests 时 CPU 百分比无从算起——requests 是弹性的地基；自定义指标（队列长度、QPS）要走 prometheus-adapter。HPA 与 VPA 同指标联动会打架（HPA 看 CPU 利用率、VPA 改 requests 会反过来影响利用率），官方建议 VPA 只开推荐模式人工采纳，或 VPA 管 CPU 时 HPA 改用自定义指标。CA 缩节点遵循 PDB，节点上有本地存储或单副本 Pod 会卡住。进阶：KEDA 按事件源（Kafka lag、Redis 长度）扩缩并支持缩到零；cron 型定时扩缩应对可预期高峰。弹性验证要纳入演练：压测观察扩容速度能否追上流量爬坡。

追问方向：HPA 的冷却时间/速率限制怎么配？requests 与 limits 的设置方法论？Karpenter 与 CA 的差异？

（约 460 字）