为什么在创建 Cloud Composer 环境时会自动创建 2 Pub/Sub 个主题和订阅
Why 2 Pub/Sub topics & subscription gets created automatically while creating Cloud Composer environment
我注意到在创建云 composer 环境时自动创建了 2 Pub/Sub 个主题和订阅，所以 pub/sub 这里需要什么，composer 的内部架构与 Pub/Sub.
我需要这个概念上的澄清，因为我没有找到任何解释这个的文档。
我知道，cloud composer 使用 pub/sub 订阅与其 Kubernetes Engine 服务代理通信，但我的问题是为什么它默认创建 2 个主题而不是一个，我在更改 kubernetes 时也注意到了来自 cloud composer 的配置（例如改变 kubernetes 集群的节点数）/更新集群值它再次创建 2 个其他主题和相同的订阅，所以我想了解它实际上是如何在内部工作的，为什么它在每个之后创建新主题和订阅更新，为什么它不使用现有主题/订阅。还有 composer 和 Kubernetes Engine 服务代理如何通过 pub/sub 进行通信，这些是否会自动部署任何其他 GCP 组件，我想知道整个内部架构。
我还想了解一件事，GKE 集群中用于 Composer 的功能 "airflow-redis-0" pod 是什么？它仅用于消息队列还是充当调度程序和工作人员之间的通信？有什么方法可以在这里检查/可视化（通过 redis-cli 命令）Redis pod 的所有功能吗？
提前致谢。
根据 Cloud Composer documentation，Cloud Composer 使用这些 topics/subscriptions 与其 Kubernetes Engine 服务代理通信，并依赖 Cloud Pub/Sub 的默认行为来管理消息。
需要两个topics/subscriptions才能实现双向通信。如果你检查他们的名字，你会注意到一个是"composer-agent-to-backend-topic"，另一个是"composer-backend-to-agent-topic"。每次更新后，Composer 环境都会重新启动，它不能使用已经存在的 topic/subscription，所以它会创建新的。 GKE 和 Composer 通过 Pub/Sub 进行通信的内部方式没有公开记录，但它还用于中继来自租户项目的数据，例如来自托管网络服务器的日志。
您不应删除这些订阅，因为这会影响您的 Composer 环境的功能。
关于Redis，这张来自documentation的图片很清楚它的作用：
Composer 使用 Redis 作为 Scheduler 和 worker 之间的后端。 Redis 服务充当 CeleryExecutor 的消息代理，它是使用 StatefulSet and saves a snapshot every 60 seconds to a persistent disk to prevent message loss from container restarts (documentation reference).
提供的
您可以使用以下命令连接到 airflow-redis-0 pod 内的 airflow-redis 容器：
kubectl exec -it airflow-redis-0 -c airflow-redis bash
然后 运行 有任何你想要的 redis-cli command。但是，不建议篡改 Composer 环境的深层架构组件。
我注意到在创建云 composer 环境时自动创建了 2 Pub/Sub 个主题和订阅，所以 pub/sub 这里需要什么，composer 的内部架构与 Pub/Sub.
我需要这个概念上的澄清，因为我没有找到任何解释这个的文档。
我知道，cloud composer 使用 pub/sub 订阅与其 Kubernetes Engine 服务代理通信，但我的问题是为什么它默认创建 2 个主题而不是一个，我在更改 kubernetes 时也注意到了来自 cloud composer 的配置（例如改变 kubernetes 集群的节点数）/更新集群值它再次创建 2 个其他主题和相同的订阅，所以我想了解它实际上是如何在内部工作的，为什么它在每个之后创建新主题和订阅更新，为什么它不使用现有主题/订阅。还有 composer 和 Kubernetes Engine 服务代理如何通过 pub/sub 进行通信，这些是否会自动部署任何其他 GCP 组件，我想知道整个内部架构。
我还想了解一件事，GKE 集群中用于 Composer 的功能 "airflow-redis-0" pod 是什么？它仅用于消息队列还是充当调度程序和工作人员之间的通信？有什么方法可以在这里检查/可视化（通过 redis-cli 命令）Redis pod 的所有功能吗？
提前致谢。
根据 Cloud Composer documentation，Cloud Composer 使用这些 topics/subscriptions 与其 Kubernetes Engine 服务代理通信，并依赖 Cloud Pub/Sub 的默认行为来管理消息。
需要两个topics/subscriptions才能实现双向通信。如果你检查他们的名字，你会注意到一个是"composer-agent-to-backend-topic"，另一个是"composer-backend-to-agent-topic"。每次更新后，Composer 环境都会重新启动，它不能使用已经存在的 topic/subscription，所以它会创建新的。 GKE 和 Composer 通过 Pub/Sub 进行通信的内部方式没有公开记录，但它还用于中继来自租户项目的数据，例如来自托管网络服务器的日志。
您不应删除这些订阅，因为这会影响您的 Composer 环境的功能。
关于Redis，这张来自documentation的图片很清楚它的作用：
Composer 使用 Redis 作为 Scheduler 和 worker 之间的后端。 Redis 服务充当 CeleryExecutor 的消息代理，它是使用 StatefulSet and saves a snapshot every 60 seconds to a persistent disk to prevent message loss from container restarts (documentation reference).
提供的您可以使用以下命令连接到 airflow-redis-0 pod 内的 airflow-redis 容器：
kubectl exec -it airflow-redis-0 -c airflow-redis bash
然后 运行 有任何你想要的 redis-cli command。但是，不建议篡改 Composer 环境的深层架构组件。