【问题标题】:Kubernetes HPA - Scale up cooldownKubernetes HPA - 扩大冷却时间
【发布时间】:2021-02-07 22:21:47
【问题描述】:

我正在运行一个带有 HPA 的 Kubernetes 集群 v1.16(目前是 GKE 上的最新版本),它根据自定义指标(特别是从谷歌云监控获取的 rabbitmq 消息计数)扩展部署。

问题

当消息数暂时很高时,部署会非常快速地扩展到最大 pod 数。

信息

HPA --horizo​​ntal-pod-autoscaler-sync-period 在 GKE 上设置为 15 秒,据我所知无法更改。

我的自定义指标每 30 秒更新一次。

我相信导致这种行为的原因是,当队列中每 15 秒有大量消息计数时,HPA 会触发扩展,并且在几个周期后它会达到最大 pod 容量。

在 kubernetes api v1.18 中,您可以控制放大稳定时间,但我在 v1.16 中找不到类似的功能。

我的问题

我怎样才能让 HPA 逐步扩大规模?

编辑 1

我的一项部署的 HPA 示例:

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: my-deployment-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicas: 6
  maxReplicas: 100
  metrics:
  - type: External
    external:
      metricName: "custom.googleapis.com|rabbit_mq|v1-compare|messages_count"
      metricSelector:
        matchLabels:
          metric.labels.name: production
      targetValue: 500
  

【问题讨论】:

    标签: kubernetes google-kubernetes-engine hpa


    【解决方案1】:

    我们构建了一个高度可配置的开源Custom HPA
    专门针对您的情况,您可以将 HPA 设置为在缩减事件之间进行冷却。

    要使用自定义 HPA,您只需:

    ; add nanit helm repo
    $ helm repo add nanit https://nanit.github.io/helm-charts
    
    ; install the chart in the cluster
    helm install nanit/custom-hpa \ 
      --version 1.0.7 \
      --set target.deployment=<deployment> \
      --set target.namespace=<namespace> \
      --set target.value=100 \
      --set minReplicas=10 \
      --set maxReplicas=50 \
      --set behavior.scaleDownCooldown=120 \
      --set prometheus.url=<prometheus-url> \
      --set prometheus.port=<prometheus-port> \
      --set prometheus.query=<prometheus-target-metric>
    

    您要查找的设置是 behavior.scaleDownCooldown,它指示 HPA 在再次缩减之前应等待的时间(以秒为单位)。

    目前自定义 HPA 仅支持 prometheus 作为指标提供程序,但您可以使用 RabbitMQ exporter 并将 queue_messages_ready 设置为目标指标。

    【讨论】:

      【解决方案2】:

      首先,需要了解的一条重要信息是,Kubernetes 中有一个内置的自动扩缩器冷却时间。引用 Kubernetes in Action:

      目前,只有在过去三分钟内没有发生重新缩放事件时,才会发生放大。缩减事件的执行频率更低——每五分钟一次。请记住这一点,这样您就不会想知道为什么自动缩放器拒绝执行重新缩放操作,即使指标清楚地表明它应该这样做。

      可能是此声明已过时,但除非更改,否则这是硬编码的,并且每个扩展/缩减事件不应扩展超过 100% 的现有 pod。

      也就是说,无论哪种方式,您都没有选择余地,以下是您可以采取的一些方法:

      1. 通过时间平均函数传递您的自定义指标以进行缩放 - 上次我这样做是使用 prometheus 和 promql 可能与您使用的不同,但如果您在问题中分享更多配置,我'我确定我可以帮助找到语法。
      2. 您可以尝试使用Keda - 它有一个cooldownPeriod 对象,您可以将它放在它附带的ScaledObject 自定义资源中。

      【讨论】:

      • 感谢您的回答。我已经为我的一个部署添加了 HPA。我来看看科达。你认为时间平均方法会如我所愿吗?
      • 它应该会减少峰值 - 如果您使用 10 分钟的时间平均值聚合数据,那么仅持续一分钟的 200% 峰值不会平均跳得那么高。但是,如果它会持续更长时间(那时并不是真正的“峰值”)——平均值也会上升,从而触发 HPA 扩大规模。请记住,您为平均值选择的时间窗口越长,HPA 响应所需的时间就越长,但它也会更好地处理峰值 - 这是一种平衡行为
      • 你能帮我看看平均时间语法吗?我找不到那个例子
      • 当然。正如我所说,我的经验是使用 promql,但稍后我会回顾你的例子,我会用我发现的内容编辑我的答案
      猜你喜欢
      • 2021-05-15
      • 2021-06-17
      • 2021-02-16
      • 2020-06-27
      • 2021-05-02
      • 2021-04-21
      • 2021-12-04
      • 2017-11-21
      • 2016-08-17
      相关资源
      最近更新 更多