弹性伸缩基础：什么是弹性伸缩、弹性伸缩的度量指标与伸缩粒度

大家好，我是你们的讲师。今天我们来聊聊弹性伸缩的基础。说实话，这个概念听起来挺高大上的，但说白了，就是让系统能像橡皮筋一样，拉得开、缩得回。

我刚开始接触云原生时，对弹性伸缩的理解很肤浅。以为就是多开几个Pod完事。后来线上出了几次事故，才真正明白——弹性伸缩不是简单的加减法，而是一门平衡的艺术。

什么是弹性伸缩？

弹性伸缩，英文叫 Auto Scaling。它的核心思想很简单：根据业务负载，自动调整计算资源的数量。

你想想看，一个电商网站，白天流量大，晚上流量小。如果一直开着100台机器，晚上就是浪费。如果只开10台，白天又扛不住。弹性伸缩就是来解决这个矛盾的。

我个人习惯把弹性伸缩分成两个维度：

• 水平伸缩：增加或减少实例数量。比如Pod从3个变成10个。
• 垂直伸缩：调整单个实例的规格。比如把CPU从1核升到4核。

在云原生场景下，我们主要关注水平伸缩。因为Pod的启停成本很低，而且可以做到秒级响应。

弹性伸缩的度量指标

有了伸缩的能力，接下来要解决的是：什么时候该伸缩？这就涉及到度量指标了。

我见过不少团队，一上来就拍脑袋定指标。结果要么频繁抖动，要么反应迟钝。这里我分享三个最常用的指标，也是我在项目中踩过坑的。

1. QPS（每秒查询数）

QPS 是最直观的业务指标。它直接反映了系统正在承受的压力。

举个例子，你的服务单机能扛1000 QPS。当QPS涨到3000时，你就需要3个Pod。当QPS降到500时，缩到1个就够了。

但这里有个坑：QPS的采集和计算有延迟。我曾经遇到过，QPS已经飙升到5000了，监控系统还在显示2000。等触发扩容时，服务已经挂了。

2. CPU 使用率

CPU 是最容易获取的指标。每个Pod都能轻松暴露CPU使用率。Kubernetes 的 HPA（Horizontal Pod Autoscaler）默认就支持CPU指标。

CPU 指标的优点是实时性好，采集成本低。但缺点也很明显——它不能完全代表业务压力。

我记得有一次，一个Java应用因为Full GC导致CPU飙升到90%。HPA触发了扩容，结果新Pod启动后也被GC拖垮了。扩容反而加剧了问题。

3. 内存使用率

内存指标和CPU类似，也是系统级指标。但它有一个特殊之处：内存是“有记忆”的。

什么意思呢？CPU用完就释放，但内存不会。一个Pod即使没有请求，它占用的内存也不会自动归还。这就导致内存使用率往往只升不降。

我建议，内存指标更适合用来做缩容保护，而不是扩容触发。比如，当内存使用率超过80%时，禁止缩容。但扩容还是用QPS或CPU更靠谱。

指标	优点	缺点	适用场景
QPS	直接反映业务压力	采集有延迟，需要预测	Web服务、API网关
CPU	实时性好，采集简单	不能代表所有负载	计算密集型服务
内存	反映资源占用	只升不降，不适合扩容	缩容保护、内存敏感型应用

伸缩的粒度：Pod级 vs Node级

聊完指标，我们来看看伸缩的粒度。说白了，就是你伸缩的最小单位是什么。

Pod级伸缩

Pod级伸缩，也叫工作负载伸缩。它调整的是应用实例的数量。

在Kubernetes中，我们通常用 HPA 来实现。HPA 会监控Pod的CPU、内存或自定义指标，然后自动调整 Deployment 或 StatefulSet 的副本数。

举个例子，一个典型的 HPA 配置：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: qps_per_pod
      target:
        type: AverageValue
        averageValue: 1000

这个配置的意思是：当Pod的平均CPU超过70%，或者单个Pod的QPS超过1000时，就自动扩容。最多10个Pod，最少2个。

Node级伸缩

Node级伸缩，也叫集群伸缩。它调整的是工作节点的数量。

你想想看，如果所有Pod都扩容到上限了，但集群的节点资源不够了，怎么办？这时候就需要Node级伸缩了。

在云原生环境中，我们通常用 Cluster Autoscaler 来实现。它会检查集群中是否有Pending状态的Pod（因为资源不足而无法调度），如果有，就自动向云厂商申请新的节点。

Node级伸缩的粒度更大，成本也更高。启动一个Node可能需要几分钟，而启动一个Pod只需要几秒。所以，Node级伸缩通常作为Pod级伸缩的后备。

维度	Pod级伸缩	Node级伸缩
伸缩对象	应用实例（Pod）	工作节点（Node）
响应速度	秒级	分钟级
成本影响	较小	较大
触发条件	Pod负载过高	集群资源不足
常用工具	HPA	Cluster Autoscaler

总结

好了，今天的内容就到这里。我们来回顾一下：

• 弹性伸缩就是根据负载自动调整资源，核心是平衡性能和成本。
• 度量指标有QPS、CPU、内存，各有优劣。我建议组合使用，不要依赖单一指标。
• 伸缩粒度分Pod级和Node级。Pod级响应快，Node级解决资源瓶颈。两者配合使用效果最好。

下一章，我们会深入HPA的实战配置。到时候我会分享一些我在生产环境中调优HPA的经验。咱们下节课见。