K8s 原生 Serverless 实践:ASK 与 Knative
金三银四马上就到了,希望大家能好好学习一下这些技术点学习视频:《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!” />金三银四马上就到了,希望大家能好好学习一下这些技术点学习视频:[外链图片转存中…(img-XiDVGkhd-1713211395253)]大厂面试真题:[外链图片转存中…(img-0IBHhrHv-1713211395253)]《
以一个简单的场景为例:
- 在 K8s 中实现基于流量的灰度发布
如果要在 K8s 中实现基于流量的灰度发布,需要创建对应的 Service 与 Deployment,弹性相关的需要 HPA 来做,然后在流量灰度发布时,要创建新的版本。
以上图为例,创始版本是 v1,要想实现流量灰度发布,我们需要创建一个新的版本 v2。创建 v2 时,要创建对应的 Service、Deployment、HPA。创建完之后通过 Ingress 设置对应的流量比例,最终实现流量灰度发布的功能。
- 在 Knative 中实现基于流量的灰度发布
如上图所示,在 Knative 中想要实现基于流量的灰度发布,只需要创建一个 Knative Service,然后基于不同的版本进行灰度流量,可以用 Revision1 和 Revision2 来表示。在不同的版本里面,已经包含了自动弹性。
从上面简单的两个图例,我们可以看到在 Knative 中实现流量灰度发布时,需要直接操作的资源明显较少。
- **Service **
Service 对应 Serverless 编排的抽象,通过 Service 管理应用的生命周期。Service 下又包含两大部分:Route 和 Configuration。
- Route
Route 对应路由策略。将请求路由到 Revision,并可以向不同的 Revision 转发不同比例的流量。
- Configuration
Configuration 配置的是相应的资源信息。当前期望状态的配置。每次更新 Service 就会更新 Configuration。
- Revision
每次更新 Configuration 都会相应得到一个快照,这个快照就是 Revision,通过 Revision 实现多版本管理以及灰度发布。
我们可以这样理解:Knative Service ≈ Ingress + Service + Deployment + 弹性(HPA)。
当然,Serverless 框架离不开弹性, Knative 中提供了以下丰富的弹性策略:
-
基于流量请求的自动扩缩容:KPA;
-
基于 CPU、Memory 的自动扩缩容:HPA;
-
支持定时 + HPA 的自动扩缩容策略;
-
事件网关(基于流量请求的精准弹性)。
=======================================================================================
如果要准备 ECI 资源的话,需要提前进行容量规划,这无疑违背了 Serverless 的初衷。为摆脱 ECI 资源的束缚,不必提前进行 ECI 资源规划,阿里云提出了无服务器 Serverless——ASK。用户无需购买节点,即可直接部署容器应用,无需对节点进行维护和容量规划。ASK 提供了 K8s 兼容的能力,同时极大地降低了 K8s 的使用门槛,让用户专注于应用程序,而不是底层基础设施。
ASK 提供了以下能力:
- 免运维
开箱即用,无节点管理和运维,无节点安全维护,无节点 NotReady,简化 K8s 集群管理。
- 极致的弹性扩容
无容量规划,秒级扩容,30s 500pod。
- 低成本
按需创建 Pod,支持 Spot,预留实例券。
- 兼容 K8s
支持 Deployment/statfulset/job/service/ingress/crd 等。
- 存储挂载
支持挂载云盘、NAS、OSS 存储券。
- Knative on ASK
基于应用流量的自动弹性,开箱即用,缩容到最小规格。
- Elastic Workload
支持 ECI 按量和 Spot 混合调度。
- 集成 ARMS/SLS 等云产品
Knative 运维主要存在三个方面的问题:Gateway、Knative 管控组件和冷启动问题。
如上图所示,在 Knative 中管控组件会涉及到相应的 Activator,它是从 0 到 1 的一个组件;Autoscaler 是扩缩容相关的组件;Controller 是自身的管控组件以及网关。对于这些组件的运维,如果放在用户层面做,无疑会加重负担,同时这些组件还会占用成本。
除此之外,从 0 到 1 的冷启动问题也需要考虑。当应用请求过来时,第一个资源从开始到启动完成需要一段时间,这段时间内的请求如果响应不及时的话,会造成请求超时,进而带来冷启动问题。
对于上面说到的这些问题,我们可以通过 ASK 来解决。下面看下 ASK 是如何做的?
相比于之前 Istio 提供的能力,我们需要运营管控 Istio 相关的组件,这无疑加大了管控成本。实际上对于大部分场景来说,我们更关心网关的能力,Istio 本身的一些服务(比如服务网格)我们其实并不需要。
在 ASK 中,我们将网关这一层通过 SLB 进行了替换:
-
降成本:减少了十几个组件,大大降低运维成本和 IaaS 成本;
-
更稳定:SLB 云产品服务更稳定,可靠性更高,易用性也更好。
对于 Knative 管控组件,ASK 做了一些托管:
-
开箱即用:用户直接使用 Serverless Framework,不需要自己安装;
-
免运维、低成本:Knative 组件和 K8s 集群进行融合,用户没有运维负担,也无需承担额外的资源成本;
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)
最后
金三银四马上就到了,希望大家能好好学习一下这些技术点
学习视频:
大厂面试真题:
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
style=“zoom: 33%;” />
最后
金三银四马上就到了,希望大家能好好学习一下这些技术点
学习视频:
[外链图片转存中…(img-XiDVGkhd-1713211395253)]
大厂面试真题:
[外链图片转存中…(img-0IBHhrHv-1713211395253)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
更多推荐
所有评论(0)