ShowDocs
搜索文章Ctrl K

外观

← 返回Kubernetes列表
知识专题

Kubernetes 扩缩容 ​

扩缩容层次 ​

层次控制对象典型组件作用
水平 Pod 扩缩副本数HPA增减同类 Pod
垂直 Pod 调整requests/limitsVPA（附加组件）调整单 Pod 资源规格
节点扩缩节点/节点池Cluster Autoscaler、Karpenter 或云方案为不可调度 Pod增加容量
事件驱动扩缩副本数/JobKEDA 等附加组件根据队列、事件源扩缩

只有 HPA 是 Kubernetes 核心 API/控制器；VPA、节点扩容器和 KEDA 的版本、能力与安装方式由具体项目/平台决定。

HPA 前提 ​

  • Metrics Server 提供 CPU/内存资源指标；自定义/外部指标需要指标适配器。
  • 容器设置合理的 CPU/内存 requests，否则利用率目标可能无法计算。
  • 工作负载能水平扩展，启动时间和依赖容量已知。
  • 扩容后的 Pod 能被调度，配额、IP、镜像和下游连接池充足。
bash
kubectl top pods -n demo
kubectl get apiservice v1beta1.metrics.k8s.io
kubectl get --raw '/apis/metrics.k8s.io/v1beta1/namespaces/demo/pods'

HPA v2 示例 ​

yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
  namespace: demo
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  maxReplicas: 30
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 60
        - type: Pods
          value: 4
          periodSeconds: 60
      selectPolicy: Max
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 25
          periodSeconds: 60
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65

基本计算近似为：

text
期望副本数 = ceil(当前副本数 × 当前指标 / 目标指标)

控制器还有容差、缺失指标、未就绪 Pod 和稳定窗口等保护，最终行为以 HPA 官方文档为准。

bash
kubectl -n demo get hpa
kubectl -n demo describe hpa web
kubectl -n demo get hpa web --watch

指标选择 ​

指标优点风险
CPU 利用率通用、链路简单与业务负载不总相关，受 requests 影响
内存适合可释放/随流量变化的缓存型服务内存通常不随缩容立即下降，易只扩不缩
每 Pod QPS直接对应服务能力需可靠自定义指标和正确聚合
队列长度/消费延迟适合异步消费者需考虑到达率、处理时长和分区上限
延迟对 SLO 直接已接近过载时才触发，噪声和反馈滞后大

避免把高基数标签作为外部指标维度。指标链断开时 HPA 可能不扩容；必须监控 HPA Conditions 和指标新鲜度。

HPA 与手工副本数 ​

HPA 拥有目标的 scale 子资源。启用后：

  • 不要让 GitOps 持续把 spec.replicas 改回固定值。
  • 不要同时运行多个控制器写同一 scale target。
  • 手工 kubectl scale 只是短期，会被 HPA 下一次协调覆盖。
  • 发布系统更新 PodTemplate，不应顺便重置副本数。

VPA ​

VPA 根据历史/实时用量推荐或应用 requests：

  • Off：只生成建议，适合评估。
  • Initial：仅创建 Pod 时应用建议。
  • Recreate/Auto：可能驱逐/重建 Pod；确切模式取决于已安装 VPA 版本。
  • 支持原地调整的能力也受 Kubernetes/运行时/策略约束。

HPA 按 CPU/内存利用率扩缩时，与 VPA 同时修改 requests 会形成反馈冲突。常见做法是 HPA 使用自定义业务指标，VPA 负责资源建议；上线前按平台版本验证。

节点自动扩缩 ​

节点扩容器通常观察因资源/约束不可调度的 Pod，并增加满足条件的节点；缩容前尝试 Evict 可迁移 Pod。

无法通过加节点解决的情况：

  • PVC 绑定到不兼容故障域。
  • 硬亲和/污点没有任何节点池匹配。
  • 云配额、IP 地址或节点池最大值耗尽。
  • Pod 请求超过任何实例类型容量。
  • PDB、Local Storage 或系统 Pod阻塞缩容。

节点创建可能耗时数分钟。突发服务需保留缓冲容量、快速启动镜像或预测扩容，不能只依赖“流量来了再加节点”。

防止震荡与雪崩 ​

  • minReplicas 至少覆盖故障域和最小可用容量。
  • Scale Up 足够快，但不能瞬间压垮数据库、队列或第三方 API。
  • Scale Down 使用稳定窗口，应用优雅排空连接。
  • 启动探针与 readiness 准确，避免未暖机实例进入流量。
  • 每 Pod 并发、连接池和线程数与副本扩展模型匹配。
  • 为 HPA 上限、集群容量、配额、IP 和下游容量同时告警。
  • 压测包括冷启动、指标延迟、节点扩容和依赖退化。

扩缩容排障 ​

bash
kubectl -n demo describe hpa web
kubectl -n demo get hpa web -o yaml
kubectl -n demo get deployment web
kubectl -n demo get pods -l app=web -o wide
kubectl -n demo get events --sort-by=.lastTimestamp
kubectl get nodes
症状常见原因
<unknown> 指标Metrics API/适配器故障、无 request、标签不匹配
达到 max 仍过载上限太低、单 Pod能力下降、下游瓶颈
期望副本增加但 Pod Pending节点/配额/IP/PV/亲和性不足
频繁上下波动指标噪声、窗口太短、启动慢、目标不合适
不缩容稳定窗口、指标仍高、缺失指标保护、最小副本
节点不缩PDB、本地存储、不可驱逐 Pod、利用率阈值

扩缩容是闭环控制系统。每次调参都记录负载模型、指标、目标、时间常数和验证结果，不凭单张监控截图修改。

继续阅读