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

Question

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

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

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

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

提前致谢。

Answer 1

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

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

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

关于Redis，这张来自documentation的图片很清楚它的作用：

Composer 使用 Redis 作为调度程序和工作人员之间的后端。 Redis 服务充当 CeleryExecutor 的消息代理，它使用 StatefulSet 进行配置，并每 60 秒将快照保存到永久磁盘，以防止容器重新启动导致消息丢失 (documentation reference)。

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

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

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