关于腾讯云:如何根据不同业务场景调节-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 两个字段别离管制扩容和缩容的行为，具体可参考官网 API 文档: https://v1-18.docs.kubernetes…

上面给出一些应用场景的示例。

疾速扩容

当你的利用须要疾速扩容时，能够应用相似如下的 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 新个性来管制扩缩容的灵敏度，以更好的满足各种不同场景对扩容速度的需要。

参考资料

• HPA 介绍: https://kubernetes.io/docs/ta…

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！