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

by

• Daniel Bryant

摘要：

在Google Cloud Next 2018上，谷歌发布了Knative，将其称为“基于“Kubernetes的平台，用来构建、部署和管理现代serverless工作负载”。该框架试图将构建、服务请求以及事件相关的最佳实践集合起来。Knative是由谷歌与Pivotal、IBM、Red Hat和SAP紧密协作开发的。

在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