谷歌发布 Knative：用于构建、部署和管理 Serverless 工作负载的 Kubernetes 框架

在 Google Cloud Next 2018 上，谷歌发布了   Knative ，将其称为“基于“Kubernetes 的平台，用来构建、部署和管理现代 serverless 工作负载”。该框架试图将开发云原生应用在三个领域的最佳实践结合起来，这三个领域指的是构建容器（和函数）、为工作负载提供服务（和动态扩展）以及事件。Knative 是由谷歌与 Pivotal 、 IBM 、 Red Hat   和 SAP 紧密协作开发的。 

Knative（发音为 kay-nay-tiv）提供了一组中间件组件，它们对于“构建现代、源码中心化以及基于容器的应用至关重要”，这些应用可以运行在企业内部、云端或第三方数据中心中。该框架是来自相同技术的一组开源组件集，能够支撑新的 GKE serverless add-on 。

按照谷歌云平台的博客文章“为您提供最好的 serverless ”的说法，Knative 专注于在云原生平台上构建和运行应用的通用任务，比如编排源码到容器构建、将服务绑定到事件生态系统、管理部署期间的路由和流量管理以及工作负载的自动扩展。该框架为工程师提供了“部署任何负载都需要的熟悉的、惯用的语言支持以及标准化的模式，这些负载包括传统的应用，也包括函数或容器。”

Knative 构建在 Kubernetes 和 Istio 之上，后者是一个开放的平台，用来连接和保护微服务（实际上是一个针对 Envoy 代理的服务网格控制面板），它的设计考虑到了多种角色通过该框架进行交互，包括开发人员、运维人员和平台提供者。

Knative 所涉及的角色（图片来源于 Knative GitHub 仓库）

Knative 致力于提供可重用的“通用模式和最佳实践组合”实现，目前可用的组件包括：

• Build ：从源到容器的构建编排；
• Eventing ：管理和交付事件；
• Serving ：请求驱动的计算，可以缩放到零。

Knative 的 Build 组件扩展了 Kubernetes 并利用了已有的原始功能，能够为工程师提供运行集群容器的能力，而这些容器是通过源构建而来的（基于之前发布的 Kaniko ）。其目标是使用 Kubernetes 原生的资源从仓库获取源码、将其构建进一个容器镜像并运行镜像。但是，文档中提到当前框架的终端用户依然要负责开发执行大多数功能所对应的组件。

不过，现在的 Knative 构建工具还没有提供完整独立的 CI/CD 解决方案，但是提供了一个低层级的构建块，它经过了专门的设计，能够支持在更大的系统中实现集成和工具化。

Eventing 系统设计为解决云原生应用开发的一系列通用需求：在开发和独立部署阶段服务保持松耦合；producer 能够在 consumer 监听之前生成事件，consumer 能够表达对某个事件或某类事件感兴趣，这些事件可能是尚未产生的；服务能够连接起来创建新的应用，在这个过程中无需修改 producer 或 consumer；能够选择来自特定 producer 所生成事件的子集。

文档表明这些设计目标是与 CloudEvents 的设计目标一致的，CloudEvents 是 CNCF Serverless WG 开发的一个通用规范，用于跨服务的协作。Eventing 仓库的文档中表明这是“一个正在进行中”的功能，目前的状态有一个已知 issue 的列表。

Knative Serving 文档表明框架的这一部分构建在 Kubernetes 和 Istio 之上，支持部署以及为 serverless 应用、函数提供服务。它的目标是提供原始的中间件，能够：快速部署 serverless 容器；自动化扩展和收缩至零；针对 Istio 组件的路由和网络编程；待部署代码和配置的时间点快照。

Heptio 的创始人兼 CTO  Joe Beda 在 Twitter 上阐述了 Serving 组件的潜在收益：

Knative 最有意思的一点在于“缩放至零”。这是通过将请求路由至一个“actuator”，让其持有请求，扩展后端，然后进行转发。我一直等待有人能构建这样的特性。

该推文继续阐述了他对 serving 组件的观察，那就是直接操纵 Istio 规则，这些规则有多个“所有者（owner）”，这一点“非常有意思，它在一定程度上将 Istio 转移到了实现细节”。其他的人，包括 Azure 容器方面的 Lead PM，表达了将 Istio 集成进框架的质疑：

我对 Knative 最大顾虑在于依赖于 Istio，这真的必要吗？

Oren Teich 是谷歌的产品管理总监，他在一系列的推文中围绕 Knative 的发布提供了更多的背景信息。他首先说谷歌团队看到 serverless 在软件开发领域推动了两个方向的重要转变：运维模型和编程模型。serverless 运维模型涉及到付费使用、扩展、安全补丁以及无维护。serverless 模型则涉及到源驱动部署、微服务、可重用的原始组件以及事件驱动 / 反应模型。随后，Teich 进一步介绍了 Knative 致力于扮演的角色：

Knative 是基础设施，允许编程模型在任何运维模型上运行。当然，现在你可能正在管理 K8S（或 GKE 或者其他类似的），但是你可以按照相同的模型来编程。

从代码库（ http://github.com/knative  ）中可以看到，它刚刚开始起步。现在的三个原始组件允许实现源 -> 容器、容器执行以及事件 -> 执行绑定。

他还指出，尽管现在并不是“很好的开发人员体验”，但是 Knative 是“构建伟大 serverless 产品的基础设施，并且会确保它们之间的编程模型可移植性”，谷歌正在不断投资以解决这些问题。

Pivotal 团队也是 Knative 一个很大的贡献者，在他们的博客文章“ Knative：用于可移植函数平台的强大构建块”中描述了他们已有的 serverless 框架项目 Riff 如何重新架构以利用 Knative ：

我们的团队贡献了很多全职的雇员来提升 Knative 中的 Serving 项目，该项目会运行动态负载。我们从 riff 项目中抽取了一个经过深思熟虑的事件模型，并帮助将其嵌入到 Knative 中。我们还在 Build 项目上做出了贡献，包括添加对 Cloud Foundry Buildpack 的支持。第一个非谷歌的 pull request 是来自我们的，持续的投资表明，我们认为这一倡议是非常重要的。

关于 Knative 的更多信息可以在项目的 GitHub 仓库找到，如何参与社区的详细信息同样可以在那里看到。

查看英文原文： Google Releases Knative: A Kubernetes Framework to Build, Deploy, and Manage Serverless Workloads