Knative 是 Serverless 平台，还是换个方式写 YAML？

Posted 2021-04-30 鲭物语

又来吐槽谷歌和 K8s 了，个人胡言乱语，如有理解错误还请留言指出。

在今天召开的 Google Cloud Next ’18 中，Google 发布了很多新的有意思的服务或产品，比如 K8s on-prem , serverless container 等，和 Serverless 相关的产品就有这些：

其中这个 Knative 是一个在 k8s 上实现 Serverless 的产品，本文也将重点介绍下这个产品。

Knative 不是 GCP 上的一个服务，而是一套开源平台，可以在 GitHub 上看到该项目。而且作者也不只有 Google 一家， 基本大厂都到齐了：

• Google LLC

• Pivotal Software, Inc.

• IBM Corp

• Red Hat, Inc.

• Cisco Systems, Inc.

（ Pivotal 和 Red Hat 有成为 Google 小弟的倾向，大厂也都在忙着结盟）

What's Serverless ?

首先来看一下现在的 Serverless 有多乱。有两种 Serverless ，一种是 类似 Lambda 的 FaaS（Function as a Service），另一种是 Serverless infrastructure （类似 AWS 的 fargate 和 hyper.sh/pi ）。若问什么是 Serverless，一般都会以 Lambda 为例来进行说明，大家的认识中，也基本认为 Serverless(FaaS)≒Lambda 。

关于 Serverless infrastructure ，可以参考旧闻: 。

但我不使用 AWS 啊，怎么办？放心，几乎哪个商业产品都会有人“山寨”出开源版本。

关于 FaaS，在 CNCF landscape 上至少就有这么多产品：

• Fission
  

• Kubeless

• OpenFaaS

产品虽然不少，但是大家都是各搞各的，不通用也不兼容，并没有统一标准，很容易被绑定到某一产品，万一有坑，沉没成本还是非常巨大的。

理想和现实之间的鸿沟

不管喜不喜欢，K8s 都在变成事实上的标准。

K8s 太复杂，太麻烦，不管是应用程序的打包和部署，还是基础设施的部署和实施，和传统方式都有很大的不同。学习成本高，维护成本高，要想帮助用户从传统到 K8s ，最简单快速的方式就是有一个强大的工具（最好连 YAML 都不要我们自己写）帮我们填补技能之间的“鸿沟”。

软件设计讲究抽象，不关心没必要关心的问题。只要程序能运行，没必要关心它是怎么运行的（这不是一句无责任的话，比如是否 OOM 还是要开发人员自己负责的）。

Knative 就是在 K8s 之上的又一个抽象平台。这个 K ，应该就是 K8s 的 K 。

Knative 架构

Knative 由 3 个松耦合的组件组成，每个组件都通过 K8s 的 CRD 的方式实现。

• Build

• Event

• Serving

Build

K8s 的大前提，就是基于容器的，而现在容器的镜像也是基本以 Docker 为主，因此要想上 K8s ，首先需要将应用程序打包成容器镜像，即 Build ，但并不一定直接是 docker build 命令。

构建容器镜像可以使用下面这些技术，

• Buildpack (Cloud Foundry)

• Google Container Builder

• Bazel

• Kaniko

• Jib

Buildpack 是 CF 和 Heroku 等 PaaS 平台使用很久的构建技术了。

基本 build 也就分这几步，和 Docker build 类似：

• 获取源代码

• 顺序执行构建任务

• 安装依赖

• 运行单元测试或集成测试

• 构建容器镜像

• 推送镜像或者部署镜像

Event

Serverless 基本都采用 Event Driven 架构实现，通过 Event 实现 Pub/Sub ，再通过消息来触发 Function 或应用。

Buses

Buses 提供了一个 K8s 原生的消息总线，类似 NATS 或 Kafka 。这个抽象层基于 Pub-Sub 模式，消息被发送到 Channel，Bus将消息路由给订阅者。

现在支持的 Bus 实现有 Stub （基于内存，无第三方依赖）、Kafka 和 GCP 的 PubSub 。

Sources

Source 用于对来源于 k8s 之外的消息进行抽象，并将这些消息通过 Feed 的形式路由到 k8s 集群。现在支持的 source 类型包括 Feed、EventType/ClusterEventType 和 EventSource/ClusterEventSource 。Source 的实现也有3种，包括 K8s event ， GitHub 和 GCP PubSub。K8s event 收集 K8s 的事件，GitHub 收集 PR 通知。

Flows

Flow 是一个高层次的抽象，这也是用户面对的最顶层的概念，用于规范从 Source 到 endpoint 的绑定，描述了外部事件到达目的地的路径和处理。用户可以选择 Bus 或 Channel用于进行路由。

Knative 只有一种 Flow 实现，是随 Knative event 安装的。

Serving

Serving 实现计算资源的调度和生命周期管理，网络端口映射等功能。

这些组件都通过 CRD 的方式实现。

• Service: 管理应用及其相关资源的生命周期。包括应用、路由、配置和版本管理。

• Route: 将网络 endpoint 映射到某一应用版本。

• Configuration: 管理应用的状态，这也是遵循 12 要素应用的原则，将代码和配置分离。修改配置也会创建一个新的版本。

• Revision: 为每次应用或配置的变更生成版本记录。

集成 Istio

Istio 1.0 即将发布，Knative 也深度集成了 Istio 。knative-ingressgateway 根据 host header 来对请求进行路由。

使用示例

官方有很多入门指南，帮助用户在各种环境下安装 Knative，不管是 Cloud，还是 minikube 等。一切皆在 https://github.com/knative/docs 。

如果你懒（估计大部分人都不一定去看 GitHub 的文档），这里简单介绍一下其中的一个例子。

这个示例很简单，只是输出运行时传递的环境变量 TARGET。下面是这个服务的定义：

然后通过 kubectl 命令即可创建该服务：

kubectl apply -f service.yaml

虽然不用写 K8s 的 deploy 和 service 了，可我还是得写一大坨不同语法的 YAML 文件。

因此付此图在文末。

 

“计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决，...”，我想你是知道后半句的。

---