【问题标题】:Scheduled scaling for PODs in KubernetesKubernetes 中 POD 的计划扩展
【发布时间】:2020-04-17 10:49:24
【问题描述】:

我有一个可预测的负载变化取决于时间的扩展部署。如何让我的部署为负载做好准备(例如,我想每天晚上从 16:00 到 23:00 将 pod 数量加倍)。 Kubernetes 有提供这样的工具吗?

我知道 Kubernetes pod 正在使用Horizontal Pod Autoscaler 进行扩展,它根据 CPU 利用率或自定义指标来扩展 pod 的数量。但它是被动的方法,我正在寻找主动。

【问题讨论】:

    标签: kubernetes autoscaling


    【解决方案1】:

    一个快速的谷歌搜索将引导你到这里:https://github.com/kubernetes/kubernetes/issues/49931

    本质上,目前最好的解决方案是为你的 pod 的主容器运行一个 sidecar 容器,它可以使用 kubernetes api 通过一个简单的 bash 脚本根据时间段进行扩展,或者编写一个 CRD对基于时间的事件(下午 6 点)做出反应的自己,就像这样:

    https://github.com/amelbakry/kube-schedule-scaler

    它在部署中使用类似 cron 的规范监视注释并做出相应的反应。

    【讨论】:

      【解决方案2】:

      Kubernetes的Horizo​​ntal Pod Autoscaler并不是一种反应式的方式,但实际上是一种主动式的伸缩方式。让我用它的默认设置来解释它的算法:

      • 冷却时间为5分钟
      • 每 15 秒跟踪一次资源利用率

      这意味着系统每 15 秒跟踪一次资源利用率(取决于最终用户设置的指标,例如 CPU、存储...等)。 直到每 5 分钟冷却下来(没有缩放操作),控制器将计算过去 5 分钟的资源利用率(它使用上面每 15 秒的历史数据跟踪)。然后它通过以下等式估计下一个 5 分钟时间窗口所需的资源数量(即副本数量):

      desiredReplicas = ceil[currentReplicas * ( currentMetricValue / 期望度量值)]

      其他主动式自动缩放器也以类似的方式工作。不同点是他们可能会应用不同的技术(队列理论、机器学习或时间序列模型)来估计所需的副本,如上述等式中所做的那样。

      【讨论】:

      • 问题显然是要求预测性计划自动缩放。您所描述的是基于资源消耗的自动缩放功能。这是误导和混淆。
      猜你喜欢
      • 1970-01-01
      • 2016-11-15
      • 1970-01-01
      • 1970-01-01
      • 2018-07-05
      • 2019-07-12
      • 2018-10-14
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多