David 译 分布式实验室 

Kubernetes近来受到高度关注，且已经成为容器领域的主要抽象方案。考虑到Kubernetes强大的容器调度能力，及其为基础设施自动化带来的坚实基础，这一切自然是在情理之中。
不过我们注意到，开发团队在使用普通Kubernetes进行应用程序部署时，往往会遇到困难。推送容器本身虽然无甚挑战，但如果大家希望利用其推送应用程序代码——或者函数，那么单凭Kubernetes自身就不太够用了。
正因为如此，才会有大量供应商围绕Kubernetes推出层级更高的抽象技术，Knative[1]应运而生。
函数，您需要关注的下一个抽象概念

大家可能已经注意到，在最近的分布式系统世界当中，函数即服务（‘函数’或者‘无服务器’）已经成为一种新的抽象趋势。其允许开发人员更轻松地运行并部署代码片段，且这些代码片段将能够快速实现规模伸缩以响应事件需求。
这对开发人员而言，无疑是个极具吸引力的主张。为什么？因为将一切基础设施与事件处理流程抽象出来（直到其触发函数为止）意味着开发人员能够完全专注于自己的功能性代码——是的，再没有任何其它事务会分散他们的精力。

当然，世界上没有免费的午餐。那么，函数的复杂性又体现在哪里？
目前市面上存在着大量函数即服务选项。而对每款产品而言，其在触发函数的具体方法、可以处理的事件格式、扩展能力以及帮助开发人员抽象出的实际复杂度数量方面皆有所区别。
对于具备实用性的抽象，公有云供应商往往会将其打包为一项服务。其中包括Azure Functions（微软）、Lambda（AWS）以及Google Cloud Functions等等。每种服务都运行函数代码以唾液事件，并根据当前需求进行扩展。此类产品采用务实的计费方式——用户需要按照函数的具体调用次数付费。
开源开发人员也投身于无服务器阵营，并开发出OpenFaaS、Fission、Kubeless以及Project riff等项目。这一切都是函数即服务的典型例子，且建立在Kubernetes基础之上。但各项目之间的共通之处也就仅此而已。
各个项目在以下三大核心领域都有着略有区别的实现方式：

• 各项目都拥有一种构建服务，或者利用函数代码构建并部署容器的方法。

• 各项目都拥有一种实现扩展伸缩以响应对函数调用需求的方法。

• 各项目都提供一种基于事件的函数调用方法，例如包含事件代理的http或发布/订阅机制。

这些微妙的差异实际上成了采用过程中的巨大障碍。企业开发者们意识到这种碎片化问题的存在，因此他们决定暂不采取行动，而是静待市场上出现真正的执行标准。
Knative——今日的主角出场

谷歌公司当然也发现了这个问题，并意识到需要提供通用型工具以帮助开发人员在Kubernetes上构建函数。而其解决方案，正是Knative（发音为kay-nay-tiv）。
Knative是一个开源软件层，旨在帮助云服务供应商及企业平台运营商为任何云环境中的开发人员提供无服务器体验。
在Pivotal公司，我们已经将自己的事件模型由Project riff移交给了Knative。此外，我们还与谷歌一道在Knative项目的多个领域开展合作，包括为其提供开发人员与代码支持。我们对这个项目的前景感到非常兴奋，且正在尝试将Project riff与Knative结合起来，从而为我们即将推出的Pivotal函数服务[2]建立基础。
那么，关于Knative大家有必要了解哪些信息？首先，该项目利用Kubernetes作为容器编排层，且在我们所熟知的Kubernetes原语（Pod、副本集、部署等）之上构建函数。那么Istio呢？没错，Knative利用Istio实现集群内的网络路由以及用于进入集群的入口连接。
不过，Kubernetes与Istio还远远不够。因此，Knative还添加了其它三种松散耦合的组件以提供完整的无服务器平台：Build、Eventing以及Serving。

• Build提供一套可插入模型，用于利用源代码构建容器。

• Eventing允许各应用/函数发布及订阅事件流，例如Google Cloud Pub/Sub以及Apache Kafka。

• Serving提供相关能力，用以轻松运行应用程序/函数并对其进行规模伸缩。

如此一来，Knative就获得了轻松易行的函数部署与运行方法，具体包括以下模式：

• 利用源代码构建应用程序/函数。

• 通过可扩展性实现多种构建方法（Cloud Foundry Buildpacks、Bazel、Kaniko以及Dockerfiles等等）。

• 允许开发人员轻松部署新的（可路由）应用程序/函数。

• 可实现应用程序的零停机升级。

• 自动扩展应用程序实例。

• 为函数、应用或容器构建事件。

• 通过HTTP请求触发函数调用。

下面，我们将更具体地聊聊Build、Eventing与Serving。
Build：利用灵活及可扩展的源代码实现容器自动化
开发人员负责编写源代码。Kubernetes负责处理容器。那么，我们该如何调和这种不匹配问题？很简单，利用开发人员编写的源代码构建容器。（听起来很熟悉吧？Cloud Foundry就在使用buildpack实现这一效果。）Knative提供一套专门用于立足源代码构建容器的可插拔模型。该模型通过定制化资源进行定义，属于一套Kubernetes API对象集合。这种方法能够提供基础构建块，确保将源代码作为CI/CD管道等更大规模系统中的组成部分。
以下为利用Knative进行构建的四大主要元素:

• 描述在何处查找构建所使用的源代码。该位置会被存储在/workspace分卷当中，并在后续步骤内被加以使用。源代码的的具体存储位置为各类源代码控制系统（例如GIT、GCS或者其它可访问的源代码自定义容器）。

• 步骤或模板。 即构建容器的实际工作。该流程体现为一系列遵循构建器规范的步骤。您亦可将其视为一套构建模板，由可插拔构建器组成，专门用于利用源代码构建容器。目前，该模型支持五种可共享构建过程的构建模板，分别为之前提到的Cloud Foundry Buildpacks、Google Container Builder、Bazel、Kaniko以及Jib。

• 服务账户。此账户用于运行构建结果。

• 分卷。提供在构建过程当中可供使用的各分卷的定义能力。这些分卷可以具有多种用途，例如共享秘密凭证或为多个步骤提供缓存功能。

Serving：可实现高级操作的按需扩展与版本控制
自动化能力将有效改善开发人员的工作流程。Serving能够以自动化方式实现从容器到函数运行的整个流程。此外，其还能够快速部署容器并执行规模伸缩，甚至可根据传入请求将规模降低至零。Istio在不同修订版本（函数版本）之间进行流量路由，从而实时零停机更新、蓝/绿部署、部分负载测试以及代码回滚等效果。
Serving拥有以下四项定制化资源定义：

• 管理应用程序/函数生命周期的资源，并提供单点控制。其负责处理对象的创建，旨在确保应用程序/函数具备网络路由、配置以及服务更新等版本控制能力。

• 为代码及其配置提供一套不可变快照。各修订版本将引用容器镜像以及由此创建的build。各修订版本之间可共存于同一历史记录之内，从而实现蓝/绿部署或者回滚等高级操作。

• 能够将网络端点映射至一个或多个函数修订版本。

• 定义所需的最新部署状态，并在状态更新时定义修订版本的状态。

Eventing：对发布/订阅细节进行抽象处理，帮助开发人员摆脱相关负担
函数的存在是为了响应事件。FaaS项目与托管服务之间的实现差异，集中体现在获取并使用这些事件的具体方式身上。Knative Eventing组件旨在对这些事件进行抽象处理，从而帮助开发人员摆脱与后端相关的具体细节。如此一来，开发人员将不必费心于挑选消息传递平台以及数据复制方法等工作。
Knative为开发人员提供Kubernetes定制化资源，这些资源可用于事件的生产与消费。此类定制化资源主要分为以下两大类别：
频道：

• 即发布者在发送消息时面向的发布/订阅目标（主题）。从本质上讲，频道可被视为获取或放置事件的位置目录。

• 总线。各频道的后端供应方。其属于支持事件的消息收发平台，具体选项包括Google Cloud PubSub、Apache Kafka以及RabbitMQ等等。

• 为应用程序/函数指定Knative服务，并为其指明立足频道所传递的具体消息。其属于应用程序/函数的入口地址。

馈送。将事件源中的单一事件添加至某一操作。
尽可能提高抽象水平
Knative是一套全新的解决方案，但目前已经存在大量关于具体使用方式及使用理由的指导性资源。总结而言，企业正编写越来越多的软件方案，这意味着典型的现代企业必然拥有自己的应用程序平台、容器编排工具与函数。Pivotal希望立足这些不同抽象对象推动开源创新。在这项工作当中，Cloud Foundry、Kubernetes以及现在的Knative都将扮演重要的角色，帮助各大公司对自身构建及运行软件的具体方式进行现代化改造。
相关链接：

1. http://github.com/knative

2. https://pivotal.io/platform/pivotal-function-service

原文链接：https://thenewstack.io/knative-enables-portable-serverless-platforms-on-kubernetes-for-any-cloud/