原文：Knative Enables Portable Serverless Platforms on Kubernetes, for Any Cloud
作者：Dan Baskette
Kubernetes 目前如日中天，这一项目不仅在容器编排方面独占鳌头，还给基础设施自动化进程提供了可实践的原语。
但是我们注意到，开发团队在进行基于 Kubernetes 的应用部署时常有困扰。Kubernetes 毕竟只会推送容器——要想推送应用代码或者 Function，很明显就不是 Kubernetes 的能力所在了。
这样一来，就有不少厂商以 K8S 作为基础设施，展开了高级抽象方面的竞争。这也是 Knative 的着眼点。
Kelsey Hightower：Kubernetes 是一个用来构建平台的平台。它是起跑线，不是目的地。
Function 是值得注意的下一次抽象
读者可能已经注意到分布式系统世界的新晋成员：FaaS（Functions/Serverless）。Function 是一种新的抽象方式，让开发人员能够轻松的运行部署代码片段，并具备根据事件进行伸缩的能力。
这对开发人员来说是非常有吸引力的。为什么？把所有的基础设施和应用启动之前的事件处理都抽象之后，开发人员能够完全专注于解决如何使用 Function 的代码处理事件的问题。
天下自然是没有免费的午餐了，FaaS 的问题在哪里呢？
市场上有很多 FaaS 方案，每个都是独一无二的，他们有自己的 Function 触发方式，自己的可接受事件格式范围，独特的伸缩功能以及从各自角度触发，为开发人员作出的各种抽象。
如果有要用到的抽象，可以寄希望于云供应商将其打包并为你提供服务。Azure Functions、Lambda 以及 Google Cloud Function 就是这样工作的：根据事件运行 Function 代码，按需伸缩。这类产品按照用量进行计费——根据调用量收取费用。
开源社区的开发者们也加入了 FaaS 的盛宴，OpenFaaS、Fission、Kubeless 以及 Project Riff 这些项目都是构建在 Kubernetes 之上的 FaaS。这一共同的基础，也有了大同小异的产品。
在三个核心领域，每个项目都有些许差异：
这些细微差异会造成平台采用的巨大障碍。在企业开发者眼里，这一领域功能破碎，竞品众多。所以只能静观其变。
Knative 适时出现
Google 看到这种碎片化的现状，也注意到了开发人员在 Kubernetes 上进行 Function 开发的过程中对通用工具集的需求。Knative 就是基于这种需求产生的。
Knative 是一个开源软件层，帮助云服务供应商和企业平台在任意云上为开发者提供 Serverless 体验。
Pivotal 也身在其中，不但向 Knative 贡献了来自 riff 项目的事件模型，还和 Google 一起，在其它方面贡献了开发人员和代码。我们为这一项目的未来欢欣鼓舞，将 riff 和 Knative 结合在一起，酝酿成我们的新项目 Pivotal Function Service。
所以对于 Knative 来说，还需要知道点什么呢？这个项目使用 Kubernetes 作为容器编排层。它使用大家熟知的 Kubernetes 对象（Pod、Replica Set 以及 Deployment）构建应用。Istio？是的，Knative 使用 Istio 来进行网格内的路由以及 Ingress 入口管理。
但是仅仅有 Kubernetes 和 Istio 还是不够的。因此 Knative 同时还引入了三个松耦合的组件，协同对外提供一个完整的 Serverless 平台：Build、Eventing 以及 Serving。
Build：提供了一个可插入模型，用于从源码构建容器。
Eventing：让应用或者 Function 发布到或订阅事件流，事件流包括 Google Cloud Pub/Sub 以及 Apache Kafka。
Serving：为应用或 Function 提供运行和扩容以及缩容至 0 的能力。
上述元素融合形成的 Knative 又有何神通？它提供了一种较为简化的部署和运行 function 的方式，包括这些模式：
稍微深入一点看看这几个组件。
Build：源码到容器的弹性和可扩展过程
开发人员编写源码。Kubernetes 操作容器。如何完成联动？Cloud Foundry 使用 buildpack 来完成这一场景。Knative 提供一个插件模型来完成从代码到容器的构建过程。这一模型通过 CRD 实现，也就是一组 Kubernetes API 对象。这种方式提供了一个构建块，能够作为一个 CI/CD 之类的更大系统的一部分，完成源码的构建。
Knative 的 Build 组件包含 4 个主要组成部分。
描述如何获取待构建的源码。位置在 /workspace 卷中存储，这个内容会在后面的步骤中沿用。通常情况下，源码会保存在 git gcs 之类的版本控制系统中，也可以用自定义容器来访问源码。
步骤或模板：这是构建容器的实际工作。这个过程简单说来就是根据 Build 规范完成一系列步骤。换句话说，这一过程由一组可插接构建器组成，被设计用来从源码构建容器，目前这个模型支持五种构建模板，提供了可共享的构建过程：Cloud Foundry Buildpacks、Google Container Builder、Bazel、Kaniko 以及 Jib。
Service Account：用来运行构建过程的账号。
存储卷：可以定义多个卷，来提供对构建步骤的支持。这些卷可以有很多用途，例如共享 Secret 或者在多个步骤间提供缓存。
Serving：按需伸缩以及版本为基础的高级运维
自动化升级了开发者的工作流。Serving 的自动化范围覆盖了从容器到运行中的 Function 部分。它还提供了容器的快速部署，以及根据进入请求完成扩容到 N 或缩容到 0 的能力支持。Istio 在版本之间进行路由，这使得不间断升级、蓝绿部署、金丝雀测试以及回滚都成为了可能。
Serving 包含了四个 CRD：
Eventing：把订阅/发布操作进行抽象，简化开发人员工作
Function 的基本存在价值就是用来响应事件。FaaS 项目和受管服务的区别就是事件的接收以及消费方式。Knative Eventing 组件用来对事件系统的后端进行抽象，从而解放开发人员。开发人员无需了解消息平台、不用关注数据复制等问题。
Knative 提供了 CRD 用于事件的生产和消费。Eventing 组件由两类 CRD 组成：
Channel
发布/订阅模型中发布者发送消息的目标。一般来说，Channel 是一组位置用于获取或存储事件。
Bus：Channel 的后端。这是为事件提供消息平台支持的底层，可以是 Google Cloud PubSub、Apache Kafka 以及 RabbitMQ 等。
这些结合起来告知 Knative 服务，特定 Channel 的消息会被哪个应用或者 Function 消费。这是应用和 Function 的入口地址。
Feeds：事件携带的附件。
试用你能掌控的最高级抽象
Knative 是一个全新事物，但是已经有了很多资源可供学习和参考。企业开发软件数量暴涨，意味着典型情况下，公司都会谋求试用应用平台、容器编排以及 Function。Pivotal 希望在所有不同抽象中驱动开源软件的发展。Cloud Foundry、Kubernetes 以及 Knative 会成为大公司的软件构建和运行过程中的主要推手。
