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

Question

我已经注意到，在创建Cloud Composer环境时会自动创建2个Pub / Sub主题和订阅，因此这里pub / sub的需求是什么，composer的内部架构与Pub / Sub的关系是什么。

我需要进行概念上的澄清，因为我没有发现任何文档对此进行解释。

我了解到，云作曲家使用那里的发布/订阅订阅与其Kubernetes Engine服务代理进行通信，但是我的问题是，为什么它默认创建2个主题而不是一个主题，当我从Cloud Composer更改kubernetes配置时我也注意到（例如改变kubernetes集群的节点数）/更新集群的价值再次为其创建了2个其他主题和订阅，因此我想了解它的内部实际工作原理，为什么每次更新后都创建新的主题和订阅，为什么其不使用现有主题/订阅。另外，作曲家和Kubernetes Engine服务代理如何通过pub / sub进行通信，这些其他GCP组件是否也可以自动部署为相同，我想了解整个内部体系结构。

我想了解的另一件事是，用于Composer的GKE集群中的功能上“ airflow-redis-0”吊舱是什么？它仅用于消息排队还是作为调度程序与工作人员之间的通信？有没有办法在这里通过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进行通信的内部方式尚未公开记录，但它还用于中继来自租户项目的数据，例如来自托管Web服务器的日志。

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

关于 Redis ，来自documentation的这张图片非常清楚其作用：

Composer使用Redis作为Scheduler和worker之间的后端。 Redis服务充当CeleryExecutor的消息代理，使用StatefulSet进行配置，并每60秒将快照保存到一个永久磁盘中，以防止容器重启（documentation reference）导致消息丢失。

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

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

，然后在任意位置运行redis-cli command。但是，不建议篡改Composer环境的深层架构组件。