腾讯云：如何根据不同业务场景调节HPA扩缩容灵

小提示：您能找到这篇{腾讯云：如何根据不同业务场景调节HPA扩缩容灵}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的腾讯云：如何根据不同业务场景调节HPA扩缩容灵内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

背景

< ">在K8s 1.18之前，HPA扩容是无法调整灵敏度的:

< ">1.对于缩容，由kube-controller-manager的--horizontal-pod-autoscaler-downscale-stabilization-window参数控制缩容时间窗口，默认5分钟，即负载减小后至少需要等5分钟才会缩容。

< ">2.对于扩容，由hpa controller固定的算法、硬编码的常量因子来控制扩容速度，无法自定义。

< ">这样的设计逻辑导致用户无法自定义HPA的扩缩容灵敏度，而不同的业务场景对于扩容容灵敏度要求可能是不一样的，比如：

< ">1.对于有流量突发的关键业务，在需要的时候应该快速扩容(即便可能不需要，以防万一)，但缩容要慢(防止另一个流量高峰)。

< ">2.对于一些需要处理大量数据的离线业务，在需要的时候应该尽快扩容以减少处理时间，不需要那么多资源的时候应该尽快缩容以节约成本。

< ">3.处理常规数据/网络流量的业务，它们可能会以一般的方式扩大和缩小规模，以减少抖动。

< ">HPA在K8s 1.18迎来了一次更新，在之前v2beta2版本上新增了扩缩容灵敏度的控制，不过版本号依然保持v2beta2不变。

如何使用

< ">这次更新实际就是在HPA Spec下新增了一个behavior字段，下面有scaleUp和scaleDown两个字段分别控制扩容和缩容的行为。

< ">下面给出一些使用场景的示例。

快速扩容

< ">当你的应用需要快速扩容时，可以使用类似如下的HPA配置:

apiVersion: autoscaling/v2beta2

kind: HorizontalPodAutoscaler

metadata:

  name: web

spec:

  minReplicas: 1

  maxReplicas: 1000

  metrics:

  - pods:

      metric:

        name: k8s_pod_rate_cpu_core_used电视机的广告_limit

      target:

        averageValue: "80"

        type: AverageValue

    type: Pods

  scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: web

  behavior: # 这里是重点

    scaleUp:

      policies:

      - type: percent

        value: 900%

< ">上面的配置表示扩容时立即新增当前9倍数量的副本数，即立即扩容到当前10倍的Pod数量，当然也不能超过maxReplicas的限制。

< ">假如一开始只有1个Pod，如果遭遇流量突发，它将以飞快的速度进行扩容，扩容时Pod数量变化趋势如下:

1->10->100->1000

< ">没有配置缩容策略，将等待全局默认的缩容时间窗口(--horizontal-pod-autoscaler-downscale-stabilization-window，默认5分钟)后开始缩容。

快速扩容，缓慢缩容

< ">如果流量高峰过了，并发量骤降，如果用默认的缩容策略，等几分钟后Pod数量也会随之骤降，如果Pod缩容后突然又来一个流量高峰，虽然可以快速扩容，但扩容的过程毕竟还是需要一定时间的，如果流量高峰足够高，在这段时间内还是可能造成后端处理能力跟不上，导致部分请求失败。这时候我们可以为HPA加上缩容策略，HPA behavior配置示例如下:

behavior:

  scaleUp:

    policies:

    - type: percent

      value: 900%

  scaleDown:

    policies:

    - type: pods

      value: 1

      periodSeconds: 600 # 每 10 分钟只缩掉 1 个 Pod

< ">上面示例中增加了scaleDown的配置，指定缩容时每10分钟才缩掉1个Pod，大大降低了缩容速度，缩容时的Pod数量变化趋势如下:

1000 -> … (10 min later) -> 999

< ">这个可以让关键业务在可能有流量突发的情况下保持处理能力，避免流量高峰导致部分请求失败。

缓慢扩容

< ">如果想要你的应用不太关键，希望扩容时不要太敏感，可以让它扩容平稳缓慢一点，为HPA加农夫山泉危机公关案例分析入下面的behavior:

behavior:

  scaleUp:

    policies:

    - type: pods

      value: 1 # 每次扩容只新增 1 个 Pod

< ">假如一开始只有1个Pod，扩容时它的Pod数量变化趋势如下:

1 -> 2 -> 3 -> 4

禁止自动缩容

< ">如果应用非常关键，希望扩容后不自动缩容，需要人工干预或其它自己开发的controller来判断缩容条件，可以使用类型如下的behavior配置来禁止自动缩容:

behavior:

  scaleDown:

    policies:

    - type: pods

      value: 0

延长缩容时间窗口

< ">缩容默认时间窗口是5 min(--horizontal-pod-autoscaler-downscale-stabilization-window)，如果我们需要延长时间窗口以避免一些流量毛刺造成的异常，可以指定下缩容的时间窗口，behavior配置示例如下:

behavior:

  scaleDown:

    stabilizationWindowSeconds: 600 # 等待 10 分钟再开始缩容

    policies:

    - type: pods

      value: 5 # 每次只缩掉 5 个 Pod

< ">上面的示例表示当负载降下来时，会等待600s(10分钟)再缩容，每次只缩容5个Pod。

延长扩容时间窗口

< ">有些应用经常会有数据毛刺导致频繁扩容，而扩容出来的Pod其实没太大必要，反而浪费资源。比如数据处理管道的场景，扩容指标是队列中的事件数量，当队列中堆积了大量事件时，我们希望可以快速扩容，但又不希望太灵敏，因为可能只是短时间内的事件堆积，即使不扩容也可以很快处理掉。

< ">默认的扩容算法会在较短的时间内扩容，针对这种场景我们可以给扩容增加一个时间窗口以避免毛刺导致扩容带来的资源浪费，behavior配置示例如下:

behavior:

  scaleUp:

    stabilizationWindowSeconds: 300 # 扩容前等待 5 分钟的时间窗口

    policies:

    - type: pods

      value: 20 # 每次扩容新增 20 个 Pod

< ">上面的示例表示扩容时，需要先等待5分钟的时间窗口，如果在这段时间内负载降下来了就不再扩容，如果负载持续超过扩容阀值才扩容，每次扩容新增20个Pod。

小结

< ">本文介绍了如何利用K8s 1.18的HPA新特性来控制扩缩容的灵敏度，以更好的满足各种不同场景对扩容速度的需求。

< ">< color: rgb(0, 112, 192);">参考资料

< ">HPA介绍:https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/