Serverless 开源引擎Knative

Knative 是通过整合：工作负载管理（和动态扩缩）以及事件模型来实现的 Serverless 标准，也叫容器化 Serverless。

Knative 社区的主要贡献者有：Google、Pivotal、IBM、Red Hat，可见其阵容强大。还有，CloudFoundry、OpenShift 这些 PaaS 提供商都在积极地参与 Knative 的建设。

Knative 是怎么做到 Serverless 。Knative 在 Istio 的基础上，加上了流量管控和灰度发布能力、路由 Route 控制、版本 Revision 快照和自动扩缩容，就组成了 Server 集合；它还将触发器、发布管道 Pipeline 结合起来组成了 Event 集合。

Knative 的核心组件

Serving 提供了管理整个 Serverless 工作负载的能力，Knative Serving 通过自定义的一组特定对象，使用 Kubernetes CRD（自定义资源）的方式，配合上 Activator 以及 AutoScaler 等关键组件，从而实现了整个流量控制和自动扩缩容能力。

Knative Eventing 实际上是一组 API，能够帮助你使用事件驱动的方式对函数进行调用。Source 与 Sink 模型是 Knative 中最简单的事件驱动模型，除此之外，还有 Channel&Subscriptions 和 Broker&Trigger。前者提供了一种事件传输机制，能把事件分发给多个目的地或 Sink。后者跟前者类似，但不同的是后者更方便对事件进行过滤，适用于一个 namespace 下的多个事件源，然后消费者根据事件的类型、属性挑选感兴趣的事件进行消费。

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

整体而言，Tekton 补充的是 Knative 快速开发与集成的能力，提升了开发与部署的效率；

Eventing 则通过松耦合的构造以及对 CloudEvents 的支持，极大地丰富了 Knative 的应用场景；

Serving 组件贯穿到了整个 Serverless 容器的生命周期。

Knative原理

 

 

用红色表示 Knative 添加的组件，橙色表示 Istio 的组件。

首先看到 Knative 又给每个 Pod 里面添加了一个伴生容器 queue，它是专门用来实时采集反馈部署应用容器的监控指标 metrics 的，收集到的信息会反馈到 autoscale，由 autoscale 决定是否需要扩缩容。

请求，从上面的操作，浏览器的 HTTP 请求是访问 Istio-ingressGateway 的，还需要绑定域名。这是因为 Istio-ingressGateway 是域名网关，它会验证请求的域名。

MyApp 应用，接收到请求会调用用户微服务和待办任务微服务，这时就会访问 activator 了，这个是 Knative 比较重要的组件，它会 hold 住我们的请求，并查看一下目前有没有活跃的服务，如果没有，它会负责拉起一个服务，等服务启动后，再将请求转接过去。

这也就是为什么 Serverless 可以缩容到 0 的原因。

当autoscale 配置了可以缩容到 0，如果一段时间没有请求，那么每个应用都会处于很低的水位，这时 autoscale 就会缩容到 0 了。当然MyApp 应用不可以缩容到 0，因为它需要接收入口请求。

当 MyApp 有流量进来请求用户服务时，此时 activator 就会临时接收请求，让请求等待；然后通知 autoscale 扩容到 1；等待 autoscale 扩容到 1 完毕后，activator 再让用户容器处理等待的请求。

在 Knative 中每次发布服务，都会被 Revision 组件拍一个快照，这个快照可以用于我们管理版本号和灰度流量分配。“待办任务”Web 服务中的用户微服务的 2 个版本流量切换，其实就是利用 Revision 和 Route 实现的。

 

Knative 是容器 Serverless 方案，所以你在容器里面运行函数、微服务或者应用都可以，这完全取决于你的 Dockerfile 里面“编排”的是什么内容。

Knative，可以让你既部署 FaaS 也部署 BaaS。FaaS 和 BaaS 都是基于 CaaS 实现的，Knative 正是一种容器服务 Serverless 化的产物。