如何将AI能力与大数据技术结合,助力数据分析治理等工作的效率大幅提升,优化大数据引擎的性能及成本? 了解详情
写点什么

Knative 基本功能深入剖析:Knative Serving 自动扩缩容 Autoscaler

  • 2019-08-12
  • 本文字数:3800 字

    阅读完需:约 12 分钟

Knative 基本功能深入剖析:Knative Serving 自动扩缩容 Autoscaler

Knative Serving 默认情况下,提供了开箱即用的快速、基于请求的自动扩缩容功能 - Knative Pod Autoscaler(KPA)。下面带你体验如何在 Knative 中玩转 Autoscaler。


Autoscaler 机制

Knative Serving 为每个 POD 注入 QUEUE 代理容器 (queue-proxy),该容器负责向 Autoscaler 报告用户容器并发指标。Autoscaler 接收到这些指标之后,会根据并发请求数及相应的算法,调整 Deployment 的 POD 数量,从而实现自动扩缩容。



算法

Autoscaler 基于每个 POD 的平均请求数(并发数)进行扩所容处理。默认并发数为 100。


POD 数=并发请求总数/容器并发数


如果服务中并发数设置了 10,这时候如果加载了 50 个并发请求的服务,Autoscaler 就会创建了 5 个 POD (50 个并发请求/10=POD)。


Autoscaler 实现了两种操作模式的缩放算法:Stable(稳定模式)和 Panic(恐慌模式)。


稳定模式


在稳定模式下,Autoscaler 调整 Deployment 的大小,以实现每个 POD 所需的平均并发数。 POD 的并发数是根据 60 秒窗口内接收所有数据请求的平均数来计算得出。


恐慌模式


Autoscaler 计算 60 秒窗口内的平均并发数,系统需要 1 分钟稳定在所需的并发级别。但是,Autoscaler 也会计算 6 秒的恐慌窗口,如果该窗口达到目标并发的 2 倍,则会进入恐慌模式。在恐慌模式下,Autoscaler 在更短、更敏感的紧急窗口上工作。一旦紧急情况持续 60 秒后,Autoscaler 将返回初始的 60 秒稳定窗口。


|                                  Panic Target--->  +--| 20                                                    |  |                                                    | <------Panic Window                                                    |  |       Stable Target--->  +-------------------------|--| 10   CONCURRENCY                          |                         |  |                          |                      <-----------Stable Window                          |                         |  |--------------------------+-------------------------+--+ 0120                       60                           0                     TIME
复制代码


配置 KPA

通过上面的介绍,我们对 Knative Pod Autoscaler 工作机制有了初步的了解,那么接下来介绍如何配置 KPA。在 Knative 中配置 KPA 信息,需要修改 k8s 中的 ConfigMap:config-autoscaler,该 ConfigMap 在 knative-serving 命名空间下。查看 config-autoscaler 使用如下命令:


kubectl -n knative-serving get cm config-autoscaler
复制代码


默认的 ConfigMap 如下:


apiVersion: v1kind: ConfigMapmetadata: name: config-autoscaler namespace: knative-servingdata: container-concurrency-target-default: 100 container-concurrency-target-percentage: 1.0 enable-scale-to-zero: true enable-vertical-pod-autoscaling: false max-scale-up-rate: 10 panic-window: 6s scale-to-zero-grace-period: 30s stable-window: 60s tick-interval: 2s
复制代码


为 KPA 配置缩容至 0

为了正确配置使 Revision 缩容为 0,需要修改 ConfigMap 中的如下参数。


scale-to-zero-grace-period


scale-to-zero-grace-period 表示在缩为 0 之前,inactive revison 保留的运行时间(最小是 3 0s)。


scale-to-zero-grace-period: 30s
复制代码


stable-window


当在 stable mode 模式运行中,autoscaler 在稳定窗口期下平均并发数下的操作。


stable-window: 60s
复制代码


stable-window 同样可以配置在 Revision 注释中。


autoscaling.knative.dev/window: 60s
复制代码


enable-scale-to-zero


保证 enable-scale-to-zero 参数设置为 true


Termination period


Termination period(终止时间)是 POD 在最后一个请求完成后关闭的时间。POD 的终止周期等于稳定窗口值和缩放至零宽限期参数的总和。在本例中,Termination period 为 90 秒。


配置并发数

可以使用以下方法配置 Autoscaler 的并发数:


target


target 定义在给定时间(软限制)需要多少并发请求,是 Knative 中 Autoscaler 的推荐配置。


在 ConfigMap 中默认配置的并发 target 为 100。


`container-concurrency-target-default: 100`
复制代码


这个值可以通过 Revision 中的 autoscaling.knative.dev/target 注释进行修改:


autoscaling.knative.dev/target: 50
复制代码


containerConcurrency


注意:只有在明确需要限制在给定时间有多少请求到达应用程序时,才应该使用 containerConcurrency (容器并发)。只有当应用程序需要强制的并发约束时,才建议使用 containerConcurrency。


containerConcurrency 限制在给定时间允许并发请求的数量(硬限制),并在 Revision 模板中配置。


containerConcurrency: 0 | 1 | 2-N
复制代码


  • 1: 将确保一次只有一个请求由 Revision 给定的容器实例处理;

  • 2-N: 请求的并发值限制为 2 或更多;

  • 0: 表示不作限制,有系统自身决定。


配置扩缩容边界(minScale 和 maxScale)


通过 minScale 和 maxScale 可以配置应用程序提供服务的最小和最大 Pod 数量。通过这两个参数配置可以控制服务冷启动或者控制计算成本。


minScale 和 maxScale 可以在 Revision 模板中按照以下方式进行配置:


spec:  template:    metadata:      autoscaling.knative.dev/minScale: "2"      autoscaling.knative.dev/maxScale: "10"
复制代码


通过在 Revision 模板中修改这些参数,将会影响到 PodAutoscaler 对象,这也表明在无需修改 Knative Serving 系统配置的情况下,PodAutoscaler 对象是可被修改的。


edit podautoscaler <revision-name>
复制代码


注意:这些注释适用于 Revision 的整个生命周期。即使 Revision 没有被任何 route 引用,minscale 指定的最小 POD 计数仍将提供。请记住,不可路由的 Revision 可能被垃圾收集掉。


默认情况

如果未设置 minscale 注释,pods 将缩放为零(如果根据上面提到的 configmap,enable-scale-to-zero 为 false,则缩放为 1)。


如果未设置 maxscale 注释,则创建的 Pod 数量将没有上限。


基于 KPA 配置的示例

Knative 0.7 版本部署安装可以参考:阿里云部署 Knative


我们使用官方提供的 autoscale-go 示例来进行演示,示例 service.yaml 如下:


apiVersion: serving.knative.dev/v1alpha1kind: Servicemetadata:  name: autoscale-go  namespace: defaultspec:  template:    metadata:      labels:        app: autoscale-go      annotations:        autoscaling.knative.dev/target: "10"    spec:      containers:        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1
复制代码


获取访问网关:


$ kubectl get svc istio-ingressgateway --namespace istio-system --output jsonpath="{.status.loadBalancer.ingress[*]['ip']}"121.199.194.150
复制代码


Knative 0.7 版本中获取域名信息:


$ kubectl get route autoscale-go --output jsonpath="{.status.url}"| awk -F/ '{print $3}'autoscale-go.default.example.com
复制代码


场景 1:并发请求示例

如上配置,当前最大并发请求数 10。 我们执行 30s 内保持 50 个并发请求,看一下执行情况:


hey -z 30s -c 50   -host "autoscale-go.default.example.com"   "http://121.199.194.150?sleep=100&prime=10000&bloat=5"
复制代码



结果正如我们所预期的:扩容出来了 5 个 POD。


场景 2:扩缩容边界示例

修改一下 servcie.yaml 配置如下:


apiVersion: serving.knative.dev/v1alpha1kind: Servicemetadata:  name: autoscale-go  namespace: defaultspec:  template:    metadata:      labels:        app: autoscale-go      annotations:        autoscaling.knative.dev/target: "10"        autoscaling.knative.dev/minScale: "1"        autoscaling.knative.dev/maxScale: "3"        spec:      containers:        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1
复制代码


当前最大并发请求数 10,minScale 最小保留实例数为 1,maxScale 最大扩容实例数为 3。


我们依然执行 30s 内保持 50 个并发请求,看一下执行情况:


hey -z 30s -c 50   -host "autoscale-go.default.example.com"   "http://121.199.194.150?sleep=100&prime=10000&bloat=5"
复制代码



结果如我们所预期:最多扩容出来了 3 个 POD,并且即使在无访问请求流量的情况下,保持了 1 个运行的 POD。


结论

看了上面的介绍,是不是感觉在 Knative 中配置应用扩缩容是如此简单?其实 Knative 中除了支持 KPA 之外,也支持 K8s HPA。你可以通过如下配置基于 CPU 的 Horizontal POD Autoscaler(HPA)。


通过在修订模板中添加或修改 autoscaling.knative.dev/class 和 autoscaling.knative.dev/metric 值作为注释,可以将 Knative 配置为使用基于 CPU 的自动缩放,而不是默认的基于请求的度量。配置如下:


spec:  template:    metadata:      autoscaling.knative.dev/metric: concurrency      autoscaling.knative.dev/class: hpa.autoscaling.knative.dev
复制代码


你可以自由的将 Knative Autoscaling 配置为使用默认的 KPA 或 Horizontal POD Autoscaler(HPA)。


相关文章:


《初识 Knative:跨平台的 Serverless 编排框架》


《Knative 初体验:Serving Hello World》


《Knative 初体验:Eventing Hello World》


《Knative 初体验:Build Hello World》


《Knative 初体验:CI/CD 极速入门》


《Knative 基本功能深入剖析:Knative Serving 的流量灰度和版本管理》


2019-08-12 08:508091
用户头像
阿里云容器平台 ACK,企业云原生转型最佳搭档

发布了 43 篇内容, 共 20.7 次阅读, 收获喜欢 78 次。

关注

评论

发布
暂无评论
发现更多内容

CODING 助力推进腾讯游戏国际化进程

CODING DevOps

DevOps 开发工具 腾讯游戏 软件研发

Java 8 新特性

Bf-Bus

辞职1000小时后,我走进字节跳动拿了offer

Java 程序员 面试 java编程

全网首发!“阿里爸爸”最新出品SpringBoot高级笔记(内部笔记!)

Java spring

模块一作业:微信业务架构图和毕设架构设计

Felix

[架构实战营][模块一作业]

KK_TTN

#架构实战营

关于数据安全

奔向架构师

大数据 数据安全

中层管理者挖掘需求的七大法宝

石云升

读书笔记 需求 职场经验 管理经验 7月日更

面试官问的那些Android原理你都懂吗?值得一看

欢喜学安卓

android 程序员 面试 移动开发

就是它,帮我斩获了8家大厂offer,由于太全被各大厂要求Github连夜下架

Java架构师迁哥

数字货币大趋势,DC EP出征,带老百姓进入新时代!

CECBC

云计算还有多久能够替代高性能计算?

北鲲云

5分钟速读之Rust权威指南(三十六)模式匹配

码生笔谈

rust

为了对抗内卷,我“偷”了阿里两份笔记:JDK源码+Java并发图册

Java架构师迁哥

数据安全法下,企业如何平衡数据安全合规与业务性能?

腾讯安全云鼎实验室

数据安全 数据安全法

算法面试通关

buchila11

面试

RedHat7.2 切换yum源记录

Bruce Xiong

redhat yum源

重磅!不容错过的阿里内部微服务速成手册也太赞了(2021版)

Java 程序员 面试 java编程

人民网发文:区块链如何跨越未来10年

CECBC

一叶红船见百年!百度大脑助力南湖红船泛起国人心中红色情怀

百度大脑

第一周作业

Morphling

#架构实战营

面试官问的那些Android原理你都懂吗?快来收藏!

欢喜学安卓

android 程序员 面试 移动开发

区块链互操作性:大规模应用的关键

CECBC

InnoDB存储引擎-锁

CodeWithBuff

MySQL innodb

自制深度学习照片数据集

re-执着

《持之以恒的从事运动》三

Changing Lin

当法律纽带变成“机器红线”,能让自动驾驶汽车更安全吗?

脑极体

数据准备的能力,决定企业AI研发的边界

百度大脑

人工智能

程序员外包避坑指南?

孙叫兽

程序员 外包

模块一作业

lhp

架构实战营

Knative 基本功能深入剖析:Knative Serving 自动扩缩容 Autoscaler_语言 & 开发_阿里云容器平台_InfoQ精选文章