初识-Knative-跨平台的-Serverless-编排框架

jiezi

5 年前

Knative 是 Google 在 2018 的 Google Cloud Next 大会上发布的一款基于 Kubernetes 的 Serverless 框架。Knative 一个很重要的目标就是制定云原生、跨平台的 Serverless 编排标准。Knative 是通过整合容器构建 (或者函数)、工作负载管理(和动态扩缩) 以及事件模型这三者来实现的这一 Serverless 标准。Knative 社区的主要贡献者有 Google、Pivotal、IBM、Red Hat。可见其阵容强大，CloudFoundry、OpenShift 这些 PAAS 提供商都在积极的参与 Knative 的建设。

在 Knative 之前社区已经有很多 Serverless 解决方案，如下所示这些：

kubeless
Fission
OpenFaaS
Apache OpenWhisk
…

除了上面这些社区的开源解决方案以外各大云厂商也都有各自的 FAAS 产品的实现比如：

AWS Lambda
Google Cloud Functions
Microsoft Azure Functions
阿里云的函数计算

业务代码部署到 Serverless 平台上就离不开源码的编译、部署和事件的管理。然而无论是开源的解决方案还是各公有云的 FAAS 产品大家的实现方式大家都各不相同，缺乏统一的标准导致市场呈现碎片化。因此无论选择哪一个方案都面临供应商绑定的风险。

没有统一的标准、市场的碎片化这对云厂商来说用户 Serverless 上云就比较困难，对于 PAAS 提供商来说很难做一个通用的 PAAS 平台给用户使用。基于这样的背景 Google 牵头联合 Pivotal、IBM、Red Hat 等发起了 Knative 项目。

我们看一下在 Knative 体系下各个角色的协作关系：

Developers
Serverless 服务的开发人员可以直接使用原生的 Kubernetes API 基于 Knative 部署 Serverless 服务
Contributors
主要是指社区的贡献者
Operators
Knative 可以被集成到任何支持的环境中，比如：云厂商、或者企业内部。目前 Knative 是基于 Kubernetes 来实现的，有 Kubernetes 的地方就可以部署 Knative
Users
终端用户通过 Istio 网关访问服务，或者通过事件系统触发 Knative 中的 Serverless 服务

作为一个通用的 Serverless 框架 Knative 由三个核心组件组成：

Build：提供从源码到镜像的通用构建能力
Eventing：提供了事件的接入、触发等一整套事件管理的能力
Serving：管理 Serverless 工作负载，可以和事件很好的结合并且提供了基于请求驱动的自动扩缩的能力，而且在没有服务需要处理的时候可以缩容到零个实例

Build 组件主要负责从代码仓库获取源码并编译成镜像和推送到镜像仓库。并且所有这些操作都是在 Kubernetes Pod 中进行的。

Eventing 组件针对 Serverless 事件驱动模式做了一套完整的设计。包括外部事件源的接入、事件注册和订阅、以及对事件的过滤等功能。事件模型可以有效的解耦生产者和消费者的依赖关系。生产者可以在消费者启动之前产生事件，消费者也可以在生产者启动之前“监听事件”。

Serving 组件的职责是管理工作负载以对外提供服务。对于 Knative Serving 组件最重要的特性就是自动伸缩的能力，目前伸缩边界支持从 0 到无限大。Serving 还有一个比较重要的功能就是灰度发布能力。

Knative 虽然是基于 Kubernetes 实现，不过这并不代表 Kubernetes 的所有功能都能在 Knative 中使用。因为 Knative 针对 Serverless 场景做了专门的设计，如一个 Pod 中只能有一个 Container，一个 Container 只能有一个 Port 等。具体这些详细的内容我们会在后续的文章中陆续介绍。

Knative 一方面基于 Kubernetes 实现 Serverless 编排，另外一方面 Knative 还基于 Istio 实现服务的接入、服务路由的管理以及度发布等功能。Knative 是在已有的云原生基础之上构建的，有很好的社区基础。Knative 一经开源就得到了大家的追捧，其中的主要缘由有：

Knative 的定位不是 PAAS 而是一个通用的 Serverless 编排框架，大家可以基于此框架构建自己的 Serverless PAAS
Knative 对于 Serverless 架构的设计是标准先行。比如之前的 FAAS 解决方案每一个都有一套自己的事件标准，相互之间无法通用。而 Knative 首先提出了 CloudEvent 这一标准，然后基于此标准进行设计
完备的社区生态：Kubernetes、ServiceMesh 等社区都是 Knative 的支持者
跨平台：因为 Knative 是构建在 Kubernetes 之上的，而 Kubernetes 在不同的云厂商之间几乎可以提供通用的标准。所以 Knative 也就实现了跨平台的能力，没有供应商绑定的风险
完备的 Serverless 模型设计：和之前的 Serverless 解决方案相比 Knative 各方面的设计更加完备。比如：
- 事件模型非常完备，有注册、订阅、以及外部事件系统的接入等等一整套的设计
- 比如从源码到镜像的构建
- 比如 Serving 可以做到按比例的灰度发布

关于 Knative 出现的背景、要解决的问题、核心概念以及其优势就介绍到这里，后续我们会有一系列的文章由浅入深的来介绍 Knative 的使用以及剖析其内部实现。

双 11 福利来了！先来康康 #怎么买云服务器最便宜# [并不简单]参团购买指定配置云服务器仅 86 元 / 年，开团拉新享三重礼：1111 红包 + 瓜分百万现金 +31% 返现，爆款必买清单，还有 iPhone 11 Pro、卫衣、T 恤等你来抽，马上来试试手气！https://www.aliyun.com/1111/2019/home?utm_content=g_1000083110

本文作者：冬岛

阅读原文

本文为云栖社区原创内容，未经允许不得转载。

初识-Knative-跨平台的-Serverless-编排框架

Knative 是什么

Knative 出现的背景

Knative 核心组件

Knative 的优势