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

阳光穿透心脏的1/2处 2022-01-14 05:13 217阅读 0赞

[2019独角兽企业重金招聘Python工程师标准>>> ][2019_Python_] ![hot3.png][]

## Knative 是什么 ##

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

## 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 体系下各个角色的协作关系：

![00cbeafd48ee1d04eaee401f8255501a856.jpg][]

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

## Knative 核心组件 ##

作为一个通用的 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 的优势 ##

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 的使用以及剖析其内部实现。

--------------------

![f0a386a6e4b56033697f3b0f6587b444765.jpg][]

[原文链接][Link 1]  
本文为云栖社区原创内容，未经允许不得转载。

转载于:https://my.oschina.net/u/1464083/blog/3053257

[2019_Python_]: https://my.oschina.net/u/2663968/blog/3061697
[hot3.png]: /images/20220114/fb6c78fdf1e949da950eff7922311d26.png
[00cbeafd48ee1d04eaee401f8255501a856.jpg]: /images/20220114/13326613f93e4a6d8cbeadce9698a9b8.png
[f0a386a6e4b56033697f3b0f6587b444765.jpg]: /images/20220114/1d8c70a7205e4132a6a54b3cefa77e68.png
[Link 1]: https://yq.aliyun.com/articles/703356?utm_content=g_1000059296#