直接回答：HPA 原生只懂 CPU/内存（resource metrics API），自定义指标靠 metrics.k8s.io 之外的两个扩展 API：custom.metrics.k8s.io（Pod 级指标，如每 Pod QPS）与 external.metrics.k8s.io（集群外指标，如 Kafka lag、SQS 队列深度）。落地方式是部署适配器把 Prometheus 等数据源翻译成这些 API——prometheus-adapter 是经典方案，KEDA 则把“事件源→指标→扩缩”做成了声明式 CRD，支持缩到零，事件驱动场景首选 KEDA。
展开解析：以 Kafka 消费者为例：用 KEDA 的 ScaledObject 指定 topic 与 lag 阈值，每个 lag 单位折算目标副本数，lag 上涨即扩容消费者，清零后可缩到 0 省钱。配置要点：指标选择要反映“处理能力瓶颈”且与副本数近似线性相关（QPS/Pod 是），延迟类指标做扩缩依据要小心反馈振荡；扩缩速度用 behavior 字段调（扩容快、缩容慢带稳定窗口，防抖动反复横跳）；副本上限结合下游容量（数据库连接数）设置，别扩出雪崩。适配器是单点关键路径，要 HA 部署并监控其查询延迟——指标断供时 HPA 默认保持现状。与 VPA、Cluster Autoscaler 的关系：HPA 动副本数，CA 动节点数，两者指标链条要算总延迟（指标采集周期 + HPA 决策 + Pod 启动 + 节点供给，常达分钟级），突发流量场景要考虑预热缓冲。
追问方向：KEDA 的 ScaledJob 与 ScaledObject 分别适合什么？如何避免扩缩抖动？
（约 500 字）