Knative:在 Kubernetes 上构建可移植 Serverless 平台

原文: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。这一共同的基础,也有了大同小异的产品。

在三个核心领域,每个项目都有些许差异:

  • 都有自己的构建服务,也就是把 Function 进行容器式构建和部署的功能。
  • 都有一种按调用需要进行扩容(或者缩容)的实现。
  • 都提供了根据事件调用 Function 的能力,事件可能是 HTTP 或者是事件中间件的发布、订阅方式。

这些细微差异会造成平台采用的巨大障碍。在企业开发者眼里,这一领域功能破碎,竞品众多。所以只能静观其变。

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 的方式,包括这些模式:

  • 从源码构建应用和 Function。
  • 包含多种构建方法(Cloud Foundry Buildpacks、Bazel、Kaniko、Dockerfiles,并可以扩展支持其他方式)。
  • 开发者能够轻松部署新的(可路由的)应用和 Function。
  • 允许应用的不间断升级。
  • 应用实例的自动伸缩。
  • 把事件绑定到 Function、应用或者容器上。
  • 当发生 HTTP 请求时触发 Function。

稍微深入一点看看这几个组件。

Build:源码到容器的弹性和可扩展过程

开发人员编写源码。Kubernetes 操作容器。如何完成联动?Cloud Foundry 使用 buildpack 来完成这一场景。Knative 提供一个插件模型来完成从代码到容器的构建过程。这一模型通过 CRD 实现,也就是一组 Kubernetes API 对象。这种方式提供了一个构建块,能够作为一个 CI/CD 之类的更大系统的一部分,完成源码的构建。

Knative 的 Build 组件包含 4 个主要组成部分。

  • 描述如何获取待构建的源码。位置在 /workspace 卷中存储,这个内容会在后面的步骤中沿用。通常情况下,源码会保存在 git gcs 之类的版本控制系统中,也可以用自定义容器来访问源码。
  • 步骤或模板:这是构建容器的实际工作。这个过程简单说来就是根据 Build 规范完成一系列步骤。换句话说,这一过程由一组可插接构建器组成,被设计用来从源码构建容器,目前这个模型支持五种构建模板,提供了可共享的构建过程:Cloud Foundry BuildpacksGoogle Container Builder、Bazel、Kaniko 以及 Jib。
  • Service Account:用来运行构建过程的账号。
  • 存储卷:可以定义多个卷,来提供对构建步骤的支持。这些卷可以有很多用途,例如共享 Secret 或者在多个步骤间提供缓存。

Serving:按需伸缩以及版本为基础的高级运维

自动化升级了开发者的工作流。Serving 的自动化范围覆盖了从容器到运行中的 Function 部分。它还提供了容器的快速部署,以及根据进入请求完成扩容到 N 或缩容到 0 的能力支持。Istio 在版本之间进行路由,这使得不间断升级、蓝绿部署、金丝雀测试以及回滚都成为了可能。

Serving 包含了四个 CRD:

  • 管理应用和 Function 的生命周期以及提供控制点。它可以处理对象的生成,来保障应用或者 Function 的任何版本更新都具备网络路由、配置以及版本支持。
  • 代码和配置的固定快照。一个版本会引用一个容器以及创建这个容器所需的内容。历史中可以包含多个版本,这样就能够支持一些蓝绿部署或者回退之类的高级运维工作。
  • 网络端点到一或多个应用版本的映射。
  • 定义了部署的最新版本以及各版本的状态。

serving

Eventing:把订阅/发布操作进行抽象,简化开发人员工作

Function 的基本存在价值就是用来响应事件。FaaS 项目和受管服务的区别就是事件的接收以及消费方式。Knative Eventing 组件用来对事件系统的后端进行抽象,从而解放开发人员。开发人员无需了解消息平台、不用关注数据复制等问题。

Knative 提供了 CRD 用于事件的生产和消费。Eventing 组件由两类 CRD 组成:

  • Channel
    • 发布/订阅模型中发布者发送消息的目标。一般来说,Channel 是一组位置用于获取或存储事件。
    • Bus:Channel 的后端。这是为事件提供消息平台支持的底层,可以是 Google Cloud PubSub、Apache Kafka 以及 RabbitMQ 等。
    • 这些结合起来告知 Knative 服务,特定 Channel 的消息会被哪个应用或者 Function 消费。这是应用和 Function 的入口地址。
  • Feeds:事件携带的附件。

eventing

试用你能掌控的最高级抽象

Knative 是一个全新事物,但是已经有了很多资源可供学习和参考。企业开发软件数量暴涨,意味着典型情况下,公司都会谋求试用应用平台、容器编排以及 Function。Pivotal 希望在所有不同抽象中驱动开源软件的发展。Cloud Foundry、Kubernetes 以及 Knative 会成为大公司的软件构建和运行过程中的主要推手。

  • Knative 文档是该项目的主要信息源。每个组件都在仓库中有自己的一席之地,让用户可以跟进最新进展。
  • 可以阅读 Pivotal 博客,Ryan Morgan 在其中发布了关于 Pivotal 在 Knative 项目中贡献的相关内容,会涉及企业应用 Serverless 的更多案例。
  • 在 Google Cloud 也有很多资料:
  • 如果想要知道 riff 项目 的信息,官方网站是最好的起步地点。其中包含了所有的文档和对 riff 仓库的引用。
  • 想要了解更多?SpringOne 平台有一套 Serverless 课程

相关

comments powered by Disqus