资源不够：手动加 Pod 加不过来

业务高峰一来，CPU 飙满、请求排队，你手动改 Deployment 的副本数、kubectl apply，再盯着看有没有压下去——峰值一过又得手动缩回来，不然白白浪费钱。这种手动伸缩在流量平稳时还行，但流量是波峰波谷的，半夜流量突然暴涨你不可能爬起来敲命令。这就是为什么 K8s 里有一套自动伸缩机制。

K8s 的弹性伸缩分两层：Pod 层自动加副本（HPA），节点层自动加机器（Cluster Autoscaler）。这一篇把这两层都讲清楚。

手动伸缩适合小流量稳定业务；波峰波谷大的业务，必须上自动伸缩。
本文核心知识点
  • HPA按 CPU/内存/自定义指标自动增减 Pod 副本。
  • 资源配额限制每个服务能用多少 CPU 内存，防争抢。
  • 节点伸缩Pod 排不下时自动加一台机器。
  • 冷启动新 Pod 刚起来还不能立刻接流量。
Kubernetes 弹性伸缩配图：左侧两摞小服务器方块、右侧一摞高服务器方块、中间双向弹性箭头的蓝色扁平科技插画
流量小用两台，流量大扩成一大摞——这就是自动伸缩。

HPA：按指标自动伸缩 Pod

HPA（水平 Pod 自动伸缩）盯着一个指标——比如 CPU 使用率——超过阈值就加副本，低于阈值就减。配起来大概长这样：

# HPA 关键思路
- 目标：CPU 平均使用率保持在 60% 左右
- 最低副本数：2（保底）
- 最高副本数：10（上限，别无限加）
- 指标：容器 CPU 利用率

这里有个前提：每个 Pod 必须声明了 requests（申请的资源），不然 HPA 没法算利用率。所以想上 HPA，先把每个 Deployment 的 resources.requests 配齐。

资源配额：别让一个服务吃光整节点

集群里很多服务跑在同一批节点上，如果没有限制，一个失控的服务可能把整台机器的 CPU 吃光，邻居全被拖死。资源配额（ResourceQuota）就是给每个命名空间画个预算：

配额的两个作用：
- limits：单个 Pod 最多用多少（防止吃满）
- requests：调度时按这个值占座（保证它有资源跑）
- 命名空间级：整个项目最多用多少 CPU/内存

很多人只配 requests 不配 limits，结果一个 Pod 内存泄漏把节点拖垮。requests 决定它能不能跑起来，limits 决定它最多能闹多大——两个都要配。

节点自动伸缩：Pod 排不下时补机器

HPA 把 Pod 副本从 2 加到 10，但如果集群里没空闲节点了，新 Pod 会一直卡着起不来。这时候就要靠节点自动伸缩（Cluster Autoscaler）——它发现有 Pod 排不下，就去云厂商开一台新机器加进集群；反过来节点长期闲着，它会再退掉：

两层伸缩配合：
1. HPA 先扩 Pod 副本
2. 节点不够 → Cluster Autoscaler 加机器
3. 流量回落 → HPA 缩 Pod
4. 节点长期空 → 退机器

注意节点伸缩比 Pod 伸缩慢很多——开一台新机器要几分钟。所以HPA 的扩容要比流量预测略激进，给节点伸缩留出补位时间。