您可能听说过Knative– Kubernetes 之上的无服务器应用程序开发平台。我知道有很多流行语,但本质上它提供了多个 API 来部署您的应用程序,而无需(过多地)考虑 Kubernetes 机制。

目前,Knative 可以分为三个组件:

• Knative Serving- 部署基于 HTTP 的应用程序 - 想想 AWS Lambda 或 Google Cloud Functions

• Knative Build- 帮助您完全避免接触容器。您提供代码,其余的将自动发生。

• Knative Eventing- 帮助您构建事件驱动的应用程序💥

你可能知道我是事件驱动架构的忠实粉丝。这就是为什么我们将在这篇文章中稍微探索一下_Knative Eventing_。

我需要什么?

由于 Knative 作为 Kubernetes 之上的无服务器平台的性质,您需要 -🎉 - 一个安装了 Service Mesh 的 Kubernetes 集群,例如Istio。不用担心,如果您不知道 Istio 的全部内容。请暂时忽略它,并将其视为要求。

对于尚未自豪地拥有 Kubernetes 集群的每个人,我建议在Google Cloud Platform (GCP)上创建一个。一般来说,需要以下步骤:

1. 使用 Istio 插件在 GCP 上创建集群

2.安装Knative

为了保持干燥而不是重复内容,您可以在 Knative 的官方文档中找到一个很好的描述:Install on Google Kubernetes Engine。

⚠️ 不要被节点自动扩缩配置(1 - 10 个节点)吓倒。对于此演示,您只需删除--enable-autoscaling --min-nodes=1 --max-nodes=10并将其替换为--num-nodes 1。这会产生一个单节点集群,足以满足我们在这里的小探索。

我们的目标

那么我们在这里的目标是什么?我想到了一个简单的场景,它展示了所有重要的关键部分,而不涉及太多的仪式。结果是以下简单的用例:

建立一个发射器,它每分钟发送一个 JSON 格式的事件,并拥有一个自动启动并仅显示相应事件的应用程序。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--rYkCRSFJ--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws。 com/i/l63haadl1kpelrubdrho.png)

让事件流...

上面描述的用例可以转换为以下架构,该架构演示了如何使用 Knative Eventing 实现事件流:

[](https://res.cloudinary.com/practicaldev/image/fetch/s--qWHhIfGN--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws。 com/i/n7cft44p1bjqnrpdwir1.png)

尽管这可能看起来很复杂,但引入的Broker和Trigger间接寻址最终还是很有意义的。让我们逐条分析。

经纪人

Broker充当中央事件网关。它从源接收事件并将其委托给对事件感兴趣的各个订阅者。

在我们的场景中,我们将通过执行以下命令在default命名空间中创建代理:

kubectl label namespace default knative-eventing-injection=enabled

您可以通过以下方式验证代理的创建:

$ kubectl get broker
NAME      READY   REASON   HOSTNAME                                   AGE
default   True             default-broker.default.svc.cluster.local   22s

事件源

作为事件的起源。想象一种微服务架构。在这种情况下,您将拥有多个此类事件源。他们每个人都会发出特定领域的事件。

建立实际事件源有多种可能性。除了编写自己的源代码之外,Knative Eventing 还附带了一堆预定义的源代码。仅举几例:

• GitHub:存储库/组织事件,例如:PR 创建、提交推送等。

• Apache Kafka:将 Kafka 消息流式传输到 Knative

• Kubernetes:将 Kubernetes 集群事件带到 Knative

您可以在Knative 文档中找到现有资源的完整列表。

另一个有趣的预定义组件是Cron Job源。它允许及时发出消息。这正是我们想要在我们的演示中使用的一个:

# filename: source.yaml
apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
  name: event-emitter
spec:
  schedule: "* * * * *"
  data: '{"message": "Hello world!"}'
  sink:
    apiVersion: eventing.knative.dev/v1alpha1
    kind: Broker
    name: default

这是定义Cron Job源所需的一切。您可以通过以下方式应用它:

kubectl apply -f source.yaml

之后,event-emitter将...

• ... 每分钟发送data中定义的事件

• ... 将此消息发送到default broker

服务

该服务是您的实际应用程序。负责接收相应事件并执行某些业务逻辑的那个。在我们的示例中,我们只使用一个现有的容器图像,该图像接收一个接收到的事件并将其打印在stdout上。

定义如下:

# service.yaml
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: dumper
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display

执行kubectl apply -f service.yaml后服务将处于活动状态,并且可以通过以下方式消化日志:

kubectl logs -f  -l serving.knative.dev/service=dumper -c user-container --since=10m

虽然我们已经应用了Broker、Source和Service,但您可能想知道为什么还看不到任何输出。这导致我们找到最后一个缺失的拼图,Trigger

触发器

老实说,Trigger是一只有趣的野兽。它充当一个间接层,您可以在其中定义_哪些事件应该发送到哪个服务_。它基本上将相应的事件类型绑定到特定的服务。很好,声明性的,是吗?

# trigger.yaml

apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
  name: trigger
spec:
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1alpha1
      kind: Service
      name: dumper

因此,在kubectl apply -f trigger.yaml之后,我们基本上创建了一个组件,该组件在每次新事件到达时_触发_服务。从现在开始,您应该会在服务的日志中看到输出。

结论

在我之前的一些客户项目中,我们自己创建了这样一个事件基础设施。你可能已经有建造这样一个东西的经验。这是相当多的工作,对吧?建立代理基础设施(通过RabbitMQ、Apache Kafka等)并手动定义所有事件路由,仅列举整体工作的两个方面。 Knative Eventing 附带正确的原语恕我直言。它使您能够以一种很好的、声明性的方式执行您过去必须手动完成的所有工作。

我的假设是 Knative 总体上面临着光明的未来。由于 Kubernetes 的高学习曲线,许多工程师只是避免接触 Kubernetes。您可能会再次考虑生态系统。 Knative 可让您专注于交付代码,而无需大量基础设施开销。

您对 Knative 和 Knative Eventing 的总体印象如何?