05-Autoscaling

最新推荐文章于 2024-09-11 08:12:44 发布
最新推荐文章于 2024-09-11 08:12:44 发布
阅读量63 收藏
点赞数
分类专栏： knative 文章标签： knative 云原生 serverless
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_38753143/article/details/135068658
版权

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-autoscaler
 namespace: 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-go
  namespace: 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: hello
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s"  ## Reviision级别配置实例缩容为0
    spec:
      containers:
        - image: ikubernetes/helloworld-go
          ports:
            - containerPort: 8080
          env:
            - name: TARGET
              value: "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: hello
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target-utilization-percentage: "60" # 实际每个pod接收的并发也就10*0.6
        autoscaling.knative.dev/target: "10" #最大并发10
    spec:
      containers:
        - image: ikubernetes/helloworld-go
          ports:
            - containerPort: 8080
          env:
            - name: TARGET
              value: "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: hello
  namespace: 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-go
          ports:
            - containerPort: 8080
          env:
            - name: TARGET
              value: "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: hello
  namespace: 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-go
          ports:
            - containerPort: 8080
          env:
            - name: TARGET
              value: "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个

      在这里插入图片描述

爱写代码的小男孩
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
[Python从零到壹] 十二.机器学习之回归分析万字总结全网首发（线性回归、多项式回归、逻辑回归）
杨秀璋的专栏
07-03 4万+
前一篇文章讲述了数据分析部分，主要普及网络数据分析的基本概念，讲述数据分析流程和相关技术，同时详细讲解Python提供的若干第三方数据分析库，包括Numpy、Pandas、Matplotlib、Sklearn等。本文介绍回归模型的原理知识，包括线性回归、多项式回归和逻辑回归，并详细介绍Python Sklearn机器学习库的LinearRegression和LogisticRegression算法及回归分析实例。进入基础文章，希望对您有所帮助。
二进制方式搭建Kubernetes高可用集群（超丰富的组件概念理论总结）
热门推荐
江晓龙的博客
09-23 7万+
二进制方式部署Kubernetes高可用集群 文章目录二进制方式部署Kubernetes高可用集群1.环境准备1.1.Kubernetes高可用集群部署方式1.2.Kubernetes集群弃用docker容器1.3.Kubernetes集群所需的证书1.4.环境准备1.5.安装cfssl证书生成工具2.操作系统初始化配置3.部署Etcd集群3.1.使用cfssl证书工具生成etcd证书3.2.部署etcd集群4.部署Docker服务4.1.安装docker4.2.为docker创建systemctl启动脚本
Knative 基本功能深入剖析：Knative Serving 自动扩缩容 Autoscaler
阿里巴巴云原生的博客
07-26 1322
Knative Serving 默认情况下，提供了开箱即用的快速、基于请求的自动扩缩容功能 - Knative Pod Autoscaler（KPA）。下面带你体验如何在 Knative 中玩转 Autoscaler。 Autoscaler 机制 Knative Serving 为每个 POD 注入 QUEUE 代理容器 (queue-proxy)，该容器负责向 Autoscaler 报告用户容...
Serverless Knative Serving弹性扩缩容实践整理
发现问题，面对问题，分析问题，解决问题，总结问题
03-01 2106
Knative的服务管理组件Serving是管理应用服务的理想选择，它通过自动缩容为零和基于HTTP负载自动扩展的方式简化了部署流程。Knative平台可管理应用服务的部署、版本、网络、扩缩容。
Kubernetes实战(二十八)-KPA实战
sre救赎之路
02-08 846
scale-to-zero-pod-retention-period定义了当Autoscaler决定要缩容到零时，最后一个Pod保留的最小时长。该设置主要针对那些启动代价高、流量突发性高的场景。其配置如下。全局关键字：scale-to-zero-pod-retention-period。修订版注解关键字：autoscaling.knative.dev/scaleToZeroPodRetentionPeriod。可能的值：非负时间字符串。默认值：0s。
当 Knative 遇见 WebAssembly
阿里巴巴中间件
06-16 196
Knative 是在 Kubernetes 基础之上的 Serverless 计算的技术框架，可以极大简化 Kubernetes 应用的开发与运维体验。在 2022 年 3 月成为 CNCF 孵化项目。Knative 由两个主要部分组成：一个是支持 HTTP 在线应用的 Knative Serving，一个是支持 CloudEvents 和事件驱动应用的 Knative ...
一文教会你使用Knative运行Spring Boot项目
Java架构师之路的博客
06-29 766
在本文中，我将解释什么是Knative以及如何将它与Spring Boot一起使用。尽管Knative是一个serverless无服务器平台，但我们可以在那里运行任何类型的应用程序（不仅仅是函数）。因此，我们将在那里运行一个标准的Spring Boot应用程序，它公开restapi并连接到数据库。 Knative介绍了一种在Kubernetes上管理应用程序的新方法。它扩展了Kubernetes，添加了一些新的关键特性。其中最重要的是“零缩容”。如果Knative检测到某个服务未被使用，它会将...
auto-sklearn源码阅读(1):超参空间的构造
using namespace 数学工具构造器;
02-12 795
本文分为软核与硬核部分，软核部分适合一般读者，为科普内容，不直接涉及代码。 硬核部分适合想研究底层源码的算法工程师 文章目录软核部分源码哥的烦恼auto-sklearn的功能与作用域从一个例子入手auto-sklearn 的 Pipeline优化过程：贝叶斯优化硬核部分创建搜索空间 软核部分 源码哥的烦恼 这天，源码哥的老板丢给源码哥一个Excel表，说： “小猿，这里有两个表，一个表是上个...
K8S-Demo集群实践05：安装kubectl并配置集群管理员账户
jasonhe2018的博客
01-19 498
K8S-Demo集群实践：安装kubectl并配置集群管理员账户一、下载kubectl二、把kubectl分发到3个master节点三、配置集群管理员账户 kubeconfig四、把kubeconfig分发到3个master节点 kubectl是一个命令行工具，通过访问apiserver的接口，对集群进行操作管理 k8s-demo有3个master节点和3个node节点，为了方便操作kubectl部署在3个master节点上 可以只部署在master1上，也可以部署在所有节点上，根据实际需要部署 一、下
4.Docker--Consul
day day up
09-17 1033
consul是google开源的一个使用go语言开发的服务管理软件。支持多数据中心、分布式高可用的、服务发现和配置共享。采用Raft算法，用来保证服务的高可用。内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如ZooKeeper等）服务部署简单，只有一个可运行的二进制的包。每个节点都需要运行agent，他有两种运行模式server 和 client。
修改knative func build的image
要努力成为很厉害很厉害的人哦
06-12 826
基于func create创建的function的source code，并基于build创建出function对应的image。我们需在该image内创建安装iperf3。
云原生之WEB应用服务器Tomcat（持续更新中）
小刘在努力的博客
09-07 1143
带你了解企业级web应用服务器--Tomcat
参赛心得和思路分享：2021第二届云原生编程挑战赛2： 实现一个柔性集群调度机制
gangyikeji的博客
09-10 909
实现的限流类似于限流算法中的计数器算法，就是定义一个最大线程数，定义一个超时时间timeout以及当前活跃的线程数active，当active小于等于max时就不处理正常执行，大于max时等待timeout长的时间，等待里面的请求自动超时，在这期间如果有请求结束，则唤醒一个新请求，如果在这段时间里有请求没有结束，就让正在活跃的请求全部失败。成功数相同的情况下，按照最大 TPS 排名。我们计算出当前维护的队列中所有的请求的平均耗时，然后将其加上一点点，作为预测的超时时间，作为我们的最终策略。
远超想象的复杂
AK15221736052的博客
09-11 282
传统技术栈 Activiti 复杂度远超理解， 在原有成本投入下，估计难改动，而新的集成方法，无历史包袱，思路的打开，产品力提上来后，前景广阔，Camunda 看到最后 engine 设计太过拖沓，如果么有上万个测试用例的把持， 令人绝望，抛弃engine 内核， 走预编译 --- Ad-hoc 流程如何做， 如走动态编译， sandbox 如何做？有偏数据ETL workflow 如 Airflow 有偏 ops 编排，有综合的如 n8n, 但是整体上都有一个特征：引入了AI集成；
Zblog 的CDNfly-CloudFlare全能CDN自动刷新缓存插件-自动清理-适配优化2.1.0版本
最新发布
09-12
Zblog 的CDNfly|CloudFlare全能CDN自动刷新缓存插件，包括其自动清理、适配优化和缓存配置,手动刷新，全站刷新，自动预热等功能。作者之前已写过Wordpress对接cdnfly的插件，而此次是应群友要求为Zblog打造相应插件
基于Dubbo与Spring Boot的服务化实践demo.zip
09-12
本项目是一个简单的Dubbo整合Spring Boot的示例，展示了如何通过Dubbo实现服务的注册与发现、服务的调用和监控等功能。通过本demo，读者可以了解到Dubbo服务框架与Spring Boot框架的集成方式，以及如何快速构建微服务应用。项目包括启动Nacos服务、生产者服务提供者、消费者服务调用者以及Dubbo的管理平台。通过简单的步骤和操作，可以实现服务的发布、订阅和监控。本demo对于初学者了解Dubbo和微服务架构有很好的帮助。 1、资源项目源码均已通过严格测试验证，保证能够正常运行； 2、项目问题、技术讨论，可以给博主私信或留言，博主看到后会第一时间与您进行沟通； 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用，尤其对于人工智能、计算机科学与技术等相关专业，更为适合； 4、下载使用后，可先查看README.md文件（如有），本项目仅用作交流学习参考，请切勿用于商业用途。 1、资源项目源码均已通过严格测试验证，保证能够正常运行； 2、项目问题、技术讨论，可以给博主私信或留言，博主看到后会第一时间与您进行沟通； 3、本项目比较适合计算机领域相关的毕业
weixin254基于微信小程序的社团活动助手php.rar
09-12
所有源码都可以运行成功
system_file1711460535847
09-12
system_file1711460535847
25工程建筑中工程造价的应用研究.docx
09-12
25工程建筑中工程造价的应用研究
boto3.session的client('application-autoscaling')从哪里获取值
03-28
boto3.session的client('application-autoscaling')是从AWS SDK for Python (Boto3)中获取的。具体来说，它是通过AWS SDK for Python (Boto3)中的application-autoscaling模块来创建的。这个模块提供了与AWS应用程序...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值