为什么在创建 Cloud Composer 环境时会自动创建 2 个 Pub/Sub 主题和订阅

Question

我注意到在创建云 Composer 环境时会自动创建 2 个 Pub/Sub 主题和订阅，那么这里需要 pub/sub 是什么，Composer 的内部架构如何与 Pub/Sub 相关。

我需要这个概念上的澄清，因为我没有找到任何文档解释这一点。

我明白，cloudcomposer 使用 pub/sub 订阅与其 Kubernetes Engine 服务代理进行通信，但我的问题是为什么它默认创建 2 个主题而不是一个，我还注意到，当我从 cloudcomposer 更改 kubernetes 配置时（例如更改kubernetes 集群的节点数）/更新集群值，它再次创建 2 个其他主题和订阅，所以我想了解它的内部工作原理，为什么它在每次更新后创建新主题和订阅，为什么它不使用退出主题/订阅。还有 Composer 和 Kubernetes Engine 服务代理如何通过 pub/sub 进行通信，这些其他 GCP 组件是否都是自动部署的，我想知道整个内部架构。

我还想了解一件事，GKE 集群中用于 Composer 的功能“airflow-redis-0”pod 是什么？它仅用于消息队列还是充当调度程序和工作人员之间的通信？有什么方法可以在这里检查/可视化（通过 redis-cli 命令）Redis pod 的所有功能吗？

提前致谢。

Answer 1

根据Cloud Composer 文档，Cloud Composer 使用这些主题/订阅与其 Kubernetes Engine 服务代理进行通信，并依赖 Cloud Pub/Sub 的默认行为来管理消息。

需要两个主题/订阅才能实现双向通信。如果您检查它们的名称，您会注意到一个是“composer-agent-to-backend-topic”，另一个是“composer-backend-to-agent-topic”。每次更新后，Composer 环境都会重新启动，并且无法使用现有的主题/订阅，因此会创建新的主题/订阅。GKE 和 Composer 通过 Pub/Sub 进行通信的内部方式并未公开记录，但它还用于中继来自租户项目的数据，例如来自托管 Web 服务器的日志。

您不应删除这些订阅，因为这会影响您的 Composer 环境的功能。

关于Redis ，文档中的这张图片非常清楚地说明了它的作用：

Composer 使用 Redis 作为 Scheduler 和 Workers 之间的后端。Redis 服务充当 CeleryExecutor 的消息代理，它使用StatefulSet进行配置，并每 60 秒将快照保存到持久磁盘，以防止容器重新启动导致消息丢失（文档参考）。

您可以使用以下命令连接到podairflow-redis内的容器airflow-redis-0：

kubectl exec -it airflow-redis-0 -c airflow-redis bash

然后在那里运行您想要的任何redis-cli 命令。但是，不建议篡改 Composer 环境的深层架构组件。