Events for Cloud Run for Anthos Codelab

1. 简介

6a5cf23c8e20491f

借助 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、Hangouts、Android Management 等）的事件来源

自定义来源

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

第三方来源

既非 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. 通过将集群范围发布到集群本地 Broker 网址，使最终用户应用和服务能够发出自定义事件。

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

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

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

我们将以迭代的方式不断创造更多价值，一直持续到 GA 及以后。

4. 设置和要求

自定进度的环境设置

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

96a9c957bc475304

b9a10ebdf5b5a448.png

a1e3c01a38fa61c2.png

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

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

启动 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：

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 事件的 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 事件的 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 事件具有控制平面和数据平面，两者需要单独设置。如需设置控制平面，请按以下步骤操作：

在 Cloud Shell 中：

gcloud beta events init

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

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

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

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 事件（数据平面）

接下来，在用户命名空间中设置数据平面。这将创建一个具有适当权限的 Broker，以便从 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

请注意，“Hello there”将采用 Pub/Sub 发送的 base64 编码格式；如果您想看到发送的原始消息，必须对其进行解码。

删除触发器

（可选）您可以在完成测试后删除该触发器。

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

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

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

启用审核日志

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

97bd4b57c6a05fcc

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

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 分钟，让触发器创建完成传播并开始过滤事件。准备就绪后，它将过滤创建事件并将其发送到服务。现在，您就可以触发事件了。

按照您之前的操作，创建另一个 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 分钟，让触发器创建完成传播并开始过滤事件。准备就绪后，它将过滤创建事件并将其发送到服务。

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

将一个随机文件上传到 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 分钟，让触发器创建完成传播并开始过滤事件。准备就绪后，它将过滤创建事件并将其发送到服务。

如果您在 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 且包含 Status=Running 的 Pod：

kubectl get pod curl -n ${NAMESPACE}

创建触发器

您将创建一个触发器，并针对您将发出的特定 CloudEvents 类型（在本例中为 alpha-type）进行过滤。请注意，系统支持对任意数量的 CloudEvents 属性以及扩展程序进行完全匹配过滤。如果您的过滤条件设置了多个属性，则事件必须具有所有属性，触发器才能对其进行过滤。相反，如果您没有指定过滤器，则您的 Service 中会收到所有事件。

创建触发器：

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 创建事件触发器
  • 生成和使用自定义事件