Kubernetes HPA 级别扩缩容配置预览

新特性背景

不同的应用程序业务价值不同，其对扩缩容的要求也不同，比如以下三种类型应用：

• 关键流量处理应用：该类应用希望在流量到来时快速的扩容，在流量高峰过去后，希望慢慢的缩容，以避免流量反弹；

• 关键数据处理应用：该类应用希望当大量数据到达时希望快速扩容，在数据减少时，希望快速的缩容，以节省成本；

• 常规流量 / 数据处理应用：该类应用不那么重要，可以缓慢的扩容和缩容，以避免快速扩缩容带来抖动；

而当前版本的实现（1.15 & 1.16）并不能很好的满足这类应用的期望。

当前版本的 kube-controller-manager 参数 --horizontal-pod-autoscaler-downscale-stabilization 可以在一定程度上控制缩容的速度。在每个调度周期（默认为 30s）都会计算出一个缩放的推荐值并记录下来，在每次计算缩放值时都会查看历史的推荐值，从最近的一段历史推荐值中挑选最大的，downscale-stabilization 就是用来指定这个时间窗口，默认为 5min。

另外在 HPA controller 层面，有两个硬编码的常量控制扩容的速度：

• scaleUpLimitFactor = 2.0 // 扩容倍数

• scaleUpLimitMinimum = 4.0 // 扩容个数

在计算扩容的目标值时算法如下：

Max(scaleUpLimitFactor* 当前副本数, scaleUpLimitMinimum))

也就是说，扩容要么扩成原来的 2 倍，要么扩大 4 个 pod，二者取大者。一方面这个扩容速度并不能满足上面提到的应用诉求，另一方面，这个硬编码也确实不够友好，尽管它设计本意是希望稳定的扩容以避免抖动。注：这里提到的算法是 HPA controller 层面的，跟据每个 HPA 的当前值和目标值计算出扩容比例后再套用该算法，以限制扩容速度。

缩上所述，当前版本的实现并不能满足一些应用对扩缩容的诉求，我们需要做一些改进。本文的目标就是分析社区对此需求的讨论结果，算是提前剖析新特性，但最终实现有可能跟此不一致。

新特性目标

结合前述的背景，不难得出，本次改进目标有两点：

1. 允话用户（更精确）的控制扩缩容速度；

2. 允话用户在 HPA 层面控制扩缩容速度（每个 HPA 可以有个性化的控制）；

新特性设计

既然要对每个 HPA 单独控制，那就需要在 HPA 资源 API 中增加相应的参数，所以将会引入下面 4 个参数：

• periodSeconds（扩缩容的周期）

  我们知道在 kube-controller-manager 有个参数（–horizontal-pod-autoscaler-sync-period）

  控制的是 HPA controller 处理周期，每个周期中处理所有的 HPA（为 HPA 生成扩缩容建议，并执行扩缩容）。本次计划引入的这个周期（periodSeconds）控制每个 HPA 两次扩缩容操作的间隔，也可以叫冷却时间。

• percent （扩缩容百分比）

顾名思义，这个是控制扩缩容的百分比，可以简单的理解成把硬编码的 scaleUpLimitFactor = 2.0 改成可配置项。例如，ScaleUpPercent = 150，那么每次扩容比例为 150%（10–>25）。

• pods （扩缩容个数）

这个是控制每个扩缩容的绝对个数，可以简单的理解成把硬编码的 scaleUpLimitMinimum = 4.0 改成可配置项。例如：ScaleUpPods = 5，那么每次扩容的数量将是 5 个（10–>15）。

• delay

  这个参数与 kube-controller-manager 的 horizontal-pod-autoscaler-downscale-stabilization 含义一样， 就是在计算扩缩容时，我们需要回头看多久的建议值（从中选最大），可以简单理解成把 kube-controller-manager 的参数下沉到 HPA 层面

需要注意的是，这几个参数既可以控制扩容，也可以控制缩容，下面我们给出几个示例来说明用法。

新特性示例

Story 1：我希望应用能尽快的扩容

当希望应用能尽快的扩容时，可以使用大一点的 percent。比如：

scaleUp

• percent = 900 (每次扩容 900%，即 10 倍速扩容)

假如 pod 最开始数量为 1，那么扩容路径如下：

1 -> 10 -> 100 -> 1000

当然，HPA 既有的 maxReplicas 仍然有效，最大 pod 数不能超过此设置。

Story 2: 我希望应用能尽快的扩容、逐步的缩容

当希望应用能尽快的扩容，同时缩容的慢一些时，可以使用如下配置：

scaleUp

• percent = 900

scaleDown

• pods = 1 (每次缩容减少一个 pod)

• periodSeconds = 600 (每 10 分钟缩容一次)

假如 pod 最开始数量为 1，那么扩容路径如下：

1 -> 10 -> 100 -> 1000

同时，缩容路径如下 (每 10 分钟缩容一次，每次减少一个 pod)：

1000 -> 1000 -> 1000 -> … (7 more min) -> 999

Story 3: 我希望能缓慢扩容、正常的缩容

希望缓慢的扩容、正常的缩容，可以使用如下配置：

scaleUp

• pods = 1

假如 pod 最开始数量为 1，那么扩容路径如下：

1 -> 2 -> 3 -> 4

Story 4: 我希望正常的扩容、不要自动缩容

如果希望能正常的扩容，但是不要自动缩容，可以使用如下配置：

scaleDown:

• percent= 0

• pods = 0

把缩容的百分比和 pod 都置为 0，那么就永远不会缩容。

Story 5: 我希望更谨慎的缩容

如果希望缩容时再谨慎些，可以使用 delaySeconds(这个跟 kube-controller-manager 的 horizontal-pod-autoscaler-downscale-stabilization 非常类似），配置如下：

scaleDown：

• pods = 5

• delaySeconds = 600

那么，每次缩容最多减少 5 个 pod，同时每次缩容，至少看到之前 600s 的推荐值，从中选择最大的值。这样，缩容时就会变得非常谨慎。

API 变化

API 的变化，主要是在 HorizontalPodAutoscalerSpec 中增加一个 Constraints 字段。

type HPAScaleConstraintValue struct {

Rate *HPAScaleConstraintRateValue

DelaySeconds *int32

type HPAScaleConstraintRateValue struct {

Pods *int32

Percent *int32

PeriodSeconds *int32}

type HPAScaleConstraints struct {

ScaleUp *HPAScaleConstraintValue

ScaleDown *HPAScaleConstraintValue}

type HorizontalPodAutoscalerSpec struct {

ScaleTargetRef CrossVersionObjectReference

MinReplicas *int32

MaxReplicas int32

Metrics []MetricSpec Constraints *HPAScaleConstraints}

当前无论是 API 还是最终实现都还在讨论中，如果对这个特性感兴趣，也可以加入讨论。

特性设计：

https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md

特性实现：

https://github.com/kubernetes/kubernetes/pull/74525

【原文】： https://www.infoq.cn/article/5bKfl9MeeZglFdOkrtIN