k8s 原生Serverless 实践:ASK 与 Knative

简介: 随着云计算技术的发展,云资源交付变的越来越简单,按需使用已经成为可能。在按需使用资源的模式下,用户更多的聚焦于业务自身,而减少了对基础设施的关注,Serverless 理念也因此应运而生。Knative 在 K8s 之上又做了进一步的简化,大大降低了应用生命周期管控复杂度,同时提供了自动弹性和灰度发布等能力,同时基于阿里云 Severless Kubernetes (ASK)提供的极致容器化 Serverless,给您带来云原生 Serverless 应用完全体。


导读

随着云计算技术的发展,云资源交付变的越来越简单,按需使用已经成为可能。在按需使用资源的模式下,用户更多的聚焦于业务自身,而减少了对基础设施的关注,Serverless 理念也因此应运而生。我们知道 Kubernetes 已成为当今云原生业界标准,具备良好的生态以及跨云厂商能力。Kubernetes 很好的抽象了 IaaS 资源交付的标准, 但如果想要在 Kubernetes 之上以 Severless 的方式管理应用还是要做很多事情的。Knative 在 K8s 之上又做了进一步的简化,大大降低了应用生命周期管控复杂度,同时提供了自动弹性和灰度发布等能力,同时基于阿里云 Severless Kubernetes (ASK)提供的极致容器化 Serverless,给您带来云原生 Serverless 应用完全体。本文会从如下 4 部分内容展开介绍:

  • 为什么需要 Knative
  • Knative 简介
  • Knative 和 ASK 融合
  • 演示示例

为什么需要Knative

我们知道当前K8s 已经成为了云原生事实上的操作系统,Kubernetes 对上通过数据抽象暴露基础设施能力,比如 Service、Ingress、Pod、Deployment,这些都是通过 Kubernetes 原生 API 给用户暴露出来的能力。而对下,Kubernetes 提供了基础设施能力接入的标准接口,比如说 CNI、CRD,让云资源以一个标准化的方式接入到 Kubernetes 的体系中。今天我们来看 Kubernetes 所处的位置,实际上是承上启下。云原生的用户使用 Kubernetes 的目的,都是为了交付和管理应用,当然也包括灰度发布、扩容缩容等,并且兼顾资源成本。

image.png

但我们实际在使用Kubernetes过程中, 逐渐会发现如下问题:

  • 通过 k8s API 实现服务全生命周期管理比较复杂
  • IaaS 资源规格繁杂,每一种规格适用场景都所有不同,用户很难自己组合所有规格
  • 节省资源使用成本,弹性越来越重要

那么如何才能简单的使用容器(K8s)技术?如何随心所欲的实现按需使用,降低成本?答案就是:Knative

image.png

Knative

降本


Knative 简介

image.png

K

es-basedplatformtobuild,deploy

andmanagemodernserverle

es平台,用于构建,部

基于Kubernetes

管理现代Serverless工作负载

Knative是在 2018 Google Cloud Next 大会上发布的一款基于Kubernetes Serverless编排引擎Knative一个很重要的目标就是制定云原生、跨平台的Serverless编排标准。Knative是通过整合容器构建(或者函数)、工作负载管理(弹性)以及事件模型这三者来实现的这一Serverless标准。Knative社区的当前主要贡献者有GooglePivotalIBMRed Hat。另外像 CloudFoundryOpenShift这些 PAAS 提供商都在积极的参与Knative的建设。

Knative 核心模块

image.png

Knative 核心模块主要包括事件驱动框架 Eventing 和部署工作负载的Serving。

Serverless服务引擎 - Serving

Knative Serving 核心能力就是其简洁、高效的应用托管服务,这也是其支撑Serverless能力的基础。当然作为SeverlesssFramework 就离不开按需分配资源的能力,Knative 可以根据您应用的请求量在高峰时期自动扩容实例数,当请求量减少以后自动缩容实例数,可以非常自动化的帮助您节省成本。Serving 还提供了的流量管理能力和灵活的灰度发布能力。流量管理能力可以根据百分比切分流量,灰度发布能力可以根据流量百分比进行灰度。

一个简单的场景:基于流量灰度发布

我们以一个简单的流量灰度发布为例,先看一下在k8s中如何实现。

我们创建一个提供外部访问的服务,在 K8s 中需要创建如下资源:

  • Deployment: 部署应用的工作负载
  • Service: 提供服务访问以及负载均衡的能力
  • Ingress: 对外提供域名访问的功能
  • HPA:我们实现按照负载(cpu、memory)自动弹性,需要创建HPA。


初始的时候,通过V1提供服务,这时候如果要灰度新的版本,那么需要创建对应资源的V2版本,然后通过Ingress实现V1和V2版本直接的流量灰度。如图:

image.png

Pod

Deployment-v1

Service-V1

Pod

HPA-V1

lngress负载均衡

客户端

路由规则

lngress

Pod

50%

Deployment-v2

Service-v2

Pod

HPA-V2

在K8s中实现流量灰度发布

我们可以看到在k8s中基于流量对灰度过程,我们需要对这些资源进行细粒度的控制,包括新版本对应资源的创建以及灰度完成之后旧版本资源的清理,对于用户来说还是比较复杂的。那么在 Knative 中,如何进行灰度发布的呢?

  • 创建 Knative 服务
  • 更新 Knative 服务
  • 调整版本流量比例


这里我们只需要操作Knative Service服务资源,对于新变更只需要更新一下Knative Service信息(如镜像),就会自动创建一个新版本,灰度的规程只需要在Knative Service中调整对应版本的流量比例即可。如下图:

image.png

看了上面的灰度发布,我们接下来对 Knative 应用模型做进一步介绍。

应用模型

Knative 提供了极简的应用模型 - Knative Service,同时满足服务部署、服务访问以及灰度发布的能力。可以用下面的公式理解:Knative Service = 工作负载(Deployment)+服务访问(service)+灰度流量(Ingress) + 自动弹性。应用模型如图:


image.png

Service

manages

Configuration

Route

10%

Revisionv3

records

90%

history

of

Revisionv2

Revisionv1

  • Service: 对 Serverless 应用模型的抽象,通过Service 管理应用的生命周期
  • configuration: 用于配置应用期望的信息。每次更新Service 就会更新Configuration
  • revision: configuration的每次更新都会创建一个快照,用来做版本管理
  • route: 将请求路由到Revision,并可以向不同的Revision 转发不同比例的流量

丰富的弹性策略

作为 Serverless 框架,其核心能力就是自动弹性,Knative中提供了丰富的弹性策略:

  • 基于流量请求的自动扩缩容-KPA
  • 基于CPU、Memory的自动扩缩容-HPA
  • 支持定时 + HPA的自动扩缩容策略
  • 提供事件网关满足事件精准分发策略


Knative 和  ASK 融合

这里我们先来了解一下ASK。通常的我们使用K8s,需要提前准备 IaaS 资源才能部署应用,这无疑违背了serverless的 初衷。那么我们能否摆脱IaaS的束缚, 不必提前进行IaaS资源规划呢?答案就是:ASK

ASK是阿里云推出的无服务器Kubernetes。用户无需购买节点即可直接部署容器应用,无需对集群进行节点维护和容量规划。ASK集群提供完善的Kubernetes兼容能力,同时极大降低了Kubernetes使用门槛,让用户更专注于应用程序,而不是管理底层基础设施。

image.png

ASK集群

弹性容器实例

ECI

ECI

ECI

ECI

ECI

ECI

ECI

ECI

ECI

ECI

ECI

ECI

ECI

ECI

ECI

  • 免运维:开箱即用,无需节点管理、运维及安全维护。
  • 极致弹性扩容:无需容量规划,秒级扩容,30s 扩容 500 POD实例。
  • 低成本:按需创建POD,支持 spot(抢占式实例)、预留实例券
  • 兼容k8s:支持deployment/statefulset/job/service/ingress/crd等
  • Knative: 基于流量的应用自动弹性、缩容到保留实例
  • 存储挂载:支持云盘、NAS、OSS存储卷
  • Elastic Workload: 支持 eci 按量和 spot 混合调度
  • 集成ARMS/SLS等云产品


Knative 运维复杂度

了解了ASK,我们接下来看一下当前Knative 自身面临的一些问题:

  • Gateway 网关。Knative 社区提供Istio网关能力,但Istio组件较多,用户在管控这些组件时需要付出资源及运维成本。(虽然当前社区已经解耦了Istio, 用户可以自行选择更多轻量级的网关,但是资源及运维成本依然需要投入
  • Knative 管控组件。当前需要运维 7 个管控组件,需要用户额外投入资源及运维成本
  • 冷启动问题。Serverless 绕不开应用冷启动的问题,0到1的时候需要考虑如何保证服务的快速响应。

image.png

Gateway

NAME

AGE

UP-TO-DATE

AVAILABLE

READY

1/1

11d

activator

Knative管控组件

1

1/1

11d

autoscaler

11

1/1

11d

autoscaler-hpa

1/1

11d

controller

冷启动问题

1/1

11d

kourier-control

2/2

kourier-gateway

11d

1/1

11d

请求

webhook

冷启动

休眠状态

时间

资源

对于上述问题,我们在ASK Knative 中提供了如下的能力。

Gateway 和 SLB 融合

通过阿里云 SLB 提供网关能力:

  • 降成本:减少了十几个组件,大大降低运维成本和 IaaS 成本
  • 保稳定:SLB 云产品服务更稳定、可靠性更高,易用性也更好

image.png

管控组件下沉

将 Knative 管控组件进行托管:

  • 开箱即用:用户直接使用 Serverless Framework,不需要自己安装
  • 免运维、低成本:Knative 组件和 K8s 集群进行融合,用户没有运维负担,也无需承担额外的资源成本
  • 高管控:所有组件都在管控端部署,升级和迭代更容易

image.png


保留实例

解决从 0 到 1冷启动的问题:

  • 免冷启动:通过保留实例消除了从 0   1 30 秒冷启动时间
  • 成本可控:突发性能实例成本比标准规格实例降低 40% 的成本,如果和 Spot 实例结合还能再进一步降低成本


演示示例

  • ASK 集群中安装 Knative
  • 部署 helloworld 应用并访问
  • 保留实例

ASK 集群中安装 Knative

当前支持在创建 ASK 集群时选择安装 Knative, 也可以在ASK集群部署完成之后在应用 > Knative 中通过组件管理页签单击一键部署Knative。在已有的ASK集群部署 Knative 操作如下:

  1. 登录容器服务管理控制台
  2. 在控制台左侧导航栏中,单击集群
  3. 集群列表页面中,单击目标集群名称或者目标集群右侧操作列下的详情
  4. 在集群管理页左侧导航栏中,选择应用 > Knative
  5. 在Knative的组件管理页签单击一键部署Knative
  6. 选择需要安装的Knative组件后,单击部署

Knative 部署完成之后,结果如图:

image.png

knative-环列直手-yuanyL

服务骨玛

组件雷甲

卡族信息

祥:knative-系列白淄-yuanyf/Knntve组件管理

一皱邦宝

命名空间与配剂

@覃助文档

1作玲契

防问网关:39.108.199.36

肠务与路在

楼心辑祥

空滑窄

宁名三间

启生

麦心组行

股本

在恬

已部

Sarvtnng

O.12.0

李用

津班

已军哥

kratve-ewening

wo.14.0

Ewen:ng

Helm

add-on组件

徐作

青注

命名空间

状态

版本

Sdd-on组件

运净售锅

抵供CitHub件,示列:GitHuo件处导

来印开

GiTHub

安全霄理

饼MIrsOO件人险医片识

印禁

未凯3

V1.0.0

拆供K3tke2.0.0上)万漂于

已年哥

Kakka

y0.14.0

2021-02-04205355

来创

部署+印坊

提供ROCKELMQ实件正E

部省

2021-02-042054:07

Q0.19.0

笑Kourior朗关

已机者

供工件机作记威功装

kna5/we-56nfma

2021-02-0420:5412

部署 helloworld 应用并访问

  1. 登录容器服务管理控制台
  2. 集群列表页面中,单击目标集群名称或者目标集群右侧操作列下的详情
  3. 在集群管理页左侧导航栏中,选择应用 > Knative
  4. 服务管理页签右上角,单击创建服务
  5. 设置集群命名空间服务名称,选择所要使用的镜像和镜像版本等配置信息。这里我们使用 helloworld 示例镜像。

image.png

  1. 单击创建。创建完成后,您可以在服务管理页签的列表中,看到新创建的服务。点击服务名称,进入服务详情页,内容如下:

image.png

  1. 服务访问。

我们将域名绑定Host访问,也可以直接通过curl命令访问如下:

$ curl -H "host: helloworld-go.default.example.com" http://39.106.199.35
Hello World!

保留实例

在没有请求访问等时候(持续时间90s没有访问),会默认缩容到保留实例:

$ kubectl get po |grep hello
helloworld-go-v6z2l-deployment-754dc6c64d-89jlj                   2/2     Terminating   0          6m28s
helloworld-go-v6z2l-deployment-reserve-6bf95f6746-mq2wq           2/2     Running       0          116s

待保留实例 Ready 之后,会将正常实例下线掉。

总结

本文介绍了为什么需要Knative, Knative 核心模块 Serving , 同时通过在ASK的融合,降低Knative 运维及资源成本,最后我们通过一个示例演示了在 ASK 部署并访问 Knative 服务、缩容到保留实例。欢迎有兴趣同学关注 Knative 钉钉交流群。

image.png



相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
9月前
|
运维 监控 Cloud Native
【云故事探索】NO.17:国诚投顾的云原生 Serverless 实践
国诚投顾携手阿里云,依托Serverless架构实现技术全面升级,构建高弹性、智能化技术底座,提升业务稳定性与运行效率。通过云原生API网关、微服务治理与智能监控,实现流量精细化管理与系统可观测性增强,打造安全、敏捷的智能投顾平台,助力行业数字化变革。
【云故事探索】NO.17:国诚投顾的云原生 Serverless 实践
|
9月前
|
运维 监控 Cloud Native
【云故事探索】NO.17:国诚投顾的云原生 Serverless 实践
通过与阿里云深度合作,国诚投顾完成了从传统 ECS 架构向云原生 Serverless 架构的全面转型。新的技术架构不仅解决了原有系统在稳定性、弹性、运维效率等方面的痛点,还在成本控制、API 治理、可观测性、DevOps 自动化等方面实现了全方位升级。
|
8月前
|
人工智能 Cloud Native 中间件
【云栖大会】AI原生、AI可观测、AI Serverless、AI中间件,4场论坛20+议题公布!
2025 年 9 月 24 日至 26 日,杭州·云栖小镇,4 大论坛、20+ 主题分享,从云原生到 AI 原生,我们诚邀您共赴企业智能化升级浪潮之巅。
|
存储 运维 Serverless
千万级数据秒级响应!碧桂园基于 EMR Serverless StarRocks 升级存算分离架构实践
碧桂园服务通过引入 EMR Serverless StarRocks 存算分离架构,解决了海量数据处理中的资源利用率低、并发能力不足等问题,显著降低了硬件和运维成本。实时查询性能提升8倍,查询出错率减少30倍,集群数据 SLA 达99.99%。此次技术升级不仅优化了用户体验,还结合AI打造了“一看”和“—问”智能场景助力精准决策与风险预测。
1198 69
|
Cloud Native Serverless 流计算
云原生时代的应用架构演进:从微服务到 Serverless 的阿里云实践
云原生技术正重塑企业数字化转型路径。阿里云作为亚太领先云服务商,提供完整云原生产品矩阵:容器服务ACK优化启动速度与镜像分发效率;MSE微服务引擎保障高可用性;ASM服务网格降低资源消耗;函数计算FC突破冷启动瓶颈;SAE重新定义PaaS边界;PolarDB数据库实现存储计算分离;DataWorks简化数据湖构建;Flink实时计算助力风控系统。这些技术已在多行业落地,推动效率提升与商业模式创新,助力企业在数字化浪潮中占据先机。
683 12
|
人工智能 Serverless 调度
突破地域限制,实现算力无限供给 -- 阿里云ACK One注册集群开启多地域Serverless算力调度
传统单地域算力难以支撑AI推理场景的高并发实时响应、突发高流量的要求,阿里云容器服务ACK One注册集群推出多地域Serverless算力调度方案完美解决此问题。
|
人工智能 Serverless 调度
突破地域限制,实现算力无限供给 —阿里云ACK One注册集群开启多地域Serverless算力调度
本文介绍了阿里云ACK One注册集群多地域Serverless算力调度解决方案,解决传统数据中心在AI时代面临的算力不足问题。方案通过分钟级接入、100%兼容Kubernetes操作及云上Serverless弹性,实现跨地域弹性算力供给,支持高并发请求与模型快速迭代。文中详细描述了快速接入步骤、指定地域调度及动态调度方法,并提供了相关代码示例。该方案助力企业实现AI推理服务的规模化部署,提升商业落地效率。
|
Kubernetes 监控 Serverless
基于阿里云Serverless Kubernetes(ASK)的无服务器架构设计与实践
无服务器架构(Serverless Architecture)在云原生技术中备受关注,开发者只需专注于业务逻辑,无需管理服务器。阿里云Serverless Kubernetes(ASK)是基于Kubernetes的托管服务,提供极致弹性和按需付费能力。本文深入探讨如何使用ASK设计和实现无服务器架构,涵盖事件驱动、自动扩展、无状态设计、监控与日志及成本优化等方面,并通过图片处理服务案例展示具体实践,帮助构建高效可靠的无服务器应用。
|
7月前
|
人工智能 运维 Kubernetes
Serverless 应用引擎 SAE:为传统应用托底,为 AI 创新加速
在容器技术持续演进与 AI 全面爆发的当下,企业既要稳健托管传统业务,又要高效落地 AI 创新,如何在复杂的基础设施与频繁的版本变化中保持敏捷、稳定与低成本,成了所有技术团队的共同挑战。阿里云 Serverless 应用引擎(SAE)正是为应对这一时代挑战而生的破局者,SAE 以“免运维、强稳定、极致降本”为核心,通过一站式的应用级托管能力,同时支撑传统应用与 AI 应用,让企业把更多精力投入到业务创新。
754 30

相关产品

  • 函数计算
  • 推荐镜像

    更多