05-Autoscaling

2023-12-18 19:44
文章标签 05 autoscaling

本文主要是介绍05-Autoscaling，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1 Knative的自动缩放机制

  • “请求驱动计算”是serverless的核心特性

    • 缩容至0：即没有请求时，系统不会分配资源给Kservice；
    • 从0开始扩容：由Activator缓存请求，并报告指标数据给Autoscaler；
    • 按需扩容：Autoscaler根据Revision中各实例的QP报告的指标数据不断调整Revision中实例数量

  • Knative系统中，Autoscaler、Activator和Queue-Proxy三者协同管理应用规模与流量规模的匹配

    • Knative附带了开箱即用的AutoScaler，简称KPA；
    • 同时，Knative还支持使用Kubernetes HPA进行Deployment缩放

    在这里插入图片描述

  • Autoscaler在扩缩容功能上实现的基本假设

    • 用户不能仅因为服务实例收缩为0而收到错误响应
    • 请求不能导致应用过载
    • 系统不能造成无谓的资源浪费

    在这里插入图片描述

2 请求如何驱动计算

  • Knative的自动扩缩容机制依赖于两个前提

    • 为Pod实例配置支持的目标并发数（在给定的时间里可同时处理的请求数）
    • 应用实例支持的缩放边界
      • 最少实例数，0即表示支持缩容至0实例；
      • 最大实例数

  • AutoScaler的基本缩放逻辑

    • Autoscaler基于过去一段时间内（stable windows指定）统计的指标(metrics)数据和单个实例的目标并发数(target)来计算目标实例数
    • 计算出的目标实例数将发送给相应的Revision的Deployment执行缩放操作

    在这里插入图片描述

3 Autoscaler执行扩缩容的基本流程

  • 目标Revision零实例

    • 初次请求由Ingress GW转发给Activator进行缓存，同时报告给数据给Autoscaler，进而控制相应的Deployment来完成Pod实例扩展；
    • Pod副本ready后，Activator将缓存的请求转发给相应的Pod对象；
    • 随后，存在ready状态的Pod期间，Ingress GW将后续的请求直接转给Pod，而不再转给Activator；

  • 目标Revision存在至少一个Ready状态的Pod

    • Autoscaler根据Revision中各Pod的Queue-Proxy容器持续报告指标数据持续计算Pod副本数；
    • Deployment根据Autoscaler的计算结果进行实例数量调整

  • Reviision实例数不为0，但请求数持续为0

    • Autoscaler在Queue-Proxy持续一段时间报告指标为0后，即将其Pod缩减为0
    • 随后，Ingress GW会将收到的请求再次转发给Activator

    在这里插入图片描述

3.1 零实例时收到请求的工作流程

在这里插入图片描述

3.2 非零实例时

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

4 缩放窗口和Panic

  • 负载变动频繁时，Knative可能会因为响应负载变动而导致频繁创建或销毁Pod实例；

  • 为避免服务规模“抖动”，Autoscaler支持两种扩缩容模式：

    • Stable：根据窗口稳定期（stable windows，默认60秒）的请求平均数（平均并发数）及每个Pod的目标并发数计算Pod数
    • Panic：短期内收到大量请求时，将启用Panic模式
      • 十分之一窗口期(6秒)的平均并发数> 2*单实例目标并发数
      • 进入panic模式60秒后，系统会重新返回stable模式

  • 以下图矩阵为例（假设现有的实例数和平均并发数均为0）

    • 横轴（现有实例数量）：0个、1个和M个
    • 纵轴（到达的请求数）： 0个、1个和N个

    在这里插入图片描述

5 Autoscaler计算Pod数的基本逻辑

  • 指标收集周期和决策周期
    • Autoscaler每2秒钟计算一次Revision上所需要Pod实例数量
    • Autoscaler每2秒钟从Revision的Pod实例（Quueu-Proxy容器）上抓取一次指标数据，并将其（每秒的）平均值存储于单独的bucket中
      • 实例较少时，则从每个实例抓取指标
      • 实例较多时，则从实例的一个子集上抓取指标，因而计算出的Pod实例数量并非精准数值
  • 决策过程
    • Autoscaler在Revision中检索就绪状态的Pod实例数量
      • 若就绪状态实例为0，将其设定为1，即使用Activator作为实例
    • Autoscaler检查累积收集的可用指标
      • 若不存在任何可用指标，则将所需要的Pod实例数设置为0
      • 若存在累积的指标，则计算出窗口期内的平均并发请求数
      • 根据平均并发请求数和每实例的并发目标值计算出所需要的Pod实例数
        • 窗口期内每实例的平均并发请求数 = Bucket中的样本值之和 / Bucket数量
        • 每实例的目标并发请求数 = 单实例目标并发数 * 目标利用率
        • 期望的Pod数 = 窗口期内每实例的并发请求数 / 每实例目标并发请求数
      • Panic的触发条件
        • 期望的Pod数 / 现有的Pod数 ≥ 2
        • 60秒之后返回至Stable

6 Knative支持的Autoscaler

  • Knative支持基于KPA和HPA的自动缩放机制，但二者的功能略有不同；
    • Knative Pod Autoscaler
      • Knative Serving的核心组件，且默认即为启用状态
      • 支持缩容为0
      • 不支持基于CPU的自动缩放机制
    • Kubernetes Horizontal Pod Autoscaler
      • Kubernetes系统上的组件
      • 不支持缩容至0
      • 支持基于CPU的自动缩放机制
6.1 配置要使用的Autoscaler

  • Autoscaler的功能设定方式

    • 全局配置：ConfigMap/config-autoscaler
    • 每Revision配置：Revision Annotations

  • 配置要使用的Autoscaler

    • 全局配置：位于knative-serving名称空间下的ConfigMap资源config-autoscaler之中

      apiVersion: v1
kind: ConfigMap
metadata:name: config-autoscalernamespace: knative-serving
data:pod-autoscaler-class: "kpa.autoscaling.knative.dev" # hpa.autoscaling.knative.dev

    • 特定的Revision：使用注解“autoscaling.knative.dev/class”

      apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: helloworld-gonamespace: default
spec:template:metadata:annotations:autoscaling.knative.dev/class: "kpa.autoscaling.knative.dev"spec:containers:- image: ghcr.io/knative/helloworld-go:latest

  • 可用的指标

    • KPA：concurrency和rps，默认是concurrency
    • HPA：cpu、memory和custom
6.2 Autoscaler的全局配置
  • 全局配置参数定义在knative-serving名称空间中的configmap/auto-scaler之中
  • 相关参数
    • container-concurrency-target-default：实例的目标并发数，即最大并发数，默认值为100；
    • container-concurrency-target-percentage：实例的目标利用率，默认为“0.7” ；
    • enable-scale-to-zero：是否支持缩容至0，默认为true；仅KPA支持；
    • max-scale-up-rate：最大扩容速率，默认为1000；
      • 当前可最大扩容数 = 最大扩容速率 * Ready状态的Pod数量
    • max-scale-down-rate：最大缩容速率，默认为2
      • 当前可最大缩容数 = Ready状态的Pod数量 / 最大缩容速率
    • panic-window-percentage：Panic窗口期时长相当于Stable窗口期时长的百分比，默认为10，即百分之十；
    • panic-threshold-percentage：因Pod数量偏差而触发Panic阈值百分比，默认为200，即2倍；
    • scale-to-zero-grace-period：缩容至0的宽限期，即等待最后一个Pod删除的最大时长，默认为30s；
    • scale-to-zero-pod-retention-period：决定缩容至0后，允许最后一个Pod处于活动状态的最小时长，默认为0s；
    • stable-window：稳定窗口期的时长，默认为60s；
    • target-burst-capacity：突发请求容量，默认为200；
    • requests-per-second-target-default：每秒并发（RPS）的默认值，默认为200；使用rps指标时生效；
6.3 配置支持缩容至0实例

  • 配置支持Revision自动缩放至0实例的参数

    • enable-scale-to-zero：不支持Revision级别的配置
    • scale-to-zero-grace-period：不支持Revision级别的配置
    • scale-to-zero-pod-retention-period：◆Revision级别配置时，使用注解键“autoscaling.knative.dev/scale-to-zero-pod-retention-period”

  • 配置示例

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: hellonamespace: default
spec:template:metadata:annotations:autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s"  ## Reviision级别配置实例缩容为0spec:containers:- image: ikubernetes/helloworld-goports:- containerPort: 8080env:- name: TARGETvalue: "Knative Autoscaling Scale-to-Zero"
6.4 配置实例并发数

  • 单实例并发数相关的设定参数

    • 软限制：流量突发尖峰期允许超出
      • 全局默认配置参数：container-concurrency-target-default
      • Revision级的注解：autoscaling.knative.dev/target
    • 硬限制：不允许超出，达到上限的请求需进行缓冲
      • 全局默认配置参数：container-concurrency：位于config-defaults中
      • Revision级的注解：containerConcurrency
    • Target目标利用率
      • 全局配置参数：container-concurrency-target-percentage
      • Revision级的注解：autoscaling.knative.dev/target-utilization-percentage

  • 配置案例

    • 场景：配置ksvc/hello的实例目标并发为10，利用率为0.6. 现在用hey压测发送20个并发。理论上来说，有4个pod会创建。

    • 实例并发数的配置清单

      apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: hellonamespace: default
spec:template:metadata:annotations:autoscaling.knative.dev/target-utilization-percentage: "60" # 实际每个pod接收的并发也就10*0.6autoscaling.knative.dev/target: "10" #最大并发10spec:containers:- image: ikubernetes/helloworld-goports:- containerPort: 8080env:- name: TARGETvalue: "Knative Autoscaling Concurrency"

    • 用hey工具进行20并发请求

      hey -z 60s -c 20 -host "hello.default.icloud2native.com" http://192.168.58.100?sleep=100&prime=10000&bloat=5

    • 结论发现确实有4个实例创建，符合预期

      在这里插入图片描述

6.5 配置Revision的扩缩容边界

  • 相关的配置参数

    • 最小实例数
      • Revision级别的Annotation: autoscaling.knative.dev/min-scale：说明：KPA且支持缩容至0时，该参数的默认值为0；其它情况下，默认值为1；
    • 最大实例数
      • 全局参数：max-scale
      • Revision级别的Annotation: autoscaling.knative.dev/max-scale：整数型取值，0表示无限制
    • 初始规模：创建Revision，需要立即初始创建的实例数，满足该条件后Revision才能Ready，默认值为1；
      • 全局参数：initial-scale和allow-zero-initial-scale
      • Revision级别的Annotation：autoscaling.knative.dev/initial-scale：其实际规模依然可以根据流量进行自动调整
    • 缩容延迟：时间窗口，在应用缩容决策前，该时间窗口内并发请求必须处于递减状态，取值范围[0s, 1h]
      • 全局参数：scale-down-delay
      • Revision级别的Annotation：autoscaling.knative.dev/scale-down-delay
    • Stable窗口期：取值范围[6s, 1h]
      • 全局参数：stable-window
      • Revision级别的Annotation: autoscaling.knative.dev/window

  • 配置案例

    • 配置ksvc/hello的实例目标并发为10，利用率为0.6. 现在用hey压测发送50个并发。理论上来说，有9个pod会创建。但是，我们定义的最大扩容实例为3个，所以，多余的请求会在QP中缓冲

    • 扩缩容边界的配置清单

      apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: hellonamespace: default
spec:template:metadata:annotations:autoscaling.knative.dev/target-utilization-percentage: "60"autoscaling.knative.dev/target: "10"autoscaling.knative.dev/max-scale: "3"autoscaling.knative.dev/initial-scale: "1"autoscaling.knative.dev/scale-down-delay: "1m"autoscaling.knative.dev/stable-window: "60s"spec:containers:- image: ikubernetes/helloworld-goports:- containerPort: 8080env:- name: TARGETvalue: "Knative Autoscaling Scale Bounds"

    • hey -z 50s -c 50 -host "hello.default.icloud2native.com" http://192.168.58.100?sleep=100&prime=10000&bloat=5

    • 可以发现，最多有3个pod创建

      在这里插入图片描述

6.6 使用rps指标

  • 相关的配置参数

    • 定义使用rps指标
      • Revision级别的Annotation：autoscaling.knative.dev/metric：取值为RPS;
    • 为rps指标指定目标请求数
      • 全局参数：requests-per-second-target-default
      • Revision级别的Annotation：autoscaling.knative.dev/target：整数取值，默认值为200

  • 配置示例

    • 场景：配置ksvc/hello的实例目标并发为100，利用率为0.6. 现在用hey压测模拟在60秒内以20的并发请求，总共加起来1200个请求。理论上来说，有20个pod会创建。但是，我们定义的最大扩容实例为10个，所以，多余的请求会在QP中缓冲

    • rps的配置清单

      apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: hellonamespace: default
spec:template:metadata:annotations:autoscaling.knative.dev/target-utilization-percentage: "60"autoscaling.knative.dev/metric: "rps"autoscaling.knative.dev/target: "100"autoscaling.knative.dev/max-scale: "10"autoscaling.knative.dev/initial-scale: "1"autoscaling.knative.dev/stable-window: "2m"spec:containers:- image: ikubernetes/helloworld-goports:- containerPort: 8080env:- name: TARGETvalue: "Knative Autoscaling Metrics and Targets"

    • 使用如下测试命令，模拟在60秒内，以20的并发向hello KService发起请求

      hey -z 60s -c 20 -host "hello.default.icloud2native.com" http://192.168.58.100?sleep=100&prime=10000&bloat=5

    • 验证：相应Revision上的实例数量会扩展至多个，但最多不超过10个

      在这里插入图片描述

这篇关于05-Autoscaling的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/509565。

相关文章

忽略某些文件 —— Git 学习笔记 05

忽略某些文件 —— Git 学习笔记 05

忽略某些文件 忽略某些文件 通过.gitignore文件其他规则源如何选择规则源参考资料 对于某些文件，我们不希望把它们纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。通常它们都是些自动生成的文件，比如日志文件、编译过程中创建的临时文件等。 通过.gitignore文件 假设我们要忽略 lib.a 文件，那我们可以在 lib.a 所在目录下创建一个名为 .gi
阅读更多...
C++入门(05-2)从命令行执行C++编译器_GCC

C++入门(05-2)从命令行执行C++编译器_GCC

文章目录 GCC编译器1. 下载MinGW-w64，安装（不推荐）2. 使用MSYS2安装MinGW-w64（推荐）2.1 安装MSYS22.2 初始化和更新2.3 安装MinGW-w64编译器2.3 在MSYS2 Shell中导航到代码目录2.4 使用 g++ 编译2.5 运行可执行文件 GCC编译器 GCC（GNU Compiler Collection）是一个开源编译器集
阅读更多...
C++入门(05)从命令行执行C++编译器_MSVC

C++入门(05)从命令行执行C++编译器_MSVC

文章目录 1.C++ 编译器2. 常用 C++ 编译器MSVC(Microsoft Visual C++)GCC(GNU Compiler Collection)Clang 3. MSVC 编译器3.1 开发者命令提示符3.2 编译 C++ 代码 1.C++ 编译器 将C++源代码（扩展名为 .cpp ）转换成计算机可以运行的可执行程序 编译器会检查代码的语法和语义，生成相应
阅读更多...
龙芯+FreeRTOS+LVGL实战笔记（新）——05部署主按钮

龙芯+FreeRTOS+LVGL实战笔记（新）——05部署主按钮

本专栏是笔者另一个专栏《龙芯+RT-Thread+LVGL实战笔记》的姊妹篇，主要的区别在于实时操作系统的不同，章节的安排和任务的推进保持一致，并对源码做了改进和优化，各位可以先到本人主页下去浏览另一专栏的博客列表（目前已撰写36篇，图1所示），再决定是否订阅。此外，也可以前往本人在B站的视频合集（图2所示）观看所有演示视频，合集首个视频链接为： 借助RT-Thread和LVGL
阅读更多...
【SpringMVC学习05】SpringMVC中的异常处理器

【SpringMVC学习05】SpringMVC中的异常处理器

SpringMVC在处理请求过程中出现异常信息交由异常处理器进行处理，自定义异常处理器可以实现一个系统的异常处理逻辑。 异常处理思路 我们知道，系统中异常包括两类：预期异常和运行时异常(RuntimeException)，前者通过捕获异常从而获取异常信息，后者主要通过规范代码开发、测试通过手段减少运行时异常的发生。系统的dao、service、controller出现异常都通过throws E
阅读更多...
学习硬件测试05：NTC（ADC）+正弦波（DAC）+DMA（ADC+DAC）（P73、P76、P78）

学习硬件测试05：NTC（ADC）+正弦波（DAC）+DMA（ADC+DAC）（P73、P76、P78）

文章以下内容全部为硬件相关知识，鲜有软件知识，并且记的是自己需要的部分，大家可能看不明白。 一、NTC（ADC） 1.1实验现象 本实验用 NTC 采集温度，数码管实时显示温度数据（整数），左下角 USB 小串口每隔 1S 打印温度信息。 1.2硬件电路 NTC 电阻是一个模拟温度传感器，随着温度的升高，电阻值逐渐减小。电路简单介绍如下: 电源滤波电容在 25℃ 室温下 NTC 电
阅读更多...
python+selenium2学习笔记unittest-05测试用例实例

python+selenium2学习笔记unittest-05测试用例实例

看一下非常简单的目录结构 test_baidu from selenium import webdriverimport unittestimport timeclass MyTest(unittest.TestCase):def setUp(self):self.driver = webdriver.Firefox()self.driver.maximize_window()self
阅读更多...
【DL--05】深度学习基本概念—函数式模型

【DL--05】深度学习基本概念—函数式模型

函数式模型 函数式模型算是本文档比较原创的词汇了，所以这里要说一下 在Keras 0.x中，模型其实有两种，一种叫Sequential，称为序贯模型，也就是单输入单输出，一条路通到底，层与层之间只有相邻关系，跨层连接统统没有。这种模型编译速度快，操作上也比较简单。第二种模型称为Graph，即图模型，这个模型支持多输入多输出，层与层之间想怎么连怎么连，但是编译速度慢。可以看到，Sequentia
阅读更多...
【ML--05】第五课 如何做特征工程和特征选择

【ML--05】第五课 如何做特征工程和特征选择

一、如何做特征工程？ 1.排序特征：基于7W原始数据，对数值特征排序，得到1045维排序特征 2. 离散特征：将排序特征区间化（等值区间化、等量区间化），比如采用等量区间化为1-10，得到1045维离散特征 3. 计数特征：统计每一行中，离散特征1-10的个数，得到10维计数特征 4. 类别特征编码：将93维类别特征用one-hot编码 5. 交叉特征：特征之间两两融合，x+y、x-y、
阅读更多...
F12抓包05：Network接口测试（抓包篡改请求）

F12抓包05：Network接口测试（抓包篡改请求）

课程大纲         使用线上接口测试网站演示操作，浏览器F12检查工具如何进行简单的接口测试：抓包、复制请求、篡改数据、发送新请求。         测试地址：https://httpbin.org/forms/post ① 抓包：鼠标右键打开“检查”工具（F12），tab导航选择“网络”（Network），输入前3项点击提交，可看到录制的请求和返回数据。
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2