初识 Knative

Knative 是谷歌开源的 Serverless 架构方案，旨在供应一套大略易用的 Serverless 方案，把 Serverless 标准化。
目前参与的公司紧张是 Google、Pivotal、IBM、Red Hat，2018 年 7 月 24 日对外发布，当前还处于快速发展的阶段。

这是 Google Cloud Platform 宣告 knative 时给出的先容：

Developed in close partnership with Pivotal, IBM, Red Hat, and SAP, Knative pushes Kubernetes-based computing forward by providing the building blocks you need to build and deploy modern, container-based serverless applications.

可以看出，Knative 是为理解决容器为核心的 Serverless 运用的构建、支配和运行的问题。

项目地址： https://github.com/knative

Serverless 的观点已经涌现蛮久了，为了理解 Serverless, 可以从运用开拓者的角度来看，利用 Serverless 框架之后，运用开拓者的全体操作流程就变成了：

~ # 编写 code 和 configuration 文件~ # faascli build~ # faascli deploy~ # curl http://myapp.com/hellohello, world from Awesome FaaS App!

可以看到用户只须要编写代码（或者函数），以及配置文件（如何 Build、运行以及访问等声明式信息），然后运行 Build 和 Deploy 就能把运用自动支配到集群（可以是公有云，也可以是私有的集群）。

其他事情都是 Serverless 平台（比如: 这里的 Knative）自动处理的，这些事情包括：

Knative 建立在 Kubernetes 和 Istio 平台之上，利用 Kubernetes 供应的容器管理能力（Deployment、Replicaset、和 Pods 等），以及 Istio 供应的网络管理功能（Ingress、LB、Dynamic Route 等）。

Knative 核心观点和事理

为了实现 Serverless 运用的管理，Knative 把全体系统分成了三个部分：

Build 的功能是把用户的代码自动化构建成容器镜像，初次听起来很奇怪，有了 Docker 之后有一个 Dockerfile 不就能构建容器了吗？为什么还须要一个新的 Build 系统？

Knative 的特殊之处在于两点：一是它的构建完备是在 Kubernetes 中进行的，和全体 Kubernetes 生态结合更紧密；其余，它旨在供应一个通用的标准化的构建组件，可以作为其他更大系统中的一部分。

正如官方文档中的说的那样，是为了定义标准化、可移植、可重用、性能高效的构建方法：

The goal of a Knative build is to provide a standard, portable, reusable, and performance optimized method for defining and running on-cluster container image builds.

Knative 供应了 Build CRD 工具，让用户可以通过 YAML 文件定义构建过程。
一个范例的 Build 配置文件如下：

apiVersion: build.knative.dev/v1alpha1kind: Buildmetadata: name: example-buildspec: serviceAccountName: build-auth-example source: git: url: https://github.com/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', 'hello-example', 'build']

个中， serviceAccountName 是构建过程中须要用到的密码和认证信息（比如连接到 Git Repo 的 SSH Keys 、Push 镜像到 Registry 的用户名和密码等）；

source 是代码信息，比如这里的 Git 地址和分支；steps 是真正运行过程中的各个步骤。

这个示例中的步骤只是作为 Demo，真正的构建过程一样平常是 Pull 代码、 Build 镜像和 Push 镜像到 Registry 等逻辑。

由于大部分的构建过程都是同等的，因此 Knative 还供应了 Build Template 的观点， Build Template 封装了预先定义好的构建过程（便是封装了上面的 steps 过程），并供应了非常大略的配置参数来利用。

利用 Build Template 构建容器镜像就更大略了，只须要供应代码的地址和镜像名字即可。
比如：下面是利用 Google Kaniko 模板构建 Github 源码的 YAML 文件（须要在代码根目录存在 Dockerfile 文件）。

apiVersion: build.knative.dev/v1alpha1kind: Buildmetadata: name: kaniko-buildspec: serviceAccountName: build-bot source: git: url: https://github.com/my-user/my-repo revision: master template: name: kaniko arguments: - name: IMAGE value: us.gcr.io/my-project/my-appServing：做事系统

Serving 的核心功能是让运用运行起来供应做事。

虽然听起来很大略，但这里包括了很多的事情：

Knative Serving 功能是基于 Kubernetes 和 Istio 开拓的，它利用 Kubernetes 来管理容器（Deployment、Pod）， Istio 来管理网络路由（VirtualService、DestinationRule）。

由于 Kubernetes 和 Istio 本身的观点非常多，理解和管理起来比较困难，Knative 在此之上供应了更高一层的抽象（这些对应是基于 Kubernetes 的 CRD 实现的）。
这些抽象出来的观点对应的关系如下图：

Configuration：运用的最新配置，也便是运用目前期望的状态，对应了 Kubernetes 的容器管理（Deployment）。
每次运用升级都会更新 Configuration，而 Knative 也会保留历史版本的记录（图中的 Revision），结合流量管理，Knative 可以让多个不同的版本共同供应做事，方便蓝绿发布和滚动升级Route：运用的路由规则，也便是进来的流量如何访问运用，对应了 Istio 的流量管理（VirtualService）Service：把稳这里不是 Kubernetes 中供应做事创造的那个 Service，而是 Knative 自定义的 CRD，它的全称目前是 Services.Serving.Knative.Dev 。
单独掌握 Route 和 Configuration 就能实现 Serving 的所有功能，但 Knative 更推举利用 Service 来管理，由于它会自动帮你管理 Route 和 Configuration

一个 hello world 的 Serving 配置如下所示：

apiVersion: serving.knative.dev/v1alpha1kind: Servicemetadata: name: helloworld-go namespace: defaultspec: runLatest: configuration: revisionTemplate: spec: container: image: docker.io/{username}/helloworld-go env: - name: TARGET value: "Go Sample v1"

看起来和 Kubernetes 的 Pod 定义非常类似，但是它会帮你管理 Deployment、Ingress、Service Discovery、Auto Scaling…… 从这个角度来看，可以认为 Knative 供应了更高的抽象，自动帮你封装掉了 Kubernetes 和 Istio 的实现细节。

下面这张图先容了 Knative Serving 各组件之间的关系：

可以看到，每个 Revision 对应了一组 Deployment 管理的 PodPod 会自动申报请示 Metrics 数据到 Autoscaler，Autoscaler 会根据要求量和资源利用情形修正 Deployment 的 Replicas 数量，从而实现自动扩缩容。
Serverless 一个主要的特定是它会 Scale to 0 的，也便是当运用没有流量访问时，它会自动销毁所有的 PodActivator 比较有趣，它是为了处理 Scale to 0 而涌现的。
当某个 Revision 后面的 Pod 缩容到 0 时，Route 的流量会指向 Activator，Activator 吸收到要求之后会自动拉起 Pod，然后把流量转发过去Route 工具对应了 Istio 的 DestinationRoute 和 VirtualService，决定了访问运用的流量如何路由Eventing：事宜系统

Serving 系统实现的功能是让运用/函数能够运行起来，并且自动伸缩，那什么时候才会调用运用呢？除了我们熟习的正常运用调用之外，Serverless 最主要的是基于事宜的触发机制，也便是说当某件事发生时，就触发某个特定的函数。

事宜观点的涌现，让函数和详细的调用方能够解耦。
函数支配出来不用关心谁会调用它，而事宜源触发也不用关心谁会处理它。

Note：目前 Serverless 的产品和平台很多，每个地方支持的事宜来源以及对事宜的定义都是不同的（比如 AWS Lambda 支持很多自己产品的事宜源）。
Knative 自然也会定义自己的事宜类型，除此之外，Knative 还联合 CNCF 在干变乱标准化的事情，目前的产出是 CloudEvents 这个项目。

为了让全体事宜系统更有扩展性和通用性，Knative 定义了很多事宜干系的观点。
我们先来先容一下：

它们之间的关系流程图如下：

Bus 是 Knative 内部的事宜存储层，用户可以选择自己感兴趣的实现，目前支持的办法有：Stub（在内存中实现的大略系统）、 Kafka 、 Google PubSub 。
如果想要事宜能够正常运行，必须在 Knative 集群中安装个中一个 Bus 实现办法。

有了 Bus 之后，我们就可以监听外部的事宜了。
目前支持的事宜源有三个： Github （比如 Merge 事宜，Push 事宜等），Kubernetes（Events），Google PubSub（系统），后面还会不断接入更多的事宜源。

如果要想监听对应的事宜源，须要在 Knative 中支配一个 Source Adaptor 的 Pod，它卖力从外部的系统中读取事宜。

读取后的事宜，会根据用户配置的 Feed 工具（里面包括了事宜源和 Channel 的对应关系），找到对应的 Channel，然后把发送到这个 Channel 中（Channel 的终极是存储在后真个 Bus 系统里的）。

然后，Knative 会根据 Subscription 的配置，不断从 Channel 中读取事宜，然后把事宜作为参数调用对应的函数，从而完成了全体事宜的流程。

Knative 是 2018 年 7 月对外开放，虽然内部已经开拓一段韶光，但是目前还处于非常早前的阶段，各个版本间的变革也比较大。

Knative 也是脱产于 Google 和 CNCF，因此全体社区运行办法和目标与之前的 Kubernetes 以及 Istio 非常相似。
社区根据组件分成多个 Working Group，每个 Group 独立卖力自己的功能，所有的开源活动（文档、***、代码）都是开放的。
其余，CloudEvents 作为 Knative 依赖的标准，目标也是成为 CRI、CNI、CSI 这种类似的标准。

Knative 社区目前非常生动，从下面发行版本的速率也可以看得出来，而且入门的文档和教程都已经非常全面。
Knative 各版本详细发行韶光节点如下：

Knative 基于 Kubernetes 和 Istio 的 Serverless 开源实现，目标是供应更高层次的抽象，让开发者无需关注根本举动步伐（虚拟机或者容器，网络配置，容量方案），而专注于业务代码即可。
更多关于 Knative 的利用场景可以参考 AWS Lambda 或者其他干系的文档，这里不再赘述，紧张讲讲 Knative 目前的局限性或者问题：

性能问题一贯是 Serverless 被人诟病的一点，也是目前它不能广泛用于运用做事上的决定性缘故原由。
互联网的运用大多数有高并发、高性能的哀求，Serverless 全体网络链路很长，容器启停须要额外的韶光，还无法知足互联网运用的哀求。

针对这一点，很多 Serverless 框架也在不断地做改进，比如不断精简容器的启动韶光、容器启动之后会做缓存等，比如 Nuclio 就流传宣传自己的平台比 AWS Lambda 要快 10 倍以上。

相信随着 Serverless 的不断演进，性能问题会不断优化，至于能不能达到互联网运用的哀求，还要韶光给我们答案。

基于 Kubernetes 的 Serverless 组件非常多，比如 Kubeless。
但是基于 Kubernetes 同时又基于 Istio，目前 Knative 还是第一个这么做的。

有些人的疑问在于，Knative 真的有必要基于 Istio 来做吗？对付这个问题，我个人的意见是必要的。

Istio 作为集群根本举动步伐通用网络层的地位已经开始显露，相信在未来的发展中接管度会越来越大，并逐渐巩固自己的地位。
虽然现阶段来说，很多人并不非常熟习 Istio 的情形，但是从长远角度来看，这一点将是 Knative 的一个上风所在。

其余，基于 Istio 构建自己的 Serverless 做事，也符合目前软件行业不要重复造轮子的思路。
Istio 在集群的网络管理方面非常精良（智能路由、负载均衡、蓝绿发布等），基于 Istio 来做可以让 Knative 不用重复事情就能直策应用 Istio 供应的网络通用功能。

这一点和上面类似，Knative 下面已经有两个非常繁芜的平台： Kubernetes 和 Istio 。
这两个平台的理解、构建、运维本身就很繁芜，如今又加上 Knative 全体平台，须要理解的观点都要几十个，更不要提落地过程中会碰着的各种问题。

对付公有云来说， Kubernetes 和 Istio 这些底层平台可以交给云供应商来掩护（比如 Google Function），但是对付内部构建来说，这无疑提高了全体技能门槛，对系统管理职员的哀求更高。

如何安装支配全体集群？如何对集群做升级？涌现问题怎么调试和追踪？怎么更好地和内部的系统对接？这些系统的最佳实践是什么？怎么做性能优化？所有这些问题都须要集群管理职员思考并落实。

相对付编写微做事来说，单个函数的繁芜度已经非常低，但是当非常多的函数须要共同事情的时候，如何管理这些函数就成了一个必须办理的问题。

针对 Serverless 衍生出来的运维工具和平台还不足多，如何调试线上问题还没有看到非常好的办理方案。

这方面的问题都不是大事情，随着 Knative 版本的迭代，在很快的韶光都能够办理。