Kubernetes 弹性伸缩体系：HPA、VPA、KEDA 与 Cluster Autoscaler 全解

┌─────────────────────────────────────────────────────────┐
│  Cluster Autoscaler（节点级）                             │
│  不够节点 → 加节点；节点闲置 → 缩减节点                   │
│  与云厂商联动：AWS ASG / GCP MIG / 云节点池               │
└─────────────────────────┬───────────────────────────────┘
                          │ 节点就绪
┌─────────────────────────▼───────────────────────────────┐
│  HPA（Pod 副本级）                                       │
│  CPU/内存/自定义/外部指标 → 调 replicas                   │
└─────────────────────────┬───────────────────────────────┘
                          │ 请求量
┌─────────────────────────▼───────────────────────────────┐
│  VPA（单 Pod 额度级）                                    │
│  观测历史用量 → 建议并调整 requests/limits                 │
└─────────────────────────┬───────────────────────────────┘
                          │ 请求量
┌─────────────────────────▼───────────────────────────────┐
│  KEDA（事件驱动，横向下层之上）                            │
│  Kafka/Redis/队列深度/定时 → 触发扩容/缩到零              │
└─────────────────────────────────────────────────────────┘

一句话：CA 管"机器够不够"，HPA 管"进程够不够"，
      VPA 管"每份申请多少"，KEDA 用业务事件驱动这一切。

# 部署 metrics-server（收集每个 Pod/Node 的 CPU/内存用量）
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
# 检查是否正常
kubectl top nodes
kubectl top pods -n dev

metrics-server 特点：
  · 只提供 CPU/内存的"瞬时用量"
  · 数据来自 kubelet 的 cAdvisor，非持久化
  · HPA 仅靠它就能做 CPU/内存扩缩
  · 若需要更多指标（QPS/延迟/队列）→ 接 Prometheus 等自定义指标源

注意：metrics-server 是"每秒采样"的近似值，
      不适合做精确的告警/容量——那是 Prometheus 的职责。

路径一：metrics-server（resource metrics）→ 内置
  供 HPA 的 resource 指标（cpu/memory）

路径二：自定义指标 API（metrics.k8s.io）
  应用自定义指标（QPS、错误率）→ 由 Prometheus Adapter 聚合

路径三：外部指标 API（external.metrics.k8s.io）
  外部服务的指标（SQS 队列长度、Kafka lag、Redis 长度）
  → 常配合 KEDA 使用

HPA 每周期（默认 15s）计算：
  期望副本数 = ceil(当前指标值 / 目标值 × 当前副本数)

例：
  当前 CPU 平均利用率 80%，target 50%，副本数 4
  → 期望 = ceil(80/50 × 4) = ceil(6.4) = 7

平滑机制：
  - 防止震荡：只允许"每步扩 max(N, 2×current)"（快速扩容）
  - 缩容有--horizontal-pod-autoscaler-downscale-stabilization（默认 5 分钟）
    避免指标抖动导致反复缩容

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: orders-hpa
  namespace: shop
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: orders
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization     # 平均值（%）
          averageUtilization: 60
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 75
  behavior:                      # 细粒度扩缩控制
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 50             # 每次最多缩一半
          periodSeconds: 60

关键理解：HPA 不保证"每个 Pod 都在 60% 以下"，
  它只保证"副本数 × Utilization 调整到接近目标"。
  - CPU 利用率是平均值：某个 Pod 高、其他低也 OK
  - 扩太慢 → 短时间峰值响应不过来 → 需要更宽预警（KEDA）
  - 缩太慢 → 高峰过后也占用资源 → 调 downscale 策略

# HPA 用应用自定义指标（如每秒请求数）扩容
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    kind: Deployment
    name: api-gateway
  minReplicas: 2
  maxReplicas: 50
  metrics:
    - type: Object                  # 对象指标（按服务对象计算）
      object:
        metric: { name: "http_requests_per_second" }
        describedObject:
          kind: Service
          name: api-gateway
        target:
          type: Value
          value: 500               # 每个副本约 500 QPS

自定义指标常用的承载方案：
  - Prometheus Adapter（prometheus-adapter）：把 Prometheus 指标转成
    custom.metrics.k8s.io，供 HPA 消费
  - 采集：应用暴露 /metrics + ServiceMonitor / Prometheus 拉取

典型问题：指标缺失 / 命名不匹配 → HPA 无法匹配
  排查：kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1

VPA 三件套：
  1. Recommender   定期读取历史用量（metrics-server + 外部），
                  输出"建议的 requests/limits"
  2. Updater       决定是否要杀 Pod 以让新配置生效
    （先升级 Pod 来 replace requests）
  3. Admission Controller（OOM 时预警、Pod 创建时注入推荐值）

两种模式：
  - vpa-updater：改完要重启 Pod 生效（有牺牲）
  - admission：新 Pod 创建时就带上推荐值（推荐日常）

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: orders-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: "Deployment"
    name: orders
  updatePolicy:
    updateMode: "Auto"      # Auto / Initial / Off
  resourcePolicy:
    containerPolicies:
      - containerName: "*"
        minAllowed:
          cpu: 50m
        maxAllowed:
          cpu: "2"
          memory: 4Gi

# 查看 VPA 推荐（Auto 模式下生效前的中间态）
kubectl get vpa orders-vpa -o yaml | grep -A8 recommendation
# recommendation:
#   containerRecommendations:
#   - containerName: main
#     target:
#       cpu: 250m
#       memory: 1Gi

HPA 是"响应式"：指标超过才扩 → 高峰到来前的几秒有 latency
KEDA 是"事件驱动"：队列一深、定时一到 → 提前扩容
  典型场景：
    - 消息消费者随队列深度扩容
    - 定时任务（Cron）按秒表缩放拉到 0（省资源）
    - 吞吐波动的工作负载（批处理、爬虫）
    - 拉起/缩到 0 的 Serverless 式工作负载

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: consumer-scaler
  namespace: shop
spec:
  scaleTargetRef:
    name: consumer-deploy        # 被缩放对象
  minReplicaCount: 1
  maxReplicaCount: 30
  triggers:
    - type: kafka                 # 事件源
      metadata:
        topic: orders
        bootstrapServers: kafka:9092
        consumerGroup: workers
        lagThreshold: "100"       # 积压超过 100 条就扩容
    - type: cron                  # 双触发可组合
      metadata:
        timezone: Asia/Shanghai
        start: "0 9 * * *"
        end: "0 20 * * *"
        desiredReplicas: "20"

KEDA 内部：
  - Scaler Controller 连接事件源统计积压量
  - 把积压量映射成"External 指标"塞给 HPA
  - HPA 据此扩缩；队列空了 → 缩到 min（甚至 0）
  → 本质是"HPA + 事件适配器"的组合

要点：
  - 结合 HPA 的 minReplicas/maxReplicas 设置下限/上限
  - "缩到 0"需要确保应用能冷启动（Ready 探针/启动率）
  - 过多 ScaledObject → 抢 HPA 资源管理器，量力而行
  - 事件触发器的"消费组隔离"：多个 worker 共享的组深度
    才是真的积压（避免把"已读未处理"当积压）

Cluster Autoscaler 观察"待调度的 Pod"：
  - 有 Pod Pending（没节点放得下）→ 添加节点
  - 节点长时间(默认 10 分钟)低占用 & 所有 Pod 可搬迁 → 缩节点

联动性：
  - 它只在"资源不足"时扩，"资源空闲"时缩
  - 配合 HPA：HPA 扩副本 → 节点指标上涨 → CA 加节点
  - 配合 VPA：VPA 提高 requests → 也可能触发 CA 扩节点

# Cluster Autoscaler 需要云厂商节点组（如 AWS Auto Scaling Group）
# 以 AWS 为例，deployment 启动参数：
spec:
  containers:
  - name: cluster-autoscaler
    image: k8s.gcr.io/autoscaling/cluster-autoscaler:v1.30.0
    command:
    - ./cluster-autoscaler
    - --cloud-provider=aws
    - --nodes=1:10:worker-groups-eks  # min:max:ASG名
    - --scale-down-unneeded-time=10m
    - --scale-down-utilization-threshold=0.5

CA 关键参数：
  --min/max：每组节点的最小最大数
  --scale-down-unneeded-time：缩容前"空闲多久"
  --scale-down-utilization-threshold：节点利用率低于多少可缩
  --balance-similar-node-groups：平衡同构节点组

坑一：节点不可由 CA 缩
  有 Pod 用了 local storage / 有 PDB → 打断了 → 加 `--skip-nodes-with-local-storage`
  单副本且无 PDB → CA 不敢缩 → 给关键工作负载建 PDB

坑二：扩缩回环
  负载下降 → CA 缩节点 → 集群小脚 → 又扩回 → 抖动
  用 --scale-down-unneeded-time 拉大 + utilization 阈值留缓冲

坑三：一次性泡沫
  高峰过去 → 需要时间 reduce → 用 CA 的延迟与上下限控制

场景：订单服务高峰
  1. Kafka 队列积压 → KEDA 触发扩 worker 副本（前置）
  2. worker CPU 涨 → HPA 发现 CPU>60% → 再补副本
  3. 现有节点放不下 → Pod Pending → CA 扩一个节点
  4. Prometheus 观测 → 队列消化 → KEDA 缩 → CA 缩节点
  → 四层协同，IP 高峰时段也能"按需就位"

HPA / VPA 分工表：
  - 指标类型         扩缩对象        适用
  - CPU/utilization  副本数         稳态服务
  - 内存/utilization 副本数         内存密集记录
  - 自定义/外部       副本数         QPS/队列/业务指标
  - 事件警报/KEDA     副本数+缩到0  需要前置伸缩的消息/批次
  - requests调整（VPA）r请求配置      组装建议（不与 HPA 抢同名指标）

# 观察 HPA 是否在合理工作
kube_horizontalpodautoscaler_spec_target_replicas     # 期望
kube_horizontalpodautoscaler_status_current_replicas    # 当前
kube_horizontalpodautoscaler_status_desired_replicas    # 期望由 HPA 计算
# 关键告警：current_replicas 长期 < desired（可能卡在 max/CA 不够）

- 常规稳定服务 → HPA + metrics-server（CPU/memory）
- 有流量概念 → 自定义/外部指标（QPS、队列）
- 高峰无等待 → 事件驱动 KEDA（消息/调度）
- 请求配置不合理 → VPA 轮询建议 + 人工/自动应用
- 负载跨节点 → Cluster Autoscaler + PDB + 预创建节点池

□ 装好 metrics-server，HPA 有 CPU/内存基线
□ HPA 设 min/max + stabilizationWindow
□ 关键服务用自定义指标（QPS/延迟），不只看 CPU
□ KEDA 处理消息积压与缩到 0
□ VPA 与 HPA 分工清晰（不同指标，避免打架）
□ Cluster Autoscaler 配 PDB + --max--nodes 上限
□ 监控 desired vs current replicas，防卡死
□ 每一层都有上下限，防止失控