Google cloud platform 在同一项目中使用Cloud Composer和Cloud功能时，如何使用VPC服务控件在GCP上配置防火墙规则和DNS设置？

我们在VPC服务控制下为单个项目配置两个GCP组件（GCP Cloud Composer，GCP功能）时遇到问题。我们可以使用VPC服务控件单独配置它们，但一旦添加第二个组件，我们就会遇到问题

一旦我们为云功能配置了防火墙规则和DNS设置，编写器就会开始失败。 Composer监视工具（用于Web服务器、SQL server等）显示Composer不正常

我们做错了什么

我们使用的文档：

对于Composer，我们使用以下设置：

• 3节点
• 标准机型
• 图像版本：composer-1.16.3-airflow-1.10.15
• python:v3
• 专用IP编写器

我们为VPC服务控制启用的API：

• 谷歌云数据处理API
• 云函数API
• 谷歌云发布/订阅API
• 云SQL API
• 谷歌云存储API
• 谷歌计算引擎API
• 谷歌Kubernetes引擎API
• 谷歌容器注册API
• 云监控API
• 云编写器API
• 工件注册API

防火墙设置（基于文档）：

名称 类型 目标 过滤器 协议/端口 行动 优先 composer出口gke群集所有端口 出口 适用于所有人 IP范围：10.10.0.0/16 tcp，udp 容许 1000 作曲家外出健康检查 出口 适用于所有人 IP范围：130.211.0.0/22、35.191.0.0/16 tcp:80443 容许 1000 作曲家-出口-端口53 出口 适用于所有人 IP范围：0.0.0.0/0 tcp:53，udp:53 容许 1000 composer出口Web服务器 出口 适用于所有人 IP范围：172.31.251.0/24 tcp:33063307 容许 1000 受限制的谷歌API 出口 适用于所有人 IP范围：199.36.153.4/30 tcp:443 容许 1000 作曲家否认一切 出口 适用于所有人 IP范围：0.0.0.0/0 全部的 否认 2000 作曲家安格斯helthcheck 进入 适用于所有人 IP范围：130.211.0.0/22、35.191.0.0/16 tcp:80443 容许 1000 入口iap 进入 适用于所有人 IP范围：35.235.240.0/20 tcp 容许 1000 gke-europe-west1-composer-dns-xxx-xxx-all 进入 gke-europe-west1-composer-dns-xxx-xxx-node IP范围：10.124.0.0/14 tcp；udp；esp；啊,；sctp；icmp 容许 1000 gke-europe-west1-composer-dns-xxx-xxx-master 进入 gke-europe-west1-composer-dns-xxx-xxx-node IP范围：172.16.8.0/28 tcp:10250443 容许 1000 gke-europe-west1-composer-dns-xxx-xxx-vms 进入 gke-europe-west1-composer-dns-xxx-xxx-node IP范围：10.10.0.0/16 tcp:1-65535；udp:1-65535；icmp 容许 1000

---

与此同时，我们已经解决了问题：

• 最大的问题是包含IP地址的

  googleapis.com.

  中缺少

  A

  类型的DNS记录
• 第二个问题是，来自云功能VPC SC设置文档的防火墙规则阻止了以下之间的通信：
  • 子网上编写器的节点
  • 在工作节点和主节点（为composer创建的Kubernetes群集）之间，主节点在不同的项目中自动创建，并通过网络对等连接到composer工作节点的子网

这两份文件显然没有涵盖这一特殊情况，因为这两种服务应该一起使用。在解决上述问题后，它已开始工作

我们仍然面临的问题是：

• 调试这类问题很困难，因为composer的监视UI似乎以不一致的方式显示信息
• 在子网上启用StackDriver日志后，很难使用它进行调试，因为它的信息太多，并且它们记录在“信息”级别，而不是“警告”或“错误”级别

---

您能否提供一些日志或收到的实际错误消息？根据你的描述，很难说是什么导致了这个问题。问题是很难得到相关的日志。。。在设置防火墙规则和DNS设置后，根据其监视UI，Composer刚刚开始失败。此UI似乎以不一致的方式总结结果。更改时间分辨率后，有时会显示失败，有时一切都是绿色的。在Composer子网上启用日志记录后，StackDriver被太多记录转储，无法正确调试。同时，我们已经解决了这个问题，我将在下面描述它。