Knative：从新定义 Serverless | GIAC 实录

Knative 是Google 发起的 Serverless 项目，但愿经过提供一套简单易用的 Serverless 开源方案，将 Serverless 标准化。

本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理，文末有PPT获取地址。

前言

你们好，今天给你们来的演讲专题是“Knative：从新定义Serverless”, 我是来自蚂蚁金服中间件的敖小剑。

这是个人我的资料，有兴趣的同窗能够关注的个人我的技术博客网站 skyao.io。

此次演讲的内容将会有这些，首先给你们介绍一下 Knative 是什么，而后是 Knative 的主要组件，让你们对 Knative 有一个基本的了解。以后我会简单的对 Knative 作一些分析和探讨，以及介绍一下 Knative 后续的发展。但愿本次的内容让你们可以对Knative有一个基本的认知。

什么是Knative？

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

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

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

这是目前Knative项目的进展，能够看到这是一个很是新的项目，刚刚起步。

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

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

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

那问题来了：到底该怎么选？

这就是目前 Serverless 的问题：因为缺少标准，市场呈现碎片化。不一样厂商，不一样项目，各不相同，所以不管怎么选择，都面临一个风险：供应商绑定！

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

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

小结：

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

Knative的主要组件

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

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

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

Knative Build 在实现时，是表现为 Kubernetes 的 CRD，经过 yaml 文件来定义构建过程。这里引入了不少概念如：Build，Builder，Step，Template，Source等。另外支持用 Service Account 作身份验证。

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

注意定义中的三个关键：

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

值得注意的是，除了k8s以外，还有另一个重要基础：istio！后面会详细聊这个。

Knative Serving项目一样也提供了本身的中间件原语，以支持如图所示的几个重要特性。

Knative中有大量的概念抽象，而在这以后的背景，提及来有些意思：Knative 以为 kubernetes 和 istio 自己的概念很是多，多到难于理解和管理，所以 Knative 决定要本身提供更高一层的抽象。至于这个作法，会是釜底抽薪解决问题，仍是雪上加霜让问题更麻烦……

Knative的这些抽象都是基于 kubernetes 的 CRD 来实现，具体抽象概念有：Service、Route、Configuration 和 Revision。特别提醒的是，右边图中的 Service 是 Knative 中的 Service 概念， service.serving.knative.dev，而不是你们一般最熟悉的 k8s 的 service。

对于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 和工做负载准备好以后，再将流量转发过去

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

Bus 是对消息总线的抽象。

Source 是事件数据源的抽象。

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

小结：

简单介绍了一下 Knative 中的三大组件，让你们对 Knative 的大致架构和功能有个基本的认知。此次就再也不继续深刻 Knative 的实现细节，之后有机会再展开。

Knative分析和探讨

在第三部分，咱们来分析探讨一下 Knative 的产品定位，顺便也聊一下为何咱们会看好 Knative。

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

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

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

要不要Istio？这是 Knative 一出来就被人诟病和挑战的点：由于 Istio 的确是复杂度有点高。而 k8s 的复杂度，还有 Knative 自身的复杂度都不低，再加上 Istio……

关于这一点，我的的建议是：

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

而 Kubernetes + Servicemesh + Serverless 的组合，咱们很是看好。

固然，Knative 体系的复杂度问题是没法回避的：Kubernetes，Istio，Knative 三者都是复杂度很高的产品， 加在一块儿总体复杂度就很是可观了，挑战很是大。

Knative后续发展

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

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

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

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

除了下沉到 k8s 以外，Autoscaler还有不少细节须要在后续版本中完善。

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

目前 Knative 尚未规划 Workflow 类的产品。

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

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

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

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

总结

最后，咱们对 Knative 作一个简单总结。

先谈一下 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 的总结，就一句话： 前途不可限量，可是成长须要时间。让咱们拭目以待。

欢迎你们加入 servicemesher 社区，也能够经过关注 servicemesher 微信公众号来及时了解 service mesh 技术的最新动态。

PPT 地址：www.sofastack.tech/posts/2019-…

长按关注，获取分布式架构干货

欢迎你们共同打造 SOFAStack https://github.com/alipay