技术干货:解密最受欢迎的开源 Serverless 框架弹性技术实现

原创
2023/10/10 15:29
阅读数 362

作者:元毅

Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架,其目标是制定云原生、跨平台的 Serverless 应用编排标准。Knative 主要功能包括基于请求的自动弹性、缩容到 0、多版本管理、基于流量的灰度发布以及事件驱动等。

弹性是 Serverless 中的核心能力,那么 Knative 作为 CNCF 社区最受欢迎的开源 Serverless 应用框架,提供了哪些与众不同的弹性能力呢?本文将带你深入了解 Knative 的弹性实现。 (说明:本文基于 Knative 1.8.0 版本进行分析)

Knative 提供了基于请求的自动弹性实现 KPA(Knative  Pod Autoscaler),也支持 K8s 中的 HPA,此外 Knative 提供了灵活的弹性扩展机制,可以结合自身业务需要,扩展弹性实现。这里我们也会介绍与 MSE 结合实现精准弹性以及与 AHPA 结合实现基于请求的弹性预测。

首先我们介绍 Knative 原生最具吸引力的弹性:KPA。

基于请求的自动弹性 KPA

基于 CPU 或者 Memory 的弹性,有时候并不能完全反映业务的真实使用情况,而基于并发数或者每秒处理请求数 (QPS/RPS),对于 web 服务来说更能直接反映服务性能,Knative 提供了基于请求的自动弹性能力。要获得当前服务的请求数,Knative Serving 为每个 Pod 注入 QUEUE 代理容器 (queue-proxy),该容器负责收集用户容器并发数 (concurrency) 或请求数 (rps) 指标。Autoscaler 定时获取这些指标之后,会根据相应的算法,调整 Deployment 的 Pod 数量,从而实现基于请求的自动扩缩容。

图片来源: https://knative.dev/docs/serving/request-flow/

基于请求数的弹性算法

Autoscaler 基于每个 Pod 的平均请求数(或并发数)进行弹性计算。默认情况下 Knative 使用基于并发数的自动弹性, 默认 Pod 的最大并发数为 100。此外 Knative 中还提供了一个叫 target-utilization-percentage 的概念,称之为目标使用率,取值范围 0~1,默认是 :0.7。

以基于并发数弹性为例,Pod 数计算方式如下:

POD数=并发请求总数/(Pod最大并发数*目标使用率)

例如服务中 Pod 最大并发数设置了 10,这时候如果接收到了 100 个并发请求,目标使用率设置为 0.7,那么 Autoscaler 就会创建了 15 个 POD(100/(0.7*10) 约等于 15)。

缩容到 0 的实现机制

使用 KPA 时当无流量请求时,会将 Pod 数自动缩容到 0;当有请求时,会从 0 开始扩容 Pod。那么 Knative 中是如何实现这样的操作呢?答案是通过模式切换。

Knative 中定义了 2 种请求访问模式:Proxy 和 Serve。Proxy 顾名思义,代理模式,也就是请求会通过 activator 组件进行代理转发。Serve 模式是请求直达模式,从网关直接请求到 Pod,不经过 activator 代理。如下图:

模式的切换是由 autoscaler 组件负责,当请求为 0 时,autoscaler 会将请求模式切换为 Proxy 模式。这时候请求会通过网关请求到 activator 组件,activator 收到请求之后会将请求放在队列中,同时推送指标通知 autoscaler 进行扩容,当 activator 检测到由扩容 Ready 的 Pod 之后,随即将请求进行转发。而 autoscaler 也会判断 Ready 的 Pod,将模式切换为 Serve 模式。

应对突发流量

突发流量下如何快速弹资源

KPA 涉及到 2 个与弹性相关的概念:Stable(稳定模式)和 Panic(恐慌模式),基于这 2 种模式,可以让我们认识到 KPA 如何基于请求做到精细化弹性。

首先稳定模式是基于稳定窗口期,默认是 60 秒。也就是计算在 60 秒时间段内,Pod 的平均并发数。

而恐慌模式是基于恐慌窗口期,恐慌窗口期是通过稳定窗口期与 panic-window-percentage 参数计算得到。panic-window-percentage取值是 0~1,默认是 0.1。恐慌窗口期计算方式:恐慌窗口期=稳定窗口期 *panic-window-percentage。默认情况下也就是 6 秒。计算在 6 秒时间段内,Pod 的平均并发数。

KPA 中会基于稳定模式和恐慌模式 Pod 的平均并发数分别计算所需要的 Pod 数。

那么实际根据哪个值进行弹性生效呢?这里会依据恐慌模式下计算的 Pod 数是否超过恐慌阈值 PanicThreshold 进行判断。恐慌阈值是通过 panic-threshold-percentage/100 计算出来,panic-threshold-percentage 参数默认是 200,也就是恐慌阈值默认是 2。当恐慌模式下计算出来的 Pod 数大于或等于当前 Ready Pod 数的 2 倍,那么就会使用恐慌模式 Pod 数进行弹性生效,否则使用稳定模式 Pod 数。

显然,恐慌模式的设计是为了应对突发流量场景。至于弹性敏感度,则可以通过上述的可配置参数进行调节。

突发流量下如何避免 Pod 被打爆

KPA 中可以设置突发请求容量(target-burst-capacity)应对 Pod 被超预期的流量打爆。也就是通过这个参数值的计算,来调节请求是否切换到 Proxy 模式,从而通过 activator 组件作为请求缓冲区。如果当前 ready pod 数*最大并发数-突发请求容量-恐慌模式计算出来的并发数 <0,意味着突发流量超过了容量阈值,则切换到 activator 进行请求缓冲。当突发请求容量值为 0 时,只有 Pod 缩容到 0 时,才切换到 activator。当大于 0 并且 container-concurrency-target-percentage 设置为 100 时,请求总是会通过 activator。-1 表示无限的请求突发容量。请求也总是会通过 activator。

减少冷启动的一些技巧

延迟缩容

对于启动成本较高的 Pod, KPA 中可以通过设置 Pod 延迟缩容时间以及 Pod 缩容到 0 保留期,来减少 Pod 扩缩容频率。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/scale-down-delay: ""60s"
        autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

调低目标使用率,实现资源预热

Knative 中提供了目标阈值使用率的配置。通过调小该值可以提前扩容超过实际需要使用量的 Pod 数,在请求达到目标并发数之前进行扩容,间接的可以做到资源预热。例如,如果 containerConcurrency 设置为 10,目标利用率值设置为 70(百分比),则当所有现有 Pod 的平均并发请求数达到 7 时,Autoscaler 将创建一个新 Pod。因为 Pod 从创建到 Ready 需要一定的时间,通过调低目标利用率值可以做到提前扩容 Pod,从而减少冷启动导致的响应延迟等问题。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target-utilization-percentage: "70"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

配置 KPA

通过上面的介绍,我们对 Knative Pod Autoscaler 工作机制有了进一步的了解,那么接下来介绍如何配置 KPA。Knative 中配置 KPA 提供了两种方式:全局模式和 Revision 模式。

全局模式

全局模式可以修改 K8s 中的 ConfigMap:config-autoscaler,查看 config-autoscaler 使用如下命令:

kubectl -n knative-serving get cm config-autoscaler

apiVersion: v1
kind: ConfigMap
metadata:
 name: config-autoscaler
 namespace: knative-serving
data:
 container-concurrency-target-default: "100"
 container-concurrency-target-percentage: "70"
 requests-per-second-target-default: "200"
 target-burst-capacity: "211"
 stable-window: "60s"
 panic-window-percentage: "10.0"
 panic-threshold-percentage: "200.0"
 max-scale-up-rate: "1000.0"
 max-scale-down-rate: "2.0"
 enable-scale-to-zero: "true"
 scale-to-zero-grace-period: "30s"
 scale-to-zero-pod-retention-period: "0s"
 pod-autoscaler-class: "kpa.autoscaling.knative.dev"
 activator-capacity: "100.0"
 initial-scale: "1"
 allow-zero-initial-scale: "false"
 min-scale: "0"
 max-scale: "0"
 scale-down-delay: "0s"

参数说明:

参数 说明
container-concurrency-target-default 默认Pod最大并发数,默认值100
container-concurrency-target-percentage 并发数目标使用率,70实际表示0.7
requests-per-second-target-default 默认每秒请求数(rps),默认值200
target-burst-capacity 突发请求容量
stable-window 稳定窗口,默认60s
panic-window-percentage 恐慌窗口比例,默认值为10,则表示默认恐慌窗口期为6秒(60*0.1=6)
panic-threshold-percentage 恐慌阈值比例,默认值200
max-scale-up-rate 最大扩缩容速率,表示一次扩容最大数,实际计算方式:math.Ceil(MaxScaleUpRate * readyPodsCount)
max-scale-down-rate 最大缩容速率,表示一次缩容最大数,实际计算方式:math.Floor(readyPodsCount / MaxScaleDownRate)。默认值2表示,每次缩容一半。
enable-scale-to-zero 是否开始缩容到0,默认开启
scale-to-zero-grace-period 优雅缩容到0的时间,也就是延迟多久缩容到0,默认30s
scale-to-zero-pod-retention-period pod缩容到0保留期,该参数适用于Pod启动成本较高的情况
pod-autoscaler-class 弹性插件类型,当前支持的弹性插件包括:kpa、hpa、ahpa以及mpa(ask场景下配合mse支持缩容到 0)
activator-capacity activator请求容量
initial-scale 创建revision时,初始化启动的Pod数,默认1
allow-zero-initial-scale 是否允许创建revision时,初始化0个Pod, 默认false,表示不允许
min-scale revision级别最小保留的Pod数量。默认0表示最小值可以为0
max-scale revision级别最大扩容的Pod数量。默认0表示无最大扩容上限
scale-down-delay 表示延迟缩容时间,默认0表示立即缩容

Revision 版本模式

在 Knative 中可以为每一个 Revision 配置弹性指标,部分配置参数如下:

  • 指标类型

<!---->

    • 每个 revision 指标注解:autoscaling.knative.dev/metric
    • 支持的指标:"concurrency","rps","cpu","memory"以及其它自定义指标
    • 默认指标:"concurrency"

<!---->

  • 目标阈值

<!---->

    • autoscaling.knative.dev/target
    • 默认值:"100"

<!---->

  • pod 缩容到 0 保留期

<!---->

    • autoscaling.knative.dev/scale-to-zero-pod-retention-period

<!---->

  • 目标使用率

<!---->

    • autoscaling.knative.dev/target-utilization-percentage

配置示例如下:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/metric: "concurrency"
        autoscaling.knative.dev/target: "50"
        autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s"
        autoscaling.knative.dev/target-utilization-percentage: "80"

对 HPA 的支持

对于 K8s HPA, Knative 也提供天然的配置支持,可以在 Knative 使用基于 CPU 或者 Memory 的自动弹性能力。

  • 基于 CPU 弹性配置

<!---->

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"
        autoscaling.knative.dev/metric: "cpu"
  • 基于 Memory 的弹性配置

<!---->

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"
        autoscaling.knative.dev/metric: "memory"

弹性能力增强

Knative 提供了灵活的插件机制(pod-autoscaler-class),可以支持不同的弹性策略。阿里云容器服务 Knative 当前支持的弹性插件包括:kpa、hpa、精准弹性扩缩容 mpa 以及 具有预测能力的 ahpa。

保留资源池

在原生的 KPA 能力之上,我们提供了保留资源池的能力。该功能可以应用在如下场景:

  • ECS 与 ECI 混用。如果希望常态情况下使用 ECS 资源,突发流量使用 ECI, 那么我们可以通过保留资源池来实现。如单个 Pod 处理的并发 10,保留资源池 Pod 数为 5,那么常态下通过 ECS 资源可以应对不超过 50 的并发请求。如果并发数超过 50,那么 Knative 就会扩容新的 Pod 数来满足需求,新扩容出来的资源使用 ECI。

  • 资源预热。对于完全使用 ECI 的场景,也可以通过保留资源池实现资源预热。当在业务波谷时使用保留实例替换默认的计算型实例,当第一个请求来临时使用保留实例提供服务,同时也会触发默认规格实例的扩容。当默认规格实例扩容完成以后所有新请求就会都转发到默认规格上,同时保留实例则不会接受新的请求,并且等保留实例所有接收到的请求处理完成以后就会被下线。通过这种无缝替换的方式实现了成本和效率的平衡,即降低了常驻实例的成本又不会有显著的冷启动时长。

精准弹性扩缩容

单个 Pod 处理请求的吞吐率有限,如果多个请求转发到同一个 Pod,会导致服务端过载异常,因此需要精准的控制单个 Pod 请求并发处理数。尤其对一些 AIGC 场景下,单个请求会占用较多的 GPU 资源,需要严格的限制每个 Pod 并发处理的请求数。

Knative 与 MSE 云原生网关结合,提供基于并发数精准控制弹性的实现:mpa 弹性插件。

mpa 会从 MSE 网关获取并发数,并计算所需要的 Pod 数进行扩缩容,而 MSE 网关可以做到基于请求精准转发。

配置示例如下:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: mpa.autoscaling.knative.dev
        autoscaling.knative.dev/max-scale: '20'
    spec:
      containerConcurrency: 5
      containers:
      - image: registry-vpc.cn-beijing.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
        env:
        - name: TARGET
          value: "Knative"

参数说明:

参数 说明
autoscaling.knative.dev/class: mpa.autoscaling.knative.dev mpa表明使用MSE指标进行扩缩容,支持缩容到0
autoscaling.knative.dev/max-scale: '20' 扩容Pod数上限是20
containerConcurrency: 5 表示单个Pod能处理的最大并发数是5

弹性预测 AHPA

容器服务 AHPA(Advanced Horizontal Pod Autoscaler)可以根据业务历史指标,自动识别弹性周期并对容量进行预测,解决弹性滞后的问题。

当前 Knative 支持 AHPA(Advanced Horizontal Pod Autoscaler)的弹性能力,当请求具有周期性时,可通过弹性预测,实现预热资源。相比于调低阈值进行资源预热,通过 AHPA 可以最大程度的提升资源利用率。

此外由于 AHPA 支持自定义指标配置,Knative 与 AHPA 结合可以做到基于消息队列以及响应延迟 rt 的自动弹性。

基于 rps 使用 AHPA 配置示例如下:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: autoscale-go
  namespace: default
spec:
  template:
    metadata:
      labels:
        app: autoscale-go
      annotations:
        autoscaling.knative.dev/class: ahpa.autoscaling.knative.dev
        autoscaling.knative.dev/target: "10"
        autoscaling.knative.dev/metric: "rps"
        autoscaling.knative.dev/minScale: "1"
        autoscaling.knative.dev/maxScale: "30"
        autoscaling.alibabacloud.com/scaleStrategy: "observer"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

参数说明:

参数 说明
autoscaling.knative.dev/class: ahpa.autoscaling.knative.dev 指定弹性插件AHPA。
autoscaling.knative.dev/metric: "rps" 设置AHPA指标。目前支持concurrency、rps以及响应时间rt。
autoscaling.knative.dev/target: "10" 设置AHPA指标的阈值,本示例rps阈值为10,表示单个Pod每秒最大处理请求数10。
autoscaling.knative.dev/minScale: "1" 设置弹性策略实例数的最小值为1。
autoscaling.knative.dev/maxScale: "30" 设置弹性策略实例数的最大值为30。
autoscaling.alibabacloud.com/scaleStrategy: "observer" 设置弹性伸缩模式,默认值是observer。 observer: 表示只观察,但不做真正的伸缩动作。您可以通过这种方式观察AHPA的工作是否符合预期。由于预测需要历史7天的数据,因此创建服务默认是observer模式。 auto: 表示由AHPA负责扩容和缩容,把AHPA指标和阈值输入到AHPA,AHPA最终决定是否生效。

小结

本文从 Knative 典型弹性实现 KPA 出发进行介绍,包括如何实现基于请求的自动弹性、缩容到 0、应对突发流量以及我们在 Knative 弹性功能上的扩展增强,包括保留资源池,精准弹性以及弹性预测能力。

这里我们也提供了一个在 AIGC 场景中,使用 Knative 的体验活动,欢迎参与:快来解锁你家萌宠专属 AI 形象!活动时间:2023/08/24-09/24。

快来解锁你家萌宠专属 AI 形象!

https://developer.aliyun.com/adc/series/petsai#J_2264716120

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部