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设计哲学的体现——整个系统采用模块化设计,每个模块只聚焦一件事情,并且做好做到极致