旺旺号查询网站怎么做,有模版之后怎么做网站,颜色搭配的网站,余姚网站建设的公司作者#xff1a;元毅
Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架#xff0c;其目标是制定云原生、跨平台的 Serverless 应用编排标准。Knative 主要功能包括基于请求的自动弹性、缩容到 0、多版本管理、基于流量的灰度发布以及事件驱动等。
弹性是 Ser…作者元毅
Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架其目标是制定云原生、跨平台的 Serverless 应用编排标准。Knative 主要功能包括基于请求的自动弹性、缩容到 0、多版本管理、基于流量的灰度发布以及事件驱动等。
弹性是 Serverless 中的核心能力那么 Knative 作为 CNCF 社区最受欢迎的开源 Serverless 应用框架提供了哪些与众不同的弹性能力呢本文将带你深入了解 Knative 的弹性实现。 说明本文基于 Knative 1.8.0 版本进行分析
Knative 提供了基于请求的自动弹性实现 KPAKnative 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 的概念称之为目标使用率取值范围 01默认是 :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取值是 01默认是 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-gonamespace: default
spec:template:metadata:annotations:autoscaling.knative.dev/scale-down-delay: 60sautoscaling.knative.dev/scale-to-zero-pod-retention-period: 1m5sspec: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-gonamespace: default
spec:template:metadata:annotations:autoscaling.knative.dev/target-utilization-percentage: 70spec:containers:- image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56配置 KPA
通过上面的介绍我们对 Knative Pod Autoscaler 工作机制有了进一步的了解那么接下来介绍如何配置 KPA。Knative 中配置 KPA 提供了两种方式全局模式和 Revision 模式。
全局模式
全局模式可以修改 K8s 中的 ConfigMapconfig-autoscaler查看 config-autoscaler 使用如下命令
kubectl -n knative-serving get cm config-autoscalerapiVersion: v1
kind: ConfigMap
metadata:name: config-autoscalernamespace: knative-serving
data:container-concurrency-target-default: 100container-concurrency-target-percentage: 70requests-per-second-target-default: 200target-burst-capacity: 211stable-window: 60spanic-window-percentage: 10.0panic-threshold-percentage: 200.0max-scale-up-rate: 1000.0max-scale-down-rate: 2.0enable-scale-to-zero: truescale-to-zero-grace-period: 30sscale-to-zero-pod-retention-period: 0spod-autoscaler-class: kpa.autoscaling.knative.devactivator-capacity: 100.0initial-scale: 1allow-zero-initial-scale: falsemin-scale: 0max-scale: 0scale-down-delay: 0s参数说明
参数说明container-concurrency-target-default默认Pod最大并发数默认值100container-concurrency-target-percentage并发数目标使用率70实际表示0.7requests-per-second-target-default默认每秒请求数rps,默认值200target-burst-capacity突发请求容量stable-window稳定窗口默认60spanic-window-percentage恐慌窗口比例默认值为10则表示默认恐慌窗口期为6秒60*0.16panic-threshold-percentage恐慌阈值比例默认值200max-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默认30sscale-to-zero-pod-retention-periodpod缩容到0保留期该参数适用于Pod启动成本较高的情况pod-autoscaler-class弹性插件类型当前支持的弹性插件包括kpa、hpa、ahpa以及mpa(ask场景下配合mse支持缩容到 0)activator-capacityactivator请求容量initial-scale创建revision时初始化启动的Pod数默认1allow-zero-initial-scale是否允许创建revision时初始化0个Pod 默认false,表示不允许min-scalerevision级别最小保留的Pod数量。默认0表示最小值可以为0max-scalerevision级别最大扩容的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-gonamespace: default
spec:template:metadata:annotations:autoscaling.knative.dev/metric: concurrencyautoscaling.knative.dev/target: 50autoscaling.knative.dev/scale-to-zero-pod-retention-period: 1m5sautoscaling.knative.dev/target-utilization-percentage: 80对 HPA 的支持
对于 K8s HPA Knative 也提供天然的配置支持可以在 Knative 使用基于 CPU 或者 Memory 的自动弹性能力。
基于 CPU 弹性配置 apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: helloworld-gonamespace: default
spec:template:metadata:annotations:autoscaling.knative.dev/class: hpa.autoscaling.knative.devautoscaling.knative.dev/metric: cpu基于 Memory 的弹性配置 apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: helloworld-gonamespace: default
spec:template:metadata:annotations:autoscaling.knative.dev/class: hpa.autoscaling.knative.devautoscaling.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.devautoscaling.knative.dev/max-scale: 20spec:containerConcurrency: 5containers:- image: registry-vpc.cn-beijing.aliyuncs.com/knative-sample/helloworld-go:73fbdd56env:- name: TARGETvalue: Knative参数说明
参数说明autoscaling.knative.dev/class: mpa.autoscaling.knative.devmpa表明使用MSE指标进行扩缩容支持缩容到0autoscaling.knative.dev/max-scale: ‘20’扩容Pod数上限是20containerConcurrency: 5表示单个Pod能处理的最大并发数是5
弹性预测 AHPA
容器服务 AHPAAdvanced Horizontal Pod Autoscaler可以根据业务历史指标自动识别弹性周期并对容量进行预测解决弹性滞后的问题。
当前 Knative 支持 AHPAAdvanced Horizontal Pod Autoscaler的弹性能力当请求具有周期性时可通过弹性预测实现预热资源。相比于调低阈值进行资源预热通过 AHPA 可以最大程度的提升资源利用率。 此外由于 AHPA 支持自定义指标配置Knative 与 AHPA 结合可以做到基于消息队列以及响应延迟 rt 的自动弹性。
基于 rps 使用 AHPA 配置示例如下
apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: autoscale-gonamespace: default
spec:template:metadata:labels:app: autoscale-goannotations:autoscaling.knative.dev/class: ahpa.autoscaling.knative.devautoscaling.knative.dev/target: 10autoscaling.knative.dev/metric: rpsautoscaling.knative.dev/minScale: 1autoscaling.knative.dev/maxScale: 30autoscaling.alibabacloud.com/scaleStrategy: observerspec: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指标和阈值输入到AHPAAHPA最终决定是否生效。
小结
本文从 Knative 典型弹性实现 KPA 出发进行介绍包括如何实现基于请求的自动弹性、缩容到 0、应对突发流量以及我们在 Knative 弹性功能上的扩展增强包括保留资源池精准弹性以及弹性预测能力。
这里我们也提供了一个在 AIGC 场景中使用 Knative 的体验活动欢迎参与快来解锁你家萌宠专属 AI 形象活动时间2023/08/24-09/24。 快来解锁你家萌宠专属 AI 形象 https://developer.aliyun.com/adc/series/petsai#J_2264716120
