Knative 冷启动|学习笔记

本文涉及的产品
函数计算FC,每月15万CU 3个月
简介: 快速学习Knative 冷启动

开发者学堂课程【通过 Knative 轻松实现应用 Serverless 化交付Knative 冷启动】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/753/detail/13227


Knative 冷启动

 

内容介绍:

一、上期回顾

二、 什么是冷启动

三、Knative 01的冷启动机制

四、当前冷启动的存在哪些问题

五、阿里云突发性能实例

六、通过保留实例解决冷启动

七、示例演示

八、总结

 

一、上期回顾

Knative 极致 Serverless 体验

1.为什么需要 Knative

// Knative 是在提供通用的编排调度服务,给上层的 Serverless 提供面向应用层的原子操作,并且通过 Knative 原生 API 暴露服务的 API ,保持和 Knative 生态攻击链的完美融合。

2.Knative Serving

// Knative Serving 介绍了 Serving 的应用模型 Serves,并且通过将 Knative Serving 的组建全托管,来降低用户的 IaaS 成本以及运维负担。

3.Knative 和云的结合

//介绍了 SLB 网关,Knative 社区默认支持 auloscalor 等多种 gateway 的实现,但是这些常驻网关实际的 IaaS 费用和运维需要支付额外的成本,为了给用户提供极致的体验,通过阿里云 SLB 实现了 Knative gateway 。不需要常驻实力,不但节省了 IaaS 成本,还省去了很多运维的负担,另外也介绍了保留实力,保留实力是IaaSk Knative 独有的功能,社区的 Knative 在默认没有流量的情况下,可以缩用到零,但是缩用到零之后,零到一的冷启动问题很难解决,Knative 对于这个的解法是通过低价格的保留实力,来平衡成本和冷启动问题,这也是今天详细介绍的内容。

 

二、  什么是冷启动

image.png

Serverless 核心是按需使用,在请求到来时才运行服务。这意味着,当没有请求时,服务会进入休眠状态,下次当请求到来时,服务需要一个启动时间,即冷启动。

//从图表可以直观的看出:首先请求逐渐减少,IaaS 资源也在逐渐减少,当请求为零的时候进去一种休眠状态,这时候不需要任何资源,当有请求进来的时候,会接受请求进去扩容,等第一个资源 ready 之后,才开始真正处理服务,从接受请求到第一个资源 ready 之后,进去一个冷启动时间。

 

三、Knative 01的冷启动机制

image.png

Activator:

·接收流量请求

·通知 Autoscaler 扩容

·转发流量到 Ready Pod

//可以通过图片看到,这里包括几个关键的组件,首先是 Ingress GW,另外是ActivatorAutoscaler,以及 RevisionIngress GW 充当请求的角色,请求通过Ingress GW 发送给 ActivatorActivator 进入到零到一的请求,把请求的数据通知给AutoscalerAutoscaler 进入到请求的数据后,计算需要扩容多少,然后修改Deployment 相应的数量,创建相应请求的Pod。在这个过程中,Autoscaler 会不断探测 Pod ready,一但 Pod ready 将请求转化到已经 ready Pod 中,这个过程就完成了零到一的启动过程,后续的请求直接通过 Ingress GW 转发到相应的Pod 上,整个过程下来 Ingress GW 扮演了冷启动的角色,接受请求,通知Autoscaler 进行扩容,最后转发流量到 Ready Pod 上。

 

四、当前冷启动的存在哪些问题

image.png

·链路过长,请求延迟

·Pod 启动耗时长

//Knative 在默认没有流量的情况下,可以缩用到零,传统应用在流量低谷的时候,即使没有业务处理,还是会保持不变,这其实是资源浪费,但优点是对请求随时响应,而缩用到零,第一个请求到达以后才会触发的过程,Knative 中的模型从零到一扩容需要四个步骤串行处理,这四个步骤完成之后才会响应第一个请求,此外,LaaS 资源的分配,综合这些因素,往往导致第一个请求超时,所以 Knative 缩用到零虽然降低了常驻资源的成本,但第一批冷启动问题也比较明显,可以从图片直观的看到,当请求到达 gateway 之后,可以转到 Activatorautoscaler 通知相应的 Pod 进行扩容,扩容完成之后 Activator 才会转化流量。另外,Pod 启动耗时长。

 

五、阿里云突发性能实例

如下所示是对2c4G 配置的计算型实例和突发性能型实例的价格对比:

规格族

实例规格

VCPU

内存

参考价格元/

计算型c5

ecs.c5.large

2 vCPU

4 GiB

0.62

突发性能实例t5

ecs.t5-lc1m2large

2 vCPU

4 GiB

0.333

计算型c6

ecs.c6.large

2 vCPU

4 GiB

0.39

突发性能实例t6

ecst6-c1m2large

2 vCPU

4 GiB

0.236

image.png

//阿里云中有不同规格,不同规格价格不一样,如图所示,是对2c4G 配置的计算型实例和突发性能型实例的价格对比,通过实例知道突发性能型比计算型便宜,可见没有流量的情况下使用突发性能实例不单单解决了冷启动的问题,还能节省资源成本。突发性能实例除了价格优势外,还有一个非常实用的功能就是 cpu  积分,突发性能实例可以利用 cpu 积分应对突发性能需求,在突发性能实例中持续获得 cpu积分,在性能无法满足负载时,通过消耗累积的 cpu 积分,来提高计算性能,不会影响在实际上的服务。例外,通过 cpu 积分,可以从业务整体角度分别计算资源,将业务低峰期的计算能力无缝嵌入高峰期。

 

六、通过保留实例解决冷启动

image.png

·免冷启动:通过保留实例消除了从0130秒冷启动时间

·成本可控:突发性能实例成本比标准规格实例降低40%的成本,如果和 Spot 实例突发性能实例结合还能再进一步降低成本

//为了解决零到一的冷启动问题,推出了保留实例的能力,保留实例是阿里云Knative 同期服务独有的功能,像上面提到的 Knative 没有流量的情况下,缩用到零,之后从零到一的冷启动问题很难解决,应用市场从毫秒到分钟都是有的,应用启动的这些时间完全是是业务行为,在底层平台是无法控制的。Knative 对这个的解法就是符合低价值的保留实力来平衡成本问题的问题。当第一个请求来临时,签订的切换的标准的计算与处理,这样可以当帮助你降低流量低控制的分类。低谷时获得的 cpu 积分可以在高峰期消耗掉。另外,使用突发性能保留实例只是默认策略,可以通过制定其他实例保留实例的规格。从这个图刻意直观的看到,随着业务量的降低,会逐渐缩容,在没有业务量的时候,并没有把它缩容到零,而缩容到了一个保留实例上。当新的请求进来之后,是通过保留实力响应业务实例,业务的请求。同时会扩容,正常的实例出来,当正常的实例扩容出来 ready 之后,就说无缝下线掉,保留实力,从而解决冷启动问题。这里可以概括两点,首先,免冷启动:通过保留实例消除了从0130秒冷启动时间。另外,成本可控:突发性能实例成本比标准规格实例降低40%的成本,如果和 Spot 实例突发性能实例结合还能再进一步降低成本。

 

七、示例演示

·社区 Knative 01冷启动

image.png

·ASK Knative 保留实例冷启动

image.png

//接下来,分别演示下社区的 Knative 零到一的冷启动,以及通过保留实例在 ASK Knative 中的冷启动。通过二者的对比,可以做个直观的感受。下面打开相应的控制台,可以看一下,其实部署的是一个简单的 coffee 服务,在上一期呢,其实也介绍到,它就是一个很简单的一个 hello coffee。来看一下,这个是左侧使用的是ASK Knative,然后右侧使用的是社区的 Knative。二者的打印信息都是一样的,可以看一下,最直观的可以看一下在 ASK 托管的 Knative 是不需要管控端相应的组建的,首先呢,可以在 Knative Serving 中,是没有任何 Pod 的,而社区的Knative,也是在相应的 Serving 空间下,需要提供相应的管控组建的,这也是上面提到的 ASK Knative 中对于 Knative Serving 相应组件做出全托管免运维的一个变化。接下来部署相应的服务,首先,可以在社区的Knative中部署相应的服务,可以观察当前 pod 的情况,同时在 ASK Knative 中创建相同的 coffee,同样可以观察当前 pod 的情况,看到 ASk Knative 中,Pod 也在创建中,在社区的 Knative 中,Pod 已经创建完成,接下来观察的一个现象就是没有请求的过程中,社区的Knative 会缩用到零,在 ASK Knative 中,正常的缩容周期是九十秒,可以看到社区的 Knative 已经缩用到零。在这个过程中,可以整理访问请求,重新打开另外一个窗口,另外观察到在 ASK Knative 中相应的创建保留实例,一但这个保留实例ready,就会把正常的实例下线掉。同样的看另外的窗口,可以看到在没有请求的时候,Knative 已经缩容到保留实例。接下来,分别进行访问,看下实际的访问效果。首先,访问社区 Knative,可以看到社区 Knative 一旦接触,就会创建相应的Pod ,启动 Pod 的时间大概需要30秒。在这个过程中,可以通过访问保留实例,可以很明显的对比出来社区的 Knative 有将近30秒的时间,才响应请求,而在 ASK提供的 Knative 几乎是实时响应,一旦正常实例 ready 之后,就会把保留实例响应掉,通过这个对比,知道如何在 ASK 中保留实例,解决冷启动问题。对于服务敏感型的,可以通过这种方式,请求的实时响应。

 

八、总结

//首先当前社区 Knative 01冷启动问题做了介绍,另外使用保留实例平衡成本和冷启动。下一期,会介绍 Knative 灰度发布和自动扩缩容。

 

 

相关实践学习
【文生图】一键部署Stable Diffusion基于函数计算
本实验教你如何在函数计算FC上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。函数计算提供一定的免费额度供用户使用。本实验答疑钉钉群:29290019867
建立 Serverless 思维
本课程包括: Serverless 应用引擎的概念, 为开发者带来的实际价值, 以及让您了解常见的 Serverless 架构模式
目录
打赏
0
0
0
0
215
分享
相关文章
基于Knative的LLM推理场景弹性伸缩方案
Knative的基于请求弹性配置与大语言模型(LLM)的推理场景高度契合。此外,它的资源降配特性可以显著帮助用户降低成本。本文详细介绍基于 Knative 的 LLM 推理场景弹性伸缩方案。
Knative 实战:基于 Knative Serverless 技术实现天气服务-下篇
Knative 实战:基于 Knative Serverless 技术实现天气服务-下篇

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等