Serverless开源架构方案——Knative

2014年11月，AWS发布了新产品Lambda，开启了全新的Serverless时代。按照当时的描述，Lambda是一种计算服务，它按需运行用户的代码，用户无须关注底层的计算资源。继AWS Lambda之后，很多公有云提供商都推出了自己的Serverless支持。2016年Google、Microsoft Azure相继推出自己的Cloud Function服务，2017年国内公有云提供商阿里云和腾讯云也分别推出了各自的Serverless产品。

整体来说，Serverless当前还处于发展初期，正在快速地迭代，并且各个云厂商均推出一套自己的Serverless标准，所以这些Serverless是无法互通的，从而导致一旦选定了某个云厂商，就会被这个云厂商的技术体系绑住，无法自如地迁移。面对Serverless领域当前的无序和混乱，Google联合IBM、Pivotal、Redhat和SAP，一起推出了Knative，目的是实现Serverless标准化。

Knative是一个以Kubernetes和Istio为基础的Serverless开源架构方案，目的是解决Kubernetes环境下Serverless应用的构建、部署和运行。Knative和以往Serverless解决方案最大的不同是，Knative不仅管理函数，它的定位是管理所有的工作负载，除了Serverless关注的函数外，还包括普通的微服务，因此Knative强调的是通过相应的机制，用户不用再关注应用的伸缩和运维。

此外，Knative不是实现一个具体的Serverless，而是构建一个能够运行标准化Serverless的平台，Knative提供大量的扩展性支持，允许其他Serverless产品在其上运行。

架构上，Knative由Build、Serving和Eventing 3个核心组件组成。其中Build负责构建工作，把用户定义的函数和应用构建成容器镜像；Serving负责计算工作，具体包含Serverless实例的路由和访问，以及Serverless实例的按需伸缩；Eventing负责事件工作，自动完成事件的绑定和触发执行。

Serving系统基于Kubernetes和Istio进行开发，利用Kubernetes强大的容器调度和生命周期管理能力以及Istio的通信和通信链路治理能力。另外，为了屏蔽Kubernetes和Istio的复杂度，Knative Serving自身有更高一层的抽象能力，提供一组用来对应用和通信进行管理的抽象概念（可使用Kubernetes CRD对这些抽象概念进行管理）。Knative Serving的主要概念如下。

1）Route：工作负载的路由规则，对应Istio的VirtualService。

2）Configuration：应用的最新配置，对应Kubernetes的Deployment。

3）Revison：每次对工作负载进行修改的快照，对应Istio的Subset。

4）Service：对工作负载的整个生命周期进行管理。

Knative的Serving系统做的事情和Kubernetes、Istio大体相同，但通过提供更高的抽象，屏蔽了Kubernetes、Istio的细节，自动帮应用管理好Deployment、VirtualService以及auto scaling之间的关系。

auto scaling是Knative Serving实现工作负载自动伸缩的关键组件，当前还处于发展早期，有不少性能问题，很不成熟，Knative后续计划将auto scaling下沉，直接复用Kubernetes原生的auto scaling能力。

基于Kubernetes的Serverless产品和解决方案市场上已经有不少，比如Fission、Funktion、Kubeless等，但同时依赖Kubernetes和Istio这两个重量级的项目，Knative还是第一个。Kubernetes和Istio的复杂度都很高，同时基于Kubernetes和Istio，再加上Serverless自身的复杂度，会导致整个Serverless解决方案的复杂度非常高，学习曲线上也非常陡峭，因此很多人都有如下疑问和质疑：Knative中为什么采用Kubernetes和Istio这么重的通信解决方案？

从架构和通信功能实现来看，确实没有必要，为了对上层用户屏蔽底层Kubernetes和Istio的实现细节，Knative又引入了一层抽象概念，对Kubernetes的容器和通信功能进行封装。如果通信直接放在Knative层面上做，只聚焦Kubernetes平台对Serverless的通信支持，不需要平台扩展性和场景扩展性支持，架构设计上会特别简单，同时灵活性也会比现在好。

从短期和静态的角度看，Knative引入Istio，确实没有那么大的必要，因为增加了复杂度，减少了灵活性。但从云计算基础设施的大趋势来看，Kubernetes已经成为容器调度和生命周期管理的事实标准，可以看成云原生时代的Linux操作系统；Istio虽然产生时间不长，但已经显现出强大的发展势头，当前在Service Mesh和Kubernetes生态中的地位已经不可撼动，可以看成云原生时代的TCP/IP协议。

因此，如果从云计算的发展趋势上看，通信功能会被Istio完全接管，并下沉为基础设施的一部分。在通信层面，Istio肯定更聚焦、更专业，Knative从大趋势出发，直接复用Istio的通信层功能，避免后续架构上的修改和返工，可以将自身聚焦到Serverless层面的功能和生态打造上。从架构的角度看，这也是Unix设计哲学的体现——整个系统采用模块化设计，每个模块只聚焦一件事情，并且做好做到极致。