前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Kubernetes HPA级别扩缩容配置预览

Kubernetes HPA级别扩缩容配置预览

作者头像
CNCF
发布2019-12-05 17:02:28
1.6K0
发布2019-12-05 17:02:28
举报
文章被收录于专栏:CNCF
前言

本文分析 HPA 功能增强的建议,而不是真正的实现。Kubernetes 1.16 发布前夕,该功能增强还没有合入,所以最快也要到 1.17 版本发布。

新特性背景

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

  • 关键流量处理应用:该类应用希望在流量到来时快速的扩容,在流量高峰过去后,希望慢慢的缩容,以避免流量反弹;
  • 关键数据处理应用:该类应用希望当大量数据到达时希望快速扩容,在数据减少时,希望快速的缩容,以节省成本;
  • 常规流量/数据处理应用:该类应用不那么重要,可以缓慢的扩容和缩容,以避免快速扩缩容带来抖动;

而当前版本的实现(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

文章转载自容器魔方。点击这里阅读原文了解更多

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-09-20,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 CNCF 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档