公司上线了一个新项目，用户量一开始不多，跑在几台小规格的节点上挺稳。可没想到推广一做，流量猛增，服务开始卡顿，临时扩容又手忙脚乱。等高峰过去，资源又大量闲置，每月云账单看着心疼。这种情况，其实用好 ref="/tag/2020/" style="color:#3D6345;font-weight:bold;">Kubernetes 集群自动伸缩就能避免。
自动伸缩不只是“加机器”
Kubernetes 的自动伸缩不是简单地监控 CPU 高了就加节点。它有多个层次配合工作。最常见的是 HPA（Horizontal Pod Autoscaler），根据 Pod 的负载情况自动增减副本数。比如你的 Web 服务在下午三点突然被大量访问，HPA 检测到平均 CPU 超过 70%，就会自动拉起更多 Pod 分担负载。
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70但这还不够。如果所有节点都快跑满了，新增的 Pod 会一直处于 Pending 状态。这时候就需要 Cluster Autoscaler 上场。它监听集群中无法调度的 Pod，一旦发现，就自动向云平台申请新的节点加入集群。
实际场景中的弹性体验
我们团队负责的后台管理服务平时只有几十人使用，两个 Pod 完全够用。但每周一早上九点，全员开例会前集中登录系统，负载瞬间翻倍。启用 HPA 后，这段时间 Pod 自动扩到六个，响应速度稳定。会开完，十分钟后副本数自动降回去。没人需要守着监控手动操作。
更省心的是 CI/CD 构建服务。这类任务短时间吃资源，但每天不定时发生。我们把构建服务的节点池设置为可伸缩，空闲时节点缩到零。只要有构建任务进来，Cluster Autoscaler 几分钟内就准备好节点并启动 Pod。用完自动回收，一个月下来节省了近 40% 的计算成本。
别忽略 VPA 和配置细节
除了横向扩容，垂直伸缩（VPA）也值得了解。它能自动调整 Pod 的 CPU 和内存请求值。适合那些副本数固定但资源需求波动大的服务。不过 VPA 调整时可能触发 Pod 重启，得结合滚动更新策略小心使用。
自动伸缩不是设完就高枕无忧。阈值设太敏感，容易频繁扩缩，增加系统抖动；设得太宽松，又起不到保护作用。建议先从 CPU 和内存入手，再逐步接入自定义指标，比如消息队列长度或 QPS。
另外，节点池的类型也很关键。不同规格的节点扩容速度和单价不同。混合使用多种实例类型，配合竞价实例，能进一步压低成本，只要你的应用能容忍偶尔的中断。