跳至主要內容

水平扩缩

Kinger2026/7/23大约 2 分钟云原生

在 Kubernetes (K8s) 的世界里，水平扩缩 (Horizontal Scaling) 俗称“变出更多的分身”。

它是相对于“垂直扩缩”（把一台服务器变强）而言的。简单来说：

  • 垂直扩缩 (Vertical Scaling)：给现有的一个 Pod 增加 CPU 和内存（换个更大的发动机）。
  • 水平扩缩 (Horizontal Scaling)：增加 Pod 的数量（多派几辆车来运货）。

1. 核心机制：HPA (Horizontal Pod Autoscaler)

HPA 是 K8s 实现水平扩缩的“大脑”。它是一个控制循环，通过以下步骤运行：

  1. 指标采集：它每隔一段时间（默认 15s）去问 Metrics Server：“现在的 Pod 压力大吗？”
  2. 公式计算：它会对比“当前指标”和“目标指标”。
  • 公式：

期望副本数 = \lceil 当前副本数 \times \frac{当前指标值}{期望目标值} \rceil

  1. 执行操作：如果计算结果需要 5 个 Pod，而现在只有 2 个，它会修改 Deployment 的 replicas 字段，K8s 就会自动创建 3 个新 Pod。

2. 为什么 AIOps 离不开水平扩缩？

在你的 OpenClaw 项目中，水平扩缩解决了三个痛点：

  • 应对突发流量：当你的 Web 集群突然涌入大量用户，CPU 飙升到 90%，HPA 会迅速横向扩容，防止单点崩溃。
  • 提高可用性：如果有 10 个 Pod 在跑，死掉 1 个对业务几乎没影响；如果只有 1 个超强 Pod，一旦挂了就是全线宕机。
  • 成本优化：深夜没人的时候，HPA 会自动缩减到 1 个 Pod，节省资源（省钱）。

3. HPA 的“冷却”与“抖动”

水平扩缩最怕**“扩了缩，缩了扩”**（这叫 Thrashing/抖动）。

  • 扩容：通常反应很快，为了救命。
  • 缩容：通常有“观察期”（默认 5 分钟）。即使 CPU 掉下去了，HPA 也会等一会儿，确认流量真的退去了才杀掉 Pod。

4. 梓涵的面试高分点：自定义指标扩容

面试官通常会问：“如果 CPU 没满，但业务响应变慢了（延迟高），HPA 怎么处理？”

你的回答建议：

“原生 HPA 只能监控 CPU/内存。但在 OpenClaw 中，我引入了 Prometheus Adapter。

我配置了基于 ‘自定义指标（Custom Metrics）’ 的扩缩容。例如，我监控 vLLM 推理队列的长度。当待处理的推理请求超过 10 个时，即使 CPU 还没满，HPA 也会提前触发扩容，确保 AI 响应的实时性。这种**‘预测性扩容’**比原生的指标触发更贴合 AIOps 场景。”

​ 动手实验：你想看代码吗？

我们可以写一个简单的 HPA YAML 定义。假设我们要保护你的 Web 业务：

  • 目标：保持每个 Pod 的平均 CPU 使用率在 50%。
  • 范围：最少 2 个 Pod，最多 10 个 Pod。

需要我把这个 YAML 配置文件写出来，并教你怎么在你的 K8s 集群里一键生效吗？