Kubernetes VPA 与 HPA：数据任务扩缩容选型

数据任务选 HPA 还是 VPA，先看任务能否通过增加副本获得吞吐，再看单个 Pod 的 CPU、内存是否需要持续纠偏。能把工作拆成独立分片、增加消费者或并发执行器的任务，优先考虑 HPA；吞吐主要受单个进程内存、缓存或堆大小影响，横向增加副本无效的任务，更适合先用 VPA 做资源建议。两者都解决不了节点容量、分片倾斜、状态迁移和检查点恢复问题，所以最终方案通常是“任务扩缩容 + 节点扩容 + 数据语义”一起设计。

HPA 和 VPA 调整的对象不同

HPA 是一个控制循环，根据平均 CPU、内存或自定义指标调整目标工作负载的 Pod 副本数。对于按利用率扩容，Kubernetes 会把当前使用量与 Pod 的 resource request 比较；如果相关容器没有设置 request，该指标的利用率就无法定义，HPA 可能不会基于它采取动作。使用多个指标时，控制器分别计算目标副本数并取较大的建议值，因此“CPU 不高但队列积压”可以通过自定义或外部指标触发横向扩容。

VPA 的核心工作是分析资源使用并生成推荐值，包括目标推荐、下界和上界，再根据 updateMode 决定是否应用。Off 只生成建议；Initial 只在 Pod 创建时设置 request；Recreate 通过驱逐并重建 Pod 应用新资源；当前文档还描述了 InPlaceOrRecreate 和 InPlace 等模式，它们是否可用取决于集群能力和资源变更类型。VPA 不是把一个任务拆成更多并行执行单元，而是调整现有 Pod 的资源请求和限制。

因此，“HPA 让任务更快，VPA 让任务更省”并不准确。HPA 改变并发数量，可能改善可并行吞吐；VPA 改变单个实例的资源画像，可能降低 OOM 或长期过度预留。数据任务往往两种瓶颈同时存在，必须先确认算子和分片模型。

先判断数据任务的并行模型

第一类是无状态或弱状态的批处理 worker。任务从队列领取互不重叠的文件、分区或消息，增加 Pod 后每个 worker 都能领取新工作。这类任务的主信号可以是队列长度、待处理分片数、每秒完成量和处理延迟，HPA 通常比 CPU 利用率更贴近业务目标。

第二类是分区型流处理。消费者数量受主题分区数或任务并发上限约束，副本超过可分配分区后不会带来线性收益。HPA 需要把分区积压与再均衡时间纳入冷却和上限，否则积压一升高就扩到无效副本，既增加成本又触发频繁再均衡。

第三类是单实例内存型任务，例如需要较大堆、缓存或状态的聚合进程。若数据不能安全拆分，HPA 增加副本可能造成重复计算或状态分裂；此时更适合先用 VPA 的 Off 模式观察推荐，再选择在维护窗口以 Initial 或 Recreate 应用。若任务支持检查点、状态迁移和优雅退出，才能进一步评估自动更新资源。

第四类是有外部副作用的任务，例如写数据库、发通知或提交账务结果。副本增加前必须确认幂等键、去重和事务边界，否则扩缩容带来的重试会转化成重复写入。扩缩容策略不能替代数据处理语义。

数据任务的选型步骤

第一步，记录任务的工作单元和最大并行度。明确一个 Pod 负责一个分片、多个分片还是一条全局状态链路，列出分片上限、再均衡耗时和是否允许并发重试。

第二步，分别采集“工作量指标”和“资源指标”。工作量指标包括队列积压、待处理分区、端到端延迟和每秒完成量；资源指标包括 CPU、内存、网络、临时磁盘和 GC。只看 CPU 会漏掉等待下游、网络受限和内存压力，只看队列又可能在单 Pod 已经 OOM 时扩出更多同样脆弱的 Pod。

第三步，先设置可信的 requests 和 limits。HPA 的利用率计算依赖 request，VPA 的建议也依赖持续、可信的历史使用数据。request 过小会让利用率看起来过高，HPA 过度扩容；request 过大又会让利用率偏低，HPA 迟迟不扩容。初始值应来自一段包含高峰、低谷和失败重试的观测窗口，而不是一次部署时的猜测。

第四步，确定控制回路的边界。HPA 负责副本数，VPA 负责单 Pod 资源建议，节点自动扩容负责为无法调度的 Pod 提供节点。三者需要有明确的上下限、冷却窗口和升级顺序。节点自动扩容通常响应 Pending 或不可调度 Pod；它不会因为某个 Pod 的 CPU 曲线高就直接增加副本。

第五步，验证扩容和缩容对数据语义的影响。检查点、offset、租约、锁、临时文件、checkpoint 目录和下游写入都要纳入测试。尤其是缩容：Pod 被终止时，任务是等待当前分片完成、保存状态后退出，还是直接由新 Pod 接管？不同答案对应不同的丢失、重复或延迟风险。

一个具体判断例子

假设有一组从对象存储读取分区文件的转换 worker。积压持续增加，单 Pod CPU 达到 75%，内存较稳定，任务可按文件分片且输出使用幂等分区覆盖。此时可以用待处理文件数或每 Pod 完成量作为 HPA 指标，设置最小副本保证持续消费，设置最大副本不超过存储和下游数据库承载能力。节点自动扩容负责承接新 Pod，扩容测试要覆盖文件重复领取和输出提交失败。

再看一个有大状态的流式聚合任务：CPU 只有 40%，但内存持续接近上限，增加副本不能拆分全局状态。先用 VPA Off 观察目标、下界和上界推荐，确认高峰期内存峰值及重启影响；若任务支持状态保存，可在发布或维护窗口用 Recreate 应用新 request。若状态无法可靠恢复，自动驱逐不是可接受的优化，即使 VPA 给出了看似合理的数值。

HPA 与 VPA 不能随便同时控制同一资源

如果 HPA 依据 CPU 利用率，而 VPA 又持续调整 CPU request，HPA 的分母会变化，控制信号会互相影响：同样的实际使用量可能因为 request 被调小而触发扩容，也可能因为 request 被调大而停止扩容。更稳妥的做法是分工，例如 HPA 使用队列或吞吐等外部指标，VPA 负责内存建议；或者先用 VPA Off 校准 requests，再固定资源基线设计 HPA。

这不是绝对禁止组合，而是要求显式定义谁控制什么。每次资源推荐变化都应能解释为什么，避免 HPA 和 VPA 同时修改同一目标导致振荡。对于有状态数据任务，宁可在观测阶段保守设置，也不要把重建代价隐藏在自动化之后。

节点容量和资源配置的失败模式

第一种失败是 HPA 已经把副本数调高，但 Pod 长时间 Pending。原因可能是节点没有可用 CPU、内存、临时磁盘，或亲和性、污点和拓扑约束阻止调度。节点自动扩容只能为满足 requests 的 Pending Pod 提供容量，无法修复过大的 request 或不合理的调度约束。

第二种失败是 HPA 没有动作，因为 metrics API 不可用，或者容器没有相关 resource request。第三种失败是扩容后吞吐不增，实际瓶颈在单分区、外部数据库连接数、对象存储限流或数据倾斜。第四种失败是 VPA 自动重建打断检查点，任务看似获得更多内存，却付出更长恢复时间。第五种失败是缩容没有等待优雅退出，导致重复处理和延迟。

建议按“观测—建议—小范围自动化”的顺序上线：先验证分片和恢复语义，再用 VPA Off 建立资源基线；对可并行任务启用 HPA，并用业务工作量指标校准；最后联动节点自动扩容，观察 Pending 时长、再均衡、恢复时间、成本和数据重复率。验收标准应同时包含吞吐、时延、资源成本和数据正确性，任何单一指标变好都不能代表扩缩容选型完成。