目录

一、 Serverless介绍

二、Knative 介绍

2.1  Knative 的定位

2.2 Knative的组成 

2.2.1 Build 构建系统

2.2.2 Serving：服务系统

2.2.3 Eventing：事件系统

补充： 

三、总结：

---

一、 Serverless介绍

在讲Knative之前，需要先讲一下Serverless。

对于Serverless，目前还没有形成一个比较权威的定义，最新的一个定义是这样描述的：

“无服务器架构是基于互联网的系统，其中应用开发不使用常规的服务进程。相反，它们仅依赖于第三方服务（例如AWS Lambda服务），客户端逻辑和服务托管远程过程调用的组合。”

最开始，“无服务器”架构试图帮助开发者摆脱运行后端应用程序所需的服务器设备的设置和管理工作。

这显然是不成立的，因为这项技术的目标并不是为了实现真正意义上的“无服务器”，而是指由第三方云计算供应商负责后端基础结构的维护，以服务的方式为开发者提供所需功能，例如数据库、消息，以及身份验证等。

简单地说，这个Serverless架构的目标：就是要让开发人员关注代码的运行而不需要管理任何的基础设施。

程序代码被部署在诸如AWS Lambda这样的平台之上，通过事件驱动的方法去触发对函数的调用。

也可以理解为，这是一种完全针对程序员的架构技术。为了简化开发人员的工作，提高业务实现效率而研发的一种架构。

其技术特点包括了事件驱动的调用方式，以及有一定限制的程序运行方式，例如AWS Lambda的函数的运行时间默认为3秒到5分钟。

从这种架构技术出现的两年多时间来看，这个技术已经有了非常广泛的应用，例如移动应用的后端和物联网应用等。

简而言之，无服务器架构的出现不是为了取代传统的应用。而是从具有高度灵活性的使用模式及事件驱动的特点出发，

开发人员／架构师应该重视这个新的计算范例，它可以帮助我们达到减少部署、提高扩展性并减少代码后面的基础设施的维护负担。

如下图，按照传统的方式，一个项目前端+后端+基础设施都是必须的，基本上项目都是需要有一套。

但是，对于无服务架构来说，拆分后端，比如把权限、业务应用、数据库等拆分，从而使得开发更灵活，复用性更强，也就是一直说的，缩短产品到落地的时间，从而缩短产品周期，提高整个项目实现的效率。

这个也是无服务的主要意义。感觉架构的发展也好，服务的演变也好，所有的发展，基本上为了提高效率，更快的从想法到产品的一个落地实施。

但是，传统的 Serverless 解决方案自身的问题有一些问题，目前存在以下问题：

• 缺乏统一标准。呈现碎片化，各家都有各自的实现。
• 厂商锁定。比如使用 AWS Lambda 就必须配套使用 AWS 的 DB, S3 等产品，这样用户就被该厂商绑定，不能进行随意的迁移或者迁移成本非常高。

为了解决传统的 Serverless这几个问题，Knative就出现了。 

二、Knative 介绍

Knative 是谷歌牵头发起的 Serverless 项目。

其目标是基于 Kubernetes 的 Serverless 解决方案，旨在标准化 Serverless，简化其学习成本。

Knative 是以 Kubernetes 的一组自定义资源类型（CRD）的方式来安装的，因此只需使用几个 YAML 文件就可以轻松地开始使用 Knative 了。

这也意味着，在本地或者托管云服务上，任何可以运行 Kubernetes 的地方都可以运行 Knative 和代码。

2.1  Knative 的定位

Knative构建在Kubernetes、Istio、Container的基础上，以K8S的CRD形式存在。

1. 基础设施：Kubernetes作为基础设施：容器编排，解决应用编排和运行环境
2. 通信设施：Isito作为通信基础设施层，保证服务的运行可检测、可配置、可追踪
3. 模板+环境：Knative使用应用模板和统一的运行环境来标准化服务的构建、部署和管理

2.2 Knative的组成 

为了实现 serverless 应用的管理，knative 把整个系统分成了三个部分：

• Build：构建系统，把用户定义的函数和应用 build 成容器镜像
• Serving：服务系统，用来配置应用的路由、升级策略、自动扩缩容等功能
• Eventing：事件系统，用来自动完成事件的绑定和触发

2.2.1 Build 构建系统

build 的功能是把用户的代码自动化构建成容器镜像

与普通docker+Dockerfile 构建容器相比较

Knative优势：

• 内部构建：是它的构建完成是在 kubernetes 中进行的，和整个 kubernetes 生态结合更紧密
• 标准化：它旨在提供一个通用的标准化的构建组件，可以作为其他更大系统中的一部分

它的存在，更多是为了定义标准化、可移植、可重用、性能高效的构建方法

Knative 提供了 Build CRD 对象，让用户可以通过 yaml 文件定义构建过程。一个典型的 Build 配置文件如下：

apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
  name: test-build
spec:
  serviceAccountName: build-auth-test #认证信息
  source:
    git:
      url: https://github.com/your-example/build-example.git #代码地址
      revision: master #分支信息
  steps:
  - name: ubuntu-example
    image: ubuntu
    args: ["ubuntu-build-example", "SECRETS-example.md"]
  steps:
  - image: gcr.io/example-builders/build-example
    args: ['echo', 'test-example', 'build']

1. serviceAccountName ：是构建过程中需要用到的密码和认证信息（比如连接到 git repo 的 SSH keys、push 镜像到 registry 的用户名和密码等）；
2. source ：是代码信息，比如这里的 git 地址和分支；
3. steps ：是真正运行过程中的各个步骤，这个只是作为 demo，真正的构建过程一般是 pull 代码、 build 镜像和 push镜像到 registry 等逻辑。

因为大部分的构建过程都是一致的，因此 knative 还提供了 Build template 的概念，

Build template 封装了预先定义好的构建过程（就是封装了上面的 steps 过程），并提供了非常简单的配置参数来使用。

使用 build template 构建容器镜像就更简单了，只需要提供代码的地址和镜像名字即可，比如下面是使用 Google kaniko 模板构建 github 源码的 yaml 文件（需要在代码根目录存在 Dockerfile 文件）

apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
  name: test-kaniko-build
spec:
  serviceAccountName: build-auth-test #认证信息
  source:
    git:
      url: https://github.com/your-user/your-repo
      revision: master
  template:
    name: kaniko
    arguments:
    - name: IMAGE
      value: us.gcr.io/my-project/my-app

2.2.2 Serving：服务系统

基于负载自动伸缩，包括在没有负载时缩减到零。

允许为多个修订版本（revision）应用创建流量策略，从而能够通过 URL 轻松路由到目标应用程序。

knative serving 功能是基于 kubernetes 和 istio 开发的

• kubernetes 来管理容器（deployment、pod）
• istio 来管理网络路由（VirtualService、DestinationRule）

可以认为 knative 提供了更高的抽象，自动封装掉了 kubernetes 和 istio 的实现细节。

serving 的核心功能是让应用运行起来提供服务。虽然听起来很简单，但包括了很多的事情：

• 自动化启动和销毁容器
• 根据名字生成网络访问相关的 service、ingress 等对象
• 监控应用的请求，并自动扩缩容
• 支持蓝绿发布、回滚功能，方便应用方法流程

2.2.3 Eventing：事件系统

使得生产和消费事件变得容易。

抽象出事件源，并允许操作人员使用自己选择的消息传递层。

serverless 最重要的是基于事件的触发机制，也就是说当某件事发生时，就触发某个特定的函数。

事件概念的出现，让函数和具体的调用方能够解耦。

函数部署出来不用关心谁会调用它，而事件源触发也不用关心谁会处理它。

为了让整个事件系统更有扩展性和通用性，knative 定义了很多事件相关的概念。简单介绍一下：

• EventSource：事件源，能够产生事件的外部系统
• Feed：把某种类型的 EventType 和 EventSource 和对应的 Channel 绑定到一起
• Channel：对消息实现的一层抽象，后端可以使用 kafka、RabbitMQ、Google PubSub 作为具体的实现。
• Subscription：把 channel 和后端的函数绑定的一起，一个 channel 可以绑定到多个knative service

补充： 

对于服务系统和事件系统，涉及到的内容比较多，后面会专门用2篇文章来讲解

三、总结：

knative的优势：

• 便利性：Knative 以 Kubernetes 作为其底层框架，因此无论是线上还是线下，任何 Kubernetes 集群，无论是云上 Kubernetes 服务还是自建 Kubernetes 集群，都可通过安装 knative 插件快速的搭建 serverless 平台。
• 标准化：Knative 联合 CNCF，把所有事件标准化，统一为 CloudEvent，提供事件的跨平台，同时让函数和具体的调用方能够解耦。
• 服务间解耦：使用 Knative 使得应用不在与底层依赖服务强绑定，可以跨云实现业务互通
• 成熟的生态：Knative 基于 Kubernetes 体系构建，与 kubernetes 生态结合更紧密；
• 自动伸缩：监控应用的请求，并自动扩缩容, 借助于istio(ambassador,gloo等)天生支持蓝绿发布、回滚功能，方便应用发布流程。
• 应用监控：支持日志的收集、查找和分析，并支持 VAmetrics 数据展示、调用关系 tracing

Knative 解决了现在Serverless 的诸多问题

如果kubernetes是容器编排的事实上的标准，那么Knative也许就是未来serverless的事实上的标准。