初识 Knative: 跨平台的 Serverless 编排框架-阿里云开发者社区

开发者社区> 阿里巴巴云原生> 正文

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

简介: 作者|阿里云智能事业群技术专家 冬岛 []() Knative 是什么 Knative 是 Google 在 2018 的 Google Cloud Next 大会上发布的一款基于 Kubernetes 的 Serverless 框架。

作者|阿里云智能事业群技术专家 冬岛

[]()

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

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

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里巴巴云原生
使用钉钉扫一扫加入圈子
+ 订阅

关注云原生中间件、微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生技术趋势、云原生大规模的落地实践

官方博客