Kubernetes 自动扩缩容实践：从 HPA 到 VPA

前言

哥们，别整那些花里胡哨的理论。今天直接上硬菜——我在大厂一线配置 Kubernetes 自动扩缩容的真实经验总结。作为一个白天写前端、晚上打鼓的硬核工程师，我对系统弹性的追求就像对鼓点节奏的把控一样严格。

背景

最近我们团队在 Kubernetes 集群中部署了一个高流量应用，需要根据负载自动调整 Pod 数量和资源配置。过程中踩了不少坑，也总结了一些最佳实践。今天就把这些干货分享给大家。

自动扩缩容核心概念

1. 水平 Pod 自动扩缩容（HPA）

问题：如何根据负载自动调整 Pod 数量？

解决方案：使用 HPA（Horizontal Pod Autoscaler）根据 CPU、内存或自定义指标自动调整 Pod 数量。

2. 垂直 Pod 自动扩缩容（VPA）

问题：如何自动调整 Pod 的资源配置？

解决方案：使用 VPA（Vertical Pod Autoscaler）根据实际使用情况自动调整 Pod 的 CPU 和内存请求与限制。

3. 集群自动扩缩容（CA）

问题：如何根据集群负载自动调整节点数量？

解决方案：使用 CA（Cluster Autoscaler）根据集群负载自动调整节点数量。

实践配置

1. HPA 配置

问题：如何配置 HPA 实现基于 CPU 和内存的自动扩缩容？

解决方案：直接上代码

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

2. 基于自定义指标的 HPA

问题：如何配置基于自定义指标的 HPA？

解决方案：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: backend-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: backend
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: requests-per-second
      target:
        type: AverageValue
        averageValue: 100

3. VPA 配置

问题：如何配置 VPA 实现自动资源调整？

解决方案：

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: backend-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: backend
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: "*"
      minAllowed:
        cpu: "100m"
        memory: "256Mi"
      maxAllowed:
        cpu: "1"
        memory: "1Gi"

4. CA 配置

问题：如何配置 CA 实现集群节点的自动扩缩容？

解决方案：

apiVersion: cluster.autoscaling.k8s.io/v1
kind: ClusterAutoscaler
metadata:
  name: cluster-autoscaler
spec:
  scaleDownDelayAfterAdd: 10m
  scaleDownDelayAfterDelete: 10m
  scaleDownDelayAfterFailure: 3m
  scaleDownUnneededTime: 10m
  maxNodeProvisionTime: 15m
  maxTotalUnreadyPercentage: 40
  newPodScaleUpDelay: 0s
  scaleUpUtilizationThreshold: 0.7
  skipNodesWithLocalStorage: false
  skipNodesWithSystemPods: true
  balanceSimilarNodeGroups: true
  expander: "random"
  nodeGroups:
  - name: "nodegroup-1"
    minSize: 1
    maxSize: 10
    scaleDownUtilizationThreshold: 0.5

最佳实践

1. HPA 最佳实践：

   • 合理设置最小和最大副本数
   • 选择合适的指标和目标值
   • 考虑指标采集和反应时间
   • 避免频繁扩缩容

2. VPA 最佳实践：

   • 先使用 "Off" 模式观察资源使用情况
   • 然后使用 "Initial" 模式为新 Pod 设置资源
   • 最后使用 "Auto" 模式自动调整资源
   • 注意 VPA 与 HPA 的配合使用

3. CA 最佳实践：

   • 合理设置节点池的最小和最大大小
   • 配置适当的扩缩容阈值
   • 考虑节点启动时间
   • 监控集群自动扩缩容的行为

4. 监控与告警：

   • 监控 Pod 数量和资源使用情况
   • 监控 HPA、VPA 和 CA 的状态
   • 配置扩缩容相关的告警
   • 定期分析扩缩容事件

常见问题与解决方案

1. HPA 不触发扩缩容

问题：HPA 配置正确，但不触发扩缩容。

解决方案：

• 检查指标是否正确采集
• 验证目标值是否合理
• 查看 HPA 事件和状态
• 检查 Pod 是否就绪

2. 频繁扩缩容

问题：HPA 频繁触发扩缩容，导致系统不稳定。

解决方案：

• 调整目标值，避免过于敏感
• 增加最小副本数
• 配置 stabilization window
• 考虑使用更稳定的指标

3. VPA 与 HPA 冲突

问题：VPA 与 HPA 同时使用时出现冲突。

解决方案：

• 合理规划资源配置
• 使用 VPA 的 "Initial" 模式
• 确保 HPA 基于合适的指标
• 监控资源使用情况

4. CA 不扩缩容节点

问题：集群负载高，但 CA 不扩容节点。

解决方案：

• 检查节点池配置
• 验证 Pod 调度约束
• 查看 CA 日志
• 检查集群资源配额

深夜感悟

在地下室敲代码的时候，我家猫 Root 跳上键盘，不小心按到了 kubectl get hpa，结果让我发现了一个 HPA 配置异常。这让我意识到：

1. 自动扩缩容是系统弹性的关键：它可以帮助我们应对流量波动，提高资源利用率
2. 合理配置是成功的基础：只有正确配置扩缩容参数，才能实现预期的效果
3. 监控是保障：及时发现和解决扩缩容问题，才能保证系统的稳定运行

总结

Kubernetes 自动扩缩容是实现系统弹性的重要工具，它可以帮助我们根据负载自动调整资源，提高系统的可靠性和资源利用率。就像打鼓一样，只有掌握了基本技巧，才能演奏出美妙的音乐。同样，只有掌握了自动扩缩容的核心概念和最佳实践，才能构建出弹性、高效的 Kubernetes 集群。

别整那些花里胡哨的配置，先把基础打牢。毕竟，弹性运行的系统才是最酷的。