Kubernetes 自动扩缩容器的“内战”与解决之道

在 Kubernetes 生态中，自动扩缩容是保障应用高可用的关键。然而，很多开发者发现，当开启多种自动扩缩容策略时，系统不仅没有变快，反而变得不稳定。这并非配置错误，而是组件间的“内战”。

核心冲突：HPA 与 VPA 的博弈

Kubernetes 提供了多种自动扩缩容工具，但它们往往基于不同的目标。理解它们如何互相干扰，是解决问题的关键。

• HPA (水平 Pod 自动扩缩容器)：关注的是数量。它根据 CPU、内存等指标，动态调整 Pod 的副本数。
• VPA (垂直 Pod 自动扩缩容器)：关注的是大小。它根据 Pod 的实际资源消耗，调整容器的 CPU 和内存请求及限制。

当两者同时开启时，会产生级联效应：VPA 发现某个 Pod 资源不够，将其调大；HPA 看到资源利用率上升，又决定增加更多副本。结果就是，Pod 变得越来越大，数量越来越多，导致资源消耗呈指数级增长。

Cluster Autoscaler 的“助攻”与“捣乱”

Cluster Autoscaler (CA) 负责根据集群中无法调度的 Pod 自动添加或删除节点。

在 HPA 和 VPA 冲突的场景下，CA 往往处于两难境地：

1. VPA 导致 Pod 变大：CA 会尝试添加新节点来容纳这些变大的 Pod。
2. 资源竞争：如果新节点上的资源被其他 VPA 调整过的 Pod 占满，或者负载未达到预期，CA 可能会误判并删除节点，导致集群不断扩缩容，形成死循环。

实战建议：如何实现真正的自主扩缩容？

为了避免组件间的“打架”，我们需要在架构设计上做出取舍。以下是面向开发者和运维者的实用建议：

1. 策略解耦：不要混用

在生产环境中，最稳妥的方案是解耦 HPA 和 VPA。

• 推荐方案 A：保留 HPA，关闭 VPA。通过调整 Pod 的资源限制，配合 HPA 来实现水平伸缩。这种方式简单且可控。
• 推荐方案 B：保留 VPA，关闭 HPA。适用于需要精细化控制资源配额的场景，但需要人工干预或配合 Job 进行调度。

2. 合理配置 VPA 的更新模式

如果必须使用 VPA，请务必选择合适的更新模式。Recreate 模式是推荐的选择。

• Recreate 模式：VPA 会先删除现有的 Pod，等待新 Pod 调度成功并运行后，再处理下一个 Pod。这避免了多个 Pod 同时调整资源导致的调度风暴。
• Auto 模式（默认）：在滚动更新期间，多个 Pod 可能会同时调整资源，极易引发调度失败或资源争抢。

3. 引入集中式控制器

对于超大规模集群，可以考虑引入集中式的控制器（如 Prometheus Adapter 或自定义的 Autoscaler）。这种控制器能统一监控指标，做出全局最优的扩缩容决策，而不是让各个组件各自为战。这种“自主性”不是指盲目反应，而是指基于全局状态的智能决策。

通过理清组件间的协作关系，我们才能真正利用 Kubernetes 的弹性能力，而不是被它复杂的机制所拖累。