导读
随着云计算技术的发展,云资源交付变的越来越简单,按需使用已经成为可能。在按需使用资源的模式下,用户更多的聚焦于业务自身,而减少了对基础设施的关注,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 的目的,都是为了交付和管理应用,当然也包括灰度发布、扩容缩容等,并且兼顾资源成本。
但我们实际在使用Kubernetes过程中, 逐渐会发现如下问题:
- 通过 k8s API 实现服务全生命周期管理比较复杂
- 云 IaaS 资源规格繁杂,每一种规格适用场景都所有不同,用户很难自己组合所有规格
- 节省资源使用成本,弹性越来越重要
那么如何才能简单的使用容器(K8s)技术?如何随心所欲的实现按需使用,降低成本?答案就是:Knative
Knative
降本
效
增
Knative 简介
K
es-basedplatformtobuild,deploy
andmanagemodernserverle
es平台,用于构建,部
基于Kubernetes
管理现代Serverless工作负载
Knative是在 2018 的 Google Cloud Next 大会上发布的一款基于Kubernetes 的 Serverless编排引擎。Knative一个很重要的目标就是制定云原生、跨平台的Serverless编排标准。Knative是通过整合容器构建(或者函数)、工作负载管理(弹性)以及事件模型这三者来实现的这一Serverless标准。Knative社区的当前主要贡献者有Google、Pivotal、IBM、Red Hat。另外像 CloudFoundry、OpenShift这些 PAAS 提供商都在积极的参与Knative的建设。
Knative 核心模块
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版本直接的流量灰度。如图:
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中调整对应版本的流量比例即可。如下图:
看了上面的灰度发布,我们接下来对 Knative 应用模型做进一步介绍。
应用模型
Knative 提供了极简的应用模型 - Knative Service,同时满足服务部署、服务访问以及灰度发布的能力。可以用下面的公式理解:Knative Service = 工作负载(Deployment)+服务访问(service)+灰度流量(Ingress) + 自动弹性。应用模型如图:
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使用门槛,让用户更专注于应用程序,而不是管理底层基础设施。
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的时候需要考虑如何保证服务的快速响应。
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 云产品服务更稳定、可靠性更高,易用性也更好
管控组件下沉
将 Knative 管控组件进行托管:
- 开箱即用:用户直接使用 Serverless Framework,不需要自己安装
- 免运维、低成本:Knative 组件和 K8s 集群进行融合,用户没有运维负担,也无需承担额外的资源成本
- 高管控:所有组件都在管控端部署,升级和迭代更容易
保留实例
解决从 0 到 1冷启动的问题:
- 免冷启动:通过保留实例消除了从 0 到 1 的 30 秒冷启动时间
- 成本可控:突发性能实例成本比标准规格实例降低 40% 的成本,如果和 Spot 实例结合还能再进一步降低成本
演示示例
- 在 ASK 集群中安装 Knative
- 部署 helloworld 应用并访问
- 保留实例
在 ASK 集群中安装 Knative
当前支持在创建 ASK 集群时选择安装 Knative, 也可以在ASK集群部署完成之后在应用 > Knative 中通过组件管理页签单击一键部署Knative。在已有的ASK集群部署 Knative 操作如下:
- 登录容器服务管理控制台。
- 在控制台左侧导航栏中,单击集群。
- 在集群列表页面中,单击目标集群名称或者目标集群右侧操作列下的详情。
- 在集群管理页左侧导航栏中,选择应用 > Knative。
- 在Knative的组件管理页签单击一键部署Knative。
- 选择需要安装的Knative组件后,单击部署。
Knative 部署完成之后,结果如图:
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 应用并访问
- 登录容器服务管理控制台。
- 在集群列表页面中,单击目标集群名称或者目标集群右侧操作列下的详情。
- 在集群管理页左侧导航栏中,选择应用 > Knative。
- 在服务管理页签右上角,单击创建服务。
- 设置集群、命名空间、服务名称,选择所要使用的镜像和镜像版本等配置信息。这里我们使用 helloworld 示例镜像。
- 单击创建。创建完成后,您可以在服务管理页签的列表中,看到新创建的服务。点击服务名称,进入服务详情页,内容如下:
- 服务访问。
我们将域名绑定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 钉钉交流群。