Events for Cloud Run for Anthos Codelab

1. 简介

6a5cf23c8e20491f.png

借助 Cloud Run，您可以在全托管式环境中运行无状态容器。它基于开源 Knative 构建而成，可让您选择使用 Cloud Run 在全托管式环境中运行容器，或使用 Cloud Run for Anthos 在您的 Google Kubernetes Engine 集群中运行容器。

借助 Events for Cloud Run for Anthos，您可以轻松将 Cloud Run 服务与来自各种来源的事件相关联。它可让您构建微服务松散耦合且分布式的事件驱动型架构。它还会为您处理事件提取、传送、安全、授权和错误处理，从而提高开发者的敏捷性和应用弹性。

在此 Codelab 中，您将了解 Events for Cloud Run for Anthos。更具体地说，您将了解如何监听来自 Cloud Pub/Sub、审核日志、Cloud Storage 和 Cloud Scheduler 的事件，以及如何生成/使用自定义事件。

学习内容

  • Events for Cloud Run for Anthos 的长期愿景
  • Events for Cloud Run for Anthos 的当前状态
  • 创建 Cloud Run 接收器
  • 创建 Cloud Pub/Sub 事件触发器
  • 创建审核日志事件触发器
  • 为 Cloud Storage 创建事件触发器
  • 创建 Cloud Scheduler 事件触发器
  • 生成和使用自定义事件

2. 长期愿景

随着我们采用无服务器架构，事件成为解耦微服务之间通信的重要组成部分。Events for Cloud Run for Anthos 使事件成为 Cloud Run for Anthos 产品中的一等公民，从而可以轻松构建事件驱动型无服务器应用。

Events for Cloud Run for Anthos 可实现从打包或应用创建的事件源到集群内和集群外消费者的可靠、安全且可扩缩的异步事件传送。

ce389bcafba6d669.png

Google Cloud 来源

属于 Google Cloud 的产品

Google 来源

Google 拥有的产品（例如 Gmail、环聊、Android 管理服务等）中的事件源

自定义来源

非 Google 拥有的产品，由最终用户自行创建的事件源。这些可以是用户开发的 Knative Source，也可以是集群上运行的任何其他可以生成 Cloud Event 的应用。

第三方来源

既不归 Google 所有也不归最终用户所有的活动来源。这包括由第三方提供商、合作伙伴或 OSS 社区拥有和维护的热门事件源，例如 GitHub、SAP、Datadog、Pagerduty 等。

为了实现跨服务互操作性，事件会标准化为 CloudEvents v1.0 格式。CloudEvents 是一种与供应商无关的开放规范，用于以通用格式描述事件数据，从而实现跨服务、平台和系统的互操作性。

Cloud Run 的事件符合 Knative Eventing 标准，可实现容器在其他基于 Knative 的实现之间进行移植。这提供了一个与云无关的统一框架，用于以声明方式将事件生成方与事件使用方连接起来。

3. 当前状态

此预览版是第一个提供初始长期功能集的版本。

b1dd0d8a73185b95.png

为了让用户能够构建事件驱动型无服务器应用，我们最初的重点是以下两个方面：

  1. 提供广泛的 Google Cloud 来源生态系统，使 Anthos 集群上的 Cloud Run 服务能够对 Google Cloud 服务的事件做出响应。
  • 最初，来自 Google Cloud 来源的事件通过 Cloud Audit Logs (CAL) 传送，从而支持广泛的事件来源。来自这些来源的事件传送延迟时间和可用性与 Cloud Audit Logs 的延迟时间和可用性相关。每当发布来自 Google Cloud 来源的事件时，系统都会创建相应的 Cloud Audit Logs 日志条目。
  • 除了 Cloud Audit Logs 之外，还提供一流的支持来使用来自 Cloud Storage、Cloud Pub/Sub 和 Cloud Scheduler 的事件。随着我们从用户转化历程和反馈中了解更多信息，我们将继续添加更多一流来源，不断扩大此来源生态系统。
  1. 通过发布到命名空间级集群本地代理网址，使最终用户应用和服务能够发出自定义事件。

底层传送机制使用客户项目中可见的 Cloud Pub/Sub 主题和订阅。因此，此功能提供的交付保证与 Cloud Pub/Sub 相同。

事件触发器提供了一种订阅事件的方式，以便将与触发器过滤条件匹配的事件传递到触发器指向的目标（或接收器）。

所有事件均以 Cloud Events v1.0 格式传送，以实现跨服务互操作性。

我们将以迭代方式不断提供更多价值，直至正式版发布及发布后。

4. 设置和要求

自定进度的环境设置

  1. 登录 Cloud 控制台，然后创建一个新项目或重复使用现有项目。 如果您还没有 Gmail 或 Google Workspace 账号，则必须创建一个。

96a9c957bc475304.png

b9a10ebdf5b5a448.png

a1e3c01a38fa61c2.png

  • 项目名称是您在此项目中的显示名称。只要您遵循其命名惯例，就可以使用任何名称，并且可以随时更新。
  • 项目 ID 在所有 Google Cloud 项目中必须是唯一的，并且不可变（一经设置便无法更改）。Cloud 控制台会自动生成一个唯一字符串；通常情况下，您无需关注该字符串。在大多数 Codelab 中，您都需要引用项目 ID（通常用 PROJECT_ID 标识），因此如果您不喜欢该 ID，可以再随机生成一个 ID，也可以尝试使用自己的 ID，看看是否可用。然后，项目创建后，ID 会处于“冻结”状态。
  1. 接下来，您需要在 Cloud 控制台中启用结算功能，才能使用 Google Cloud 资源。

运行此 Codelab 应该不会产生太多的费用（如果有费用的话）。请务必按照“清理”部分中的所有说明操作，该部分介绍了如何关停资源，以免产生超出本教程范围的结算费用。Google Cloud 的新用户符合参与 $300 USD 免费试用计划的条件。

启动 Cloud Shell

虽然可以通过笔记本电脑对 Google Cloud 进行远程操作，但在此 Codelab 中，您将使用 Google Cloud Shell，这是一个在云端运行的命令行环境。

在 GCP 控制台中，点击右上角工具栏上的 Cloud Shell 图标：

bce75f34b2c53987.png

预配和连接到环境应该只需要片刻时间。完成后，您应该会看到如下内容：

f6ef2b5f13479f3a.png

这个虚拟机已加载了您需要的所有开发工具。它提供了一个持久的 5GB 主目录，并且在 Google Cloud 中运行，大大增强了网络性能和身份验证功能。只需一个浏览器，即可完成本实验中的所有工作。

5. 启用 API，设置可用区和平台

设置项目 ID 并安装 Alpha 版组件

在 Cloud Shell 中，GOOGLE_CLOUD_PROJECT 应该已设置为您的项目 ID。如果不是，请确保已设置该项目 ID，并且您的 gcloud 已配置为使用该项目 ID：

export GOOGLE_CLOUD_PROJECT=your-project-id
gcloud config set project ${GOOGLE_CLOUD_PROJECT}

确保已安装 Alpha 版 gcloud 组件：

gcloud components install alpha

启用 API

启用所有必要的服务：

gcloud services enable cloudapis.googleapis.com 
gcloud services enable container.googleapis.com 
gcloud services enable containerregistry.googleapis.com
gcloud services enable cloudbuild.googleapis.com

设置可用区和平台

在创建启用了 Cloud Run Events 的 GKE 集群之前，请设置集群名称、可用区和平台。例如，在此处，我们将名称和可用区设置为 events-cluster 和 europe-west1-b，并将平台设置为 gke,

在 Cloud Shell 中：

export CLUSTER_NAME=events-cluster
export CLUSTER_ZONE=europe-west1-b

gcloud config set run/cluster ${CLUSTER_NAME}
gcloud config set run/cluster_location ${CLUSTER_ZONE}
gcloud config set run/platform gke

您可以检查配置是否已设置：

gcloud config list

...
[run]
cluster = events-cluster
cluster_location = europe-west1-b
platform = gke

6. 创建已启用 Cloud Run Events 的 GKE 集群

创建一个运行 Kubernetes >= 1.15.9-gke.26 的 GKE 集群，并启用以下插件：CloudRun、HttpLoadBalancing、HorizontalPodAutoscaling：

gcloud beta container clusters create ${CLUSTER_NAME} \
  --addons=HttpLoadBalancing,HorizontalPodAutoscaling,CloudRun \
  --machine-type=n1-standard-4 \
  --enable-autoscaling --min-nodes=3 --max-nodes=10 \
  --no-issue-client-certificate --num-nodes=3 --image-type=cos \
  --enable-stackdriver-kubernetes \
  --scopes=cloud-platform,logging-write,monitoring-write,pubsub \
  --zone ${CLUSTER_ZONE} \
  --release-channel=rapid

7. 设置 Cloud Run 事件（控制平面）

Cloud Run Events 具有控制平面和数据平面，需要分别进行设置。如需设置控制平面，请执行以下操作：

在 Cloud Shell 中：

gcloud beta events init

这将初始化事件处理，并创建所需的多个服务账号。当系统提示您创建服务账号时，请务必选择“是”。

此时，控制平面应已正确初始化。您应该会看到四个 Pod，其中

Running 状态，cloud-run-events 命名空间中有 2 个（controller-xxx-xxx 和 webhook-xxx-xxx），knative-eventing 命名空间中有 2 个（eventing-controller-xxx-xxx 和 eventing-webhook-xxx-xxx）。您可以通过执行以下命令进行检查：

kubectl get pods -n cloud-run-events

NAME                         READY   STATUS    RESTARTS   AGE
controller-9cc679b67-2952n   1/1     Running   0          22s
webhook-8576c4cfcb-dhz82     1/1     Running   0          16m

kubectl get pods -n knative-eventing

NAME                                   READY   STATUS    RESTARTS   AGE
eventing-controller-77f46f6cf8-kj9ck   1/1     Running   0          17m
eventing-webhook-5bc787965f-hcmwg      1/1     Running   0          17m

8. 设置 Cloud Run Events（数据层）

接下来，在用户命名空间中设置数据平面。这会创建一个具有适当权限的代理，以便从 Pub/Sub 读取数据/向 Pub/Sub 写入数据。

在 Cloud Shell 中，为要用于对象的命名空间设置 NAMESPACE 环境变量。如果您想使用默认命名空间，可以将其设置为 default，如下所示：

export NAMESPACE=default

请注意，如果指定的命名空间不存在（即命名空间不是默认命名空间），您需要创建该命名空间：

kubectl create namespace ${NAMESPACE}

使用默认密钥初始化命名空间：

gcloud beta events namespaces init ${NAMESPACE} --copy-default-secret

在命名空间中创建默认代理：

gcloud beta events brokers create default --namespace ${NAMESPACE}

检查代理是否已创建。请注意，代理可能需要几秒钟才能准备就绪：

kubectl get broker -n ${NAMESPACE}

NAME      READY   REASON   URL
default   True             http://default-brokercell-ingress.cloud-run-events.svc.cluster.local/default/default

9. 活动发现

您可以了解已注册的来源、它们可以发出的事件类型，以及如何配置触发器以使用这些事件。

如需查看不同类型事件的列表，请执行以下操作：

gcloud beta events types list

如需详细了解每种事件类型，请执行以下操作：

gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished

10. 创建 Cloud Run 接收器

作为事件接收器，部署一个 Cloud Run 服务，用于记录其收到的 CloudEvent 的内容。

您可以使用已编译的 Knative event_display，其容器映像已作为 Knative 版本的一部分构建。您可以在 event-display.yaml 中看到容器映像详情：

...
containers:
  - image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27

部署到 Cloud Run

将容器化应用部署到 Cloud Run：

export SERVICE_NAME=event-display
gcloud run deploy ${SERVICE_NAME} \
  --namespace=${NAMESPACE} \
  --image gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27

成功完成时，命令行会显示服务网址。现在，您可以在任何浏览器窗口中打开该服务网址，访问您部署的容器。

11. 创建 Cloud Pub/Sub 事件触发器

Cloud Pub/Sub 是接收事件的一种途径。自定义应用可以将消息发布到 Cloud Pub/Sub，然后这些消息可经由 Events for Cloud Run 传递到 Google Cloud Run 接收器。

创建主题

首先，创建一个 Cloud Pub/Sub 主题。您可以将 TOPIC_ID 替换为您偏好的唯一主题名称：

export TOPIC_ID=cr-gke-topic
gcloud pubsub topics create ${TOPIC_ID}

创建触发器

在创建触发器之前，详细了解构建 Cloud Pub/Sub 事件触发器所需的参数：

gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished

创建触发器，以过滤发布到 Cloud Pub/Sub 主题的事件，仅将符合条件的事件传递到我们部署的 Cloud Run 服务：

gcloud beta events triggers create trigger-pubsub \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type google.cloud.pubsub.topic.v1.messagePublished \
  --parameters topic=${TOPIC_ID}

测试触发器

您可以通过列出所有触发器来检查触发器是否已创建：

gcloud beta events triggers list

您可能需要等待触发器创建操作传播完毕，最多 10 分钟后，它会开始过滤事件。

要想模拟自定义应用发送消息的情景，您可以使用 gcloud 来触发事件：

gcloud pubsub topics publish ${TOPIC_ID} --message="Hello there"

我们创建的 Cloud Run 接收器会记录收到的消息正文。您可以在 Cloud Run 实例的“日志”部分中看到下列内容：

9526909a06c6d4f4.png

请注意，“Hello there”将采用 base64 编码（因为它是由 Pub/Sub 发送的），如果您想查看发送的原始消息，则必须对其进行解码。

删除触发器

测试完成后，您可以选择删除触发器。

gcloud beta events triggers delete trigger-pubsub --namespace ${NAMESPACE}

12. 创建审核日志事件触发器

您将设置一个触发器，以监听来自审核日志的事件。具体而言，您将在审核日志中查找 Pub/Sub 主题创建事件。

启用审核日志

要想接收来自某一服务的事件，您需要启用审核日志。在 Cloud 控制台中，从左上角的菜单中选择 IAM & Admin > Audit Logs。在服务列表中，选中 Google Cloud Pub/Sub：

97bd4b57c6a05fcc.png

在右侧，确保已选择“管理员”“读取”和“写入”。点击“保存”：

bec31b4f35fbcea.png

测试审核日志

要想了解如何识别参数，您需要设置一个真实的触发器并执行真实的操作。

例如，创建 Pub/Sub 主题：

gcloud pubsub topics create cre-gke-topic1

现在，我们来看看此次更新所生成的审核日志。在 Cloud 控制台中，从左上角的菜单中选择 Logging > Logs Viewer。

在 Query Builder, 下，选择 Cloud Pub/Sub Topic，然后点击 Add：

f5c634057e935bc6.png

运行查询后，您将看到 Pub/Sub 主题的相关日志，其中一个应该是 google.pubsub.v1.Publisher.CreateTopic：

b083cce219773d24.png

请注意 serviceName、methodName 和 resourceName。创建触发器时将会用到这些变量。

创建触发器

现在，您可以创建审核日志事件触发器了。

您可以运行以下命令，详细了解构建 Google Cloud 来源事件触发器所需的参数：

gcloud beta events types describe google.cloud.audit.log.v1.written

创建含有正确过滤条件的触发器：

gcloud beta events triggers create trigger-auditlog \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=google.cloud.audit.log.v1.written \
  --parameters serviceName=pubsub.googleapis.com \
  --parameters methodName=google.pubsub.v1.Publisher.CreateTopic

测试触发器

列出所有触发器，以确认触发器已成功创建：

gcloud beta events triggers list

等待触发器创建操作传播完毕，最多 10 分钟后，它会开始过滤事件。准备就绪后，它会过滤出 create 事件并将其发送到该服务。现在，您可以触发一个事件了。

像之前一样，创建另一个 Pub/Sub 主题：

gcloud pubsub topics create cre-gke-topic2

如果您在 Cloud 控制台中查看 Cloud Run 服务的日志，应该会看到收到的事件：

aff3b2e7ad05c75d.png

删除触发器和主题

测试完成后，您可以选择删除触发器：

gcloud beta events triggers delete trigger-auditlog

同时删除以下主题：

gcloud pubsub topics delete cre-gke-topic1 cre-gke-topic2

13. 为 Cloud Storage 创建事件触发器

您将设置一个触发器来监听来自 Cloud Storage 的事件。

创建存储桶

首先，在部署了 Cloud Run 服务的同一区域中创建一个 Cloud Storage 存储分区。您可以将 BUCKET_NAME 替换为您喜欢的唯一名称：

export BUCKET_NAME=[new bucket name]
export REGION=europe-west1

gsutil mb -p $(gcloud config get-value project) \
  -l $REGION \
  gs://$BUCKET_NAME/

设置 Cloud Storage 权限

在创建触发器之前，您需要向 Cloud Storage 的默认服务账号授予向 Pub/Sub 发布消息的权限。

首先，您需要找到 Cloud Storage 用于向 Pub/Sub 发布内容的服务账号。您可以按照获取 Cloud Storage 服务账号中所述的步骤获取服务账号，也可以使用以下命令：

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://storage.googleapis.com/storage/v1/projects/$(gcloud config get-value project)/serviceAccount"

服务账号应列在 email_address 下。

假设您从上述步骤中找到的服务账号为 service-XYZ@gs-project-accounts.iam.gserviceaccount.com，请将其设置为环境变量：

export GCS_SERVICE_ACCOUNT=service-XYZ@gs-project-accounts.iam.gserviceaccount.com

然后，向该服务账号授予发布到 Pub/Sub 的权限：

gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} \
  --member=serviceAccount:${GCS_SERVICE_ACCOUNT} \
  --role roles/pubsub.publisher

创建触发器

现在，您可以创建 Cloud Storage 事件触发器了。

您可以详细了解构建触发器所需的参数：

gcloud beta events types describe google.cloud.storage.object.v1.finalized

创建含有正确过滤条件的触发器：

gcloud beta events triggers create trigger-storage \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=google.cloud.storage.object.v1.finalized \
  --parameters bucket=${BUCKET_NAME}

测试触发器

列出所有触发器，以确认触发器已成功创建：

gcloud beta events triggers list

等待触发器创建操作传播完毕，最多 10 分钟后，它会开始过滤事件。准备就绪后，它会过滤出 create 事件并将其发送到该服务。

现在，您可以触发一个事件了。

将随机文件上传到 Cloud Storage 存储分区：

echo "Hello World" > random.txt
gsutil cp random.txt gs://${BUCKET_NAME}/random.txt

如果您在 Cloud 控制台中查看 Cloud Run 服务的日志，应该会看到收到的事件：

aff3b2e7ad05c75d.png

删除触发器

测试完成后，您可以选择删除触发器：

gcloud beta events triggers delete trigger-storage

14. 创建 Cloud Scheduler 事件触发器

您将设置一个触发器来监听来自 Cloud Scheduler 的事件。

创建 App Engine 应用

Cloud Scheduler 目前需要用户创建 App Engine 应用。选择 App Engine 位置并创建应用：

export APP_ENGINE_LOCATION=europe-west
gcloud app create --region=${APP_ENGINE_LOCATION}

创建触发器

您可以运行以下命令，详细了解构建 Google Cloud 来源事件触发器所需的参数：

gcloud beta events types describe google.cloud.scheduler.job.v1.executed

选择一个 Cloud Scheduler 位置来创建调度程序：

export SCHEDULER_LOCATION=europe-west1

创建一个触发器，该触发器将创建一个作业，以便在 Google Cloud Scheduler 中每分钟执行一次，并调用目标服务：

gcloud beta events triggers create trigger-scheduler \
  --namespace ${NAMESPACE} \
  --target-service=${SERVICE_NAME} \
  --type=google.cloud.scheduler.job.v1.executed \
  --parameters location=${SCHEDULER_LOCATION} \
  --parameters schedule="* * * * *" \
  --parameters data="trigger-scheduler-data"

测试触发器

列出所有触发器，以确认触发器已成功创建：

gcloud beta events triggers list

等待触发器创建操作传播完毕，最多 10 分钟后，它会开始过滤事件。准备就绪后，它会过滤出 create 事件并将其发送到该服务。

如果您在 Cloud 控制台中查看 Cloud Run 服务的日志，应该会看到接收到的事件。

删除触发器

测试完成后，您可以选择删除触发器：

gcloud beta events triggers delete trigger-scheduler

15. 自定义事件（代理端点）

在此 Codelab 的这一部分中，您将使用 Broker 生成和使用自定义事件。

创建 Curl Pod 以生成事件

事件通常是以编程方式创建的。不过，在此步骤中，您将使用 curl 手动发送各个事件，并查看这些事件如何被正确的消费者接收。

如需创建充当事件生产者的 Pod，请运行以下命令：

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: curl
  name: curl
  namespace: $NAMESPACE
spec:
  containers:
  - image: radial/busyboxplus:curl
    imagePullPolicy: IfNotPresent
    name: curl
    resources: {}
    stdin: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    tty: true
EOF

验证 curl Pod 是否正常运行。您应该会看到一个名为 curl 的 pod，其中包含 Status=Running：

kubectl get pod curl -n ${NAMESPACE}

创建触发器

您将创建一个触发器，该触发器会过滤您将发出的特定 CloudEvents 类型（在本例中为 alpha-type）。请注意，系统支持对任意数量的 CloudEvents 属性以及扩展程序进行精确过滤。如果您的过滤条件设置了多个特性，则事件必须具有所有这些特性，触发器才会将其过滤出来。反之，如果您不指定过滤条件，您的服务将收到所有事件。

创建触发器：

gcloud beta events triggers create trigger-custom \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=alpha-type \
  --custom-type

测试触发器

列出所有触发器，以确认触发器已成功创建：

gcloud beta events triggers list

通过向代理发送 HTTP 请求来创建事件。运行以下命令，提醒自己 Broker 网址：

kubectl get brokers -n ${NAMESPACE}

NAME      READY   REASON   URL
default   True             http://default-broker.<NAMESPACE>.svc.cluster.local

通过 SSH 连接到您之前创建的 curl pod：

kubectl --namespace ${NAMESPACE} attach curl -it

您已通过 SSH 连接到 pod，现在可以发出 HTTP 请求。系统会显示类似以下内容的提示：

Defaulting container name to curl.
Use 'kubectl describe pod/curl -n default' to see all of the containers in this pod.
If you don't see a command prompt, try pressing enter.
[ root@curl:/ ]$

创建活动：

curl -v "<BROKER-URL>" \
-X POST \
-H "Ce-Id: my-id" \
-H "Ce-Specversion: 1.0" \
-H "Ce-Type: alpha-type" \
-H "Ce-Source: my-source" \
-H "Content-Type: application/json" \
-d '{"msg":"send-cloudevents-to-broker"}'

如果已收到该事件，您将收到 HTTP 202 Accepted 响应。使用 Ctrl + D 退出 SSH 会话

通过查看 Cloud Run 服务的日志，验证已发布的事件是否已发送：

kubectl logs --selector serving.knative.dev/service=$SERVICE_NAME \
 -c user-container -n $NAMESPACE --tail=100

删除触发器

测试完成后，您可以选择删除触发器：

gcloud beta events triggers delete trigger-custom

16. 恭喜！

恭喜您完成此 Codelab。

所学内容

  • Events for Cloud Run for Anthos 的长期愿景
  • Events for Cloud Run for Anthos 的当前状态
  • 创建 Cloud Run 接收器
  • 创建 Cloud Pub/Sub 事件触发器
  • 创建审核日志事件触发器
  • 为 Cloud Storage 创建事件触发器
  • 创建 Cloud Scheduler 事件触发器
  • 生成和使用自定义事件