Knative:重新定义 Serverless | GIAC 实录

  1. 云栖社区>
  2. 博客>
  3. 正文

Knative:重新定义 Serverless | GIAC 实录

s潘潘 2019-01-02 14:38:18 浏览371 评论0

摘要: Knative 是Google 发起的 Serverless 项目,希望通过提供一套简单易用的 Serverless 开源方案,将 Serverless 标准化。本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理,文末有PPT获取地址。

Knative 是Google 发起的 Serverless 项目,希望通过提供一套简单易用的 Serverless 开源方案,将 Serverless 标准化。
本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理,文末有PPT获取地址。

image.png | left | 754x223

前言

大家好,今天给大家来的演讲专题是“Knative:重新定义Serverless”, 我是来自蚂蚁金服中间件的敖小剑。

image | left

这是我的个人资料,有兴趣的同学可以关注的我的个人技术博客网站 https://skyao.io。

image | left

这次演讲的内容将会有这些,首先给大家介绍一下 Knative 是什么,然后是 Knative 的主要组件,让大家对 Knative 有一个基本的了解。之后我会简单的对 Knative 做一些分析和探讨,以及介绍一下 Knative 后续的发展。希望本次的内容让大家能够对Knative有一个基本的认知。

什么是Knative?

image | left

Knative 是 Google 牵头发起的 Serverless 项目。

image | left

这是Knative的项目定义,注意这句话里面几个关键字:Kubernetes,Serverless,Workload。

image | left

这是最近几年 Google 做大型项目的常态:产品刚出来,阵营就已经很强大了,所谓先声夺人。

image | left

这是目前Knative项目的进展,可以看到这是一个非常新的项目,刚刚起步。

备注:这是截至2018-11-24演讲当天的情况,到2018年12月底,Knative已经发布了v0.2.2和v0.2.3两个bugfix版本。但也还只是 0.2 ……

image | left

我们来看一下,在Knative出来前, Serverless 领域已有的实现,包括云端提供的产品和各种开源项目。

image | left

这幅图片摘自The New Stack的一个Serverless 调查,我们忽略调查内容,仅仅看看这里列出来的Serverless产品的数量——感受是什么?好多Serverless项目,好多选择!

那问题来了:到底该怎么选?

image | left

这就是目前 Serverless 的问题:由于缺乏标准,市场呈现碎片化。不同厂商,不同项目,各不相同,因此无论怎么选择,都面临一个风险:供应商绑定!

image | left

这段话来自 Knative 的官方介绍,Google 推出 Knative 的理由和动机。其中第一条和第二条针对的是当前 Serverless 市场碎片的现状。而第四条多云战略,则是针对供应商绑定的风险。

image | left

Google描述Knative的动机之一,是将云原生中三个领域的最佳实践结合起来。

小结:

当前 Serverless 市场产品众多导致碎片化严重,存在厂商绑定风险,而 Google 推出 Knative,希望能提供一套简单易用的 Serverless 方案,实现 Serverless 的标准化和规范化。

Knative的主要组件

image | left

第二部分,来介绍一下Knative的主要组件。

image | left

前面提到,Google 推出 Knative ,试图将云原生中三个领域的最佳实践结合起来。反应到 Knative 产品中,就是这三大主要组件:Build,Serving,Eventing。

image | left

Knative Build 组件,实现从代码到容器的目标。为什么不直接使用 dockfile 来完成这个事情?

image | left

Knative Build 在实现时,是表现为 Kubernetes 的 CRD,通过 yaml 文件来定义构建过程。这里引入了很多概念如:Build,Builder,Step,Template,Source等。另外支持用 Service Account 做身份验证。

image | left

Knative Serving组件的职责是运行应用以对外提供服务,即提供服务、函数的运行时支撑。

注意定义中的三个关键:

  1. Kubernetes-based:基于k8s,也仅支持k8s,好处是可以充分利用k8s平台的能力
  2. scale-to-zero:serverless 最重要的卖点之一,当然要强调
  3. request-driven compute:请求驱动的计算

值得注意的是,除了k8s之外,还有另外一个重要基础:istio!后面会详细聊这个。

Knative Serving项目同样也提供了自己的中间件原语,以支持如图所示的几个重要特性。

image | left

Knative中有大量的概念抽象,而在这之后的背景,说起来有些意思:Knative 觉得 kubernetes 和 istio 本身的概念非常多,多到难于理解和管理,因此 Knative 决定要自己提供更高一层的抽象。至于这个做法,会是釜底抽薪解决问题,还是雪上加霜让问题更麻烦……

Knative的这些抽象都是基于 kubernetes 的 CRD 来实现,具体抽象概念有:Service、Route、Configuration 和 Revision。特别提醒的是,右边图中的 Service 是 Knative 中的 Service 概念,service.serving.knative.dev,而不是大家通常最熟悉的 k8s 的 service。

image | left

对于Knative Serving 组件,最重要的特性就是自动伸缩的能力。目前伸缩边界支持从0到无限,容许通过配置设置。

Knative 目前是自己实现的 Autoscaler ,原来比较简单:Revision 对应的pod由 k8s deployment 管理,pod上的工作负载上报 metrics,汇总到 Autoscaler 分析判断做决策,在需要时修改 replicas 数量来实现自动伸缩(后面会再讲这块存在的问题)。

当收缩到0,或者从0扩展到1时,情况会特别一些。Knative在这里提供了名为 Activator 的设计,如图所示:

  1. Istio Route 控制流量走向,正常情况下规则设置为将流量切到工作负载所在的pod
  2. 当没有流量,需要收缩到0时,规则修改为将流量切到 Activator ,如果一直没有流量,则什么都不发生。此时Autoscaler 通过 deployment 将 replicas 设置为0。
  3. 当新的流量到来时,流量被 Activator 接收,Activator 随即拉起 pod,在 pod 和工作负载准备好之后,再将流量转发过去

image | left

Knative Eventing 组件负责事件绑定和发送,同样提供多个抽象概念:Flow,Source,Bus,以帮助开发人员摆脱概念太多的负担(关于这一点,我保留意见)。

image | left

Bus 是对消息总线的抽象。

image | left

Source 是事件数据源的抽象。

image | left

Knative 在事件定义方面遵循了 Cloudevents 规范。

小结:

简单介绍了一下 Knative 中的三大组件,让大家对 Knative 的大体架构和功能有个基本的认知。这次就不再继续深入 Knative 的实现细节,以后有机会再展开。

Knative分析和探讨

image | left

在第三部分,我们来分析探讨一下 Knative 的产品定位,顺便也聊一下为什么我们会看好 Knative。

image | left

首先,最重要的一点是:Knative __不是__一个 Serverless 实现,而是一个 Serviceless 平台。

也就是说,Knative 不是在现有市场上的20多个 Serverless 产品和开源项目的基础上简单再增加一个新的竞争者,而是通过建立一个标准而规范的 Serverless 平台,容许其他 Serverless 产品在 Knative 上运行。

image | left

Knative 在产品规划和设计理念上也带来了新的东西,和传统 Serverless 不同。工作负载和平台支撑是 Knative 最吸引我们的地方。

image | left

要不要Istio?这是 Knative 一出来就被人诟病和挑战的点:因为 Istio 的确是复杂度有点高。而 k8s 的复杂度,还有 Knative 自身的复杂度都不低,再加上 Istio……

关于这一点,个人的建议是:

  • 如果原有系统中没有规划 Istio/Service mesh 的位置,那么为了 Knative 而引入 Istio 的确是代价偏高。可以考虑用其他方式替代,最新版本的 Knative 已经实现了对 Istio 的解耦,容许替换。
  • 如果本来就有规划使用 Istio/Service mesh ,比如像我们蚂蚁这种,那么 Knative 对 Istio 的依赖就不是问题了,反而可以组合使用。

而 Kubernetes + Servicemesh + Serverless 的组合,我们非常看好。

image | left

当然,Knative 体系的复杂度问题是无法回避的:Kubernetes,Istio,Knative 三者都是复杂度很高的产品, 加在一起整体复杂度就非常可观了,挑战非常大。

Knative后续发展

image | left

第四个部分,我们来展望一下 Knative 的后续发展,包括如何解决一些现有问题。

image | left

第一个问题就是性能问题。

image | left

Queue Proxy也是一个现存的需要替换的模块。

image | left

前面讲过 Knative 的 Autoscaler 是自行实现的,而 k8s 目前已经有比较健全原生能力: HPA 和 Custom Metrics。目前 Knative 已经有计划要转而使用 k8s 的原生能力。这也符合 Cloud Native 的玩法:将基础能力下沉到 k8s 这样的基础设施,上层减负。

image | left

除了下沉到 k8s 之外,Autoscaler还有很多细节需要在后续版本中完善。

image | left

对事件源和消息系统的支持也远不够完善,当然考虑到目前才 0.2.0 版本,可以理解。

image | left

目前 Knative 还没有规划 Workflow 类的产品。

image | left

在网络路由能力方面也有很多欠缺,上面是 Knative 在文档中列出来的需求列表。

image | left

最后聊聊 Knative 的可拔插设计,这是 Knative 在架构设计上的一个基本原则:顶层松耦合,底层可拔插。

最顶层是 Build / Serving / Eventing 三大组件,中间是各种能力,通过 k8s 的 CRD 方式来进行声明,然后底层是各种实现,按照 CRD 的要求进行具体的实现。

在这个体系中,用户接触的是 Build / Serving / Eventing 通用组件,通过通过标准的 CRD 进行行为控制,而和底层具体的实现解耦。理论上,之后在实现层做适配,Knative 就可以运行在不同的底层 Serverless 实现上。从而实现 Knative 的战略目标:提供 Serverless 的通用平台,实现 Serverless 的标准化和规范化。

总结

image | left

最后,我们对 Knative 做一个简单总结。

image | left

先谈一下 Knative 的优势,首先是 Knative 自身的几点:

  • 产品定位准确:针对市场现状,不做竞争者而是做平台
  • 技术方向明确:基于 k8s,走 Cloud Native 方向
  • 推出时机精准:k8s 大势已成,istio 接近成熟

然后,再次强调:Kubernetes + Service mesh + Serverless 的组合,在用好的前提下,应该威力不凡。

此外,Knative 在负载的支撑上,不拘泥于传统的FaaS,可以支持 BaaS 和传统应用,在落地时适用性会更好,使用场景会更广泛。(备注:在这里我个人有个猜测,Knative 名字中 native 可能指的是 native workload,即在 k8s 和 Cloud Native 语义下的原生工作负载,如果是这样,那么 Google 和 Knative 的这盘棋就下的有点大了。)

最后,考虑到目前 Serverless 的市场现状,对 Serverless 做标准化和规范化,出现一个 Serverless 平台,似乎也是一个不错的选择。再考虑到 Google 拉拢大佬和社区一起干的一贯风格,携 k8s 和 Cloud Native 的大势很有可能实现这个目标。

当然,Knative 目前存在的问题也很明显,细节不说,整体上个人感觉有:

  • 成熟度:目前才 0.2 版本,实在太早期,太多东西还在开发甚至规划中。希望随着时间的推移和版本演进,Knative 能尽快走向成熟。
  • 复杂度:成熟度的问题还好说,总能一步一步改善的,无非是时间问题。但是 Knative 的系统复杂度过高的问题,目前看来几乎是不可避免的。

最后,对 Knative 的总结,就一句话:__前途不可限量,但是成长需要时间__。让我们拭目以待。

image | left

欢迎大家加入 servicemesher 社区,也可以通过关注 servicemesher 微信公众号来及时了解 service mesh 技术的最新动态。
PPT 地址:http://www.sofastack.tech/posts/2019-01-02-01

image | left

长按关注,获取分布式架构干货
欢迎大家共同打造 SOFAStack https://github.com/alipay

【云栖快讯】一站式开发者服务,海量学习资源免费学  详情请点击

网友评论