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 数*最大并发数-突发请求容量-恐慌模式计算出来的并发数
减少冷启动的一些技巧
延迟缩容
对于启动成本较高的 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。 |
http://autoscaling.alibabacloud.com/scaleStrategy: “observer” | 设置弹性伸缩模式,默认值是observer。observer:表示只观察,但不做真正的伸缩动作。您可以通过这种方式观察AHPA的工作是否符合预期。由于预测需要历史7天的数据,因此创建服务默认是observer模式。auto:表示由AHPA负责扩容和缩容,把AHPA指标和阈值输入到AHPA,AHPA最终决定是否生效。 |
-
ta-draft-node=”block” data-draft-type=”table” data-size=”normal” data-row-style=”normal”>
参数 说明 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。 http://autoscaling.alibabacloud.com/scaleStrategy: “observer” 设置弹性伸缩模式,默认值是observer。observer:表示只观察,但不做真正的伸缩动作。您可以通过这种方式观察AHPA的工作是否符合预期。由于预测需要历史7天的数据,因此创建服务默认是observer模式。auto:表示由AHPA负责扩容和缩容,把AHPA指标和阈值输入到AHPA,AHPA最终决定是否生效。 - e data-draft-node=”block” data-draft-type=”table” data-size=”normal” data-row-style=”normal”>
小结
本文从 Knative 典型弹性实现 KPA 出发进行介绍,包括如何实现基于请求的自动弹性、缩容到 0、应对突发流量以及我们在 Knative 弹性功能上的扩展增强,包括保留资源池,精准弹性以及弹性预测能力。
作者:元毅
点击立即免费试用云产品 开启云上实践之旅!
原文链接
本文为阿里云原创内容,未经允许不得转载。