写点什么

Kubernetes HPA 级别扩缩容配置预览

  • 2019 年 9 月 24 日
  • 本文字数:2435 字

    阅读完需:约 8 分钟

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


2019 年 9 月 24 日 15:352035

评论

发布
暂无评论
发现更多内容

如何使用Java AWT 创建一个简易计算器

华为云开发者联盟

Java 计算器 GUI AWT 图形

即学即会 Serverless 系列:初识 Serverless 架构

Serverless Devs

云计算 阿里云 Serverless 架构

深度揭秘阿里云 Serverless Kubernetes

Serverless Devs

企业知识管理的措施

小炮

知识管理

ShardingSphere-Proxy 5.0 分库分表(一)

神农写代码

资金管理系统解决方案

低代码小观

资产管理 企业管理系统 资金安全 CRM系统 客户关系管理系统

ModStartCMS模块化建站系统 v3.5.0 多图字段支持,系统优化升级

ModStart开源

隐私安全的必答题,网易云信如何解?

网易云信

隐私安全

如何实现24小时客户服务

小炮

客户服务

小程序多端引流新思路:App公域流量挖掘

Speedoooo

APP开发 智慧终端 引流获客工具 引流获客系统

API接口知识小结

源字节1号

程序员 有趣的技术知识

《Mybatis 手撸专栏》第1章:开篇介绍,我要带你撸 Mybatis 啦!

小傅哥

小傅哥 mybatis 手写Mybatis

字节跳动流式数据集成基于Flink Checkpoint两阶段提交的实践和优化背景

字节跳动数据平台

大数据 flink 字节跳动 数据集成

金三银四的 Vue 面试准备

CRMEB

从持续交付到业务创新(上):互联网时代研发效能的核心

阿里云云效

云计算 阿里云 云原生 研发效能 持续交付

阿里巴巴开源大规模稀疏模型训练/预测引擎DeepRec

阿里云大数据AI技术

机器学习 深度学习 搜索引擎 分布式训练 推荐引擎

从持续交付到业务创新(下):有效的业务创新

阿里云云效

云计算 阿里云 云原生 研发效能

打印总是遇到问题?一文教你如何在优麒麟上使用 CUPS 管理打印机

优麒麟

Linux 终端 优麒麟 打印机管理

安全大讲堂 | 孙朝晖:全量数据是一切网络安全分析的起点

腾讯安全云鼎实验室

数据分析 网络安全 数据安全 安全大讲堂

信创云管理平台,头部券商解决异构云资源管理的关键

BoCloud博云

信创 云管平台

web前端培训React合成事件原理解析

@零度

React web前端开发

TSP 平台场景中的 MQTT 主题设计|车联网平台搭建从入门到精通 03

EMQ映云科技

开源 物联网 IoT mqtt emq

中国企业的测试之道被美国学习了?

博文视点Broadview

动态卡片:富媒体内容井喷式增长下,新一代移动端动态研发的模式

蚂蚁集团移动开发平台 mPaaS

ios android 前端 mPaaS 卡片技术

31岁的Python,蝉联年度编程语言排行榜冠军

JackTian

Python 编程 程序员 编程语言 后端

Kubernetes HPA级别扩缩容配置预览_云计算_华为云原生团队_InfoQ精选文章