第十章：扩缩容 —— 增加 Pod 和增加 Node 不是一回事

扩缩容至少分两层。

第一层：工作负载扩缩容
比如一个 Deployment 从 3 副本变成 10 副本。

第二层：Node 扩缩容
如果现有 Node 装不下新增的 Pod，那就得再加母舰。

先看最常见的 HPA：HorizontalPodAutoscaler。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: city-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: city-api
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

创建后：

kubectl apply -f hpa.yaml
kubectl get hpa

它的意思是：

盯着 city-api 的指标，如果平均 CPU 长期高于目标，就加 Pod；低了再缩回去。

但这里有两个超级常见的误解。

误解一：装了 HPA 就万事大吉。

不对。
HPA 需要指标来源，最常见是 metrics.k8s.io，通常靠 Metrics Server 提供。没有指标，HPA 就没法算。

误解二：HPA 扩 Pod 了，集群一定接得住。

也不对。
如果 Node 不够，Pod 会 Pending。
这时还需要 Node Autoscaler 去补 Node。官方文档当前主线里提到的节点自动扩缩能力，常见实现包括 Cluster Autoscaler 和 Karpenter 生态路线。

所以扩缩容完整链路通常是：

流量上涨
  │
  ▼
HPA 发现 CPU / Memory / Custom Metrics 偏高
  │
  ▼
Deployment.replicas 增加
  │
  ▼
新 Pod 创建
  │
  ├── 有空余 Node：直接调度成功
  └── 没空余 Node：触发 Node Autoscaler 补新 Node

再提醒一个官方文档明确写出来的坑：

如果 HPA 在管理某个 Deployment，就不要再把 .spec.replicas 当成你手工拍脑袋改来改去的字段。
kubectl scale、manifest 里的 replicas、HPA，三者混着管，最后一定乱。