掌握云容量自动扩缩与成本运营：实战指南

场景

某企业将工作负载迁移至云端。为了确保平稳迁移，工程团队最初过度配置资源，导致云账单急剧上升，但资源利用率却很低。同时，在流量高峰期间，部分服务出现性能下降和限流，影响了 SLO。团队需要一套既能保障性能又能控制成本的自动扩缩与容量管理方案。

症状

• 月度云账单异常高，但 CPU、内存利用率长期低于 20%。
• 业务高峰时，Pod 出现 CPU 节流、请求超时，甚至 OOMKill。
• 部署的副本数量固定，不随流量变化。
• 集群节点数量长期不变，即使负载很低。
• 成本报表显示计算资源支出占比过高，且无法解释。

诊断

首先，我们使用 Kubernetes 原生工具和云平台监控来收集数据。

# 查看节点和 Pod 的资源使用情况
kubectl top nodes
kubectl top pods -A

# 检查现有 HPA 配置和状态
kubectl get hpa -A
kubectl describe hpa -n <namespace>

# 查看集群自动扩缩器状态（以 EKS 为例）
kubectl get clusterautoscaler -n kube-system

# 对于 GKE，使用 gcloud 检查集群自动扩缩配置
gcloud container clusters describe <cluster-name> --region <region>

分析这些数据： - 若 HPA 未配置或配置不正确，副本数不会随负载变化。 - 若 Pod 资源请求（requests）和限制（limits）未设置或设置过低，调度和扩缩将失效。 - 若集群自动扩缩器未启用，节点数不会根据 Pod 调度需求变化。

使用云平台的成本管理工具（如 AWS Cost Explorer、GCP Cost Management）按服务、命名空间或标签分析成本，找出资源浪费的主要来源。

命令

1. 调整 HPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70

应用配置：

kubectl apply -f hpa.yaml

2. 启用集群自动扩缩器

• EKS: 在创建集群时启用 --managed-nodegroup，并设置 --min-size 和 --max-size。
• GKE: gcloud container clusters update <cluster> --enable-autoscaling --min-nodes 1 --max-nodes 10
• AKS: az aks update --resource-group <rg> --name <cluster> --enable-cluster-autoscaler --min-count 1 --max-count 10

3. 设置资源请求与限制

编辑 Deployment，为每个容器配置准确的 requests 和 limits。建议使用 VPA 推荐值作为起点。

风险控制

• 始终为关键工作负载设置 PodDisruptionBudget（PDB），确保滚动更新或缩容时服务不中断。
• 设置 HPA 的缩放边界，避免过度伸缩（例如 maxReplicas 不要设置太高）。
• 首先在非生产环境测试所有自动扩缩配置，确认行为符合预期。
• 为集群自动扩缩器设置节点组的最小/最大限制，防止意外扩展到超高成本。
• 使用垂直 Pod 自动扩缩（VPA）时，先用“recommendation”模式，再逐步开启“auto”模式。
• 监控扩缩频率，防止“抖动”（频繁缩放），可设置 HPA 的 --horizontal-pod-autoscaler-sync-period 或调整指标阈值。

回滚

如果自动扩缩导致问题，可以快速回滚：

# 删除 HPA，恢复手动副本数
kubectl delete hpa my-app-hpa
kubectl scale deployment my-app --replicas=5

# 禁用集群自动扩缩器
# EKS: 通过 AWS 控制台或 CLI 移除自动扩缩配置
# GKE: gcloud container clusters update <cluster> --no-enable-autoscaling
# AKS: az aks update --resource-group <rg> --name <cluster> --disable-cluster-autoscaler

回滚前，确保手动设置的副本数能够承载当前负载，避免服务中断。

验证

• 观察 HPA 状态：kubectl describe hpa 显示 Current Replicas 和 Desired Replicas，并检查扩缩事件。
• 使用 Grafana 或云监控查看 CPU、内存、P99 延迟和成本变化。
• 比较回滚前后的 SLO 达成率和云账单。
• 检查集群节点数量是否随 Pod 需求变化，并通过 kubectl get nodes 确认。

例如，在高峰期，副本数应从 2 自动扩展至 10，同时节点数从 3 增加至 6；在低谷时，应自动收缩，降低成本。

何时提交 OpsGlobal 工单

如果出现以下情况，建议立即联系我们：

• 自动扩缩频繁抖动，导致应用不稳定，常规调优无效。
• 云平台配额限制（如 vCPU 限额）导致集群无法扩展，需要调整配额或重新设计架构。
• 成本异常飙升，且无法通过现有工具定位原因。
• 需要设计复杂的扩缩策略，例如基于自定义指标（Kafka 堆积数、请求队列长度）的 HPA，或混合使用 Spot 实例与按需实例。
• 集群扩缩产生内部错误，需要深入调查。

OpsGlobal 的 SRE 专家团队可以协助您设计并实施稳健的容量管理与成本优化方案，让您在云上跑得更快、更省。