Google Cloud Run服务间非HTTP私有通信及无代码层Bearer认证实现技术问询

针对你提到的多个长期运行Cloud Run服务通过TCP/UDP私有通信、无需Bearer认证的场景，我来逐一解答你的疑问：

1. 自定义VPC和Serverless VPC Connector是否必要？同一项目内Cloud Run默认能否互相访问？ #

默认情况下，Cloud Run服务部署在Google托管的公共网络中，彼此只能通过HTTPS协议访问，且必须携带Bearer令牌进行IAM认证——这显然不符合你非HTTP、无Bearer认证的需求。

所以自定义VPC + Serverless VPC Connector是必要的：通过Connector可以将Cloud Run服务接入你的私有VPC，让服务之间的流量完全在VPC内部流转，既支持TCP/UDP协议，又能通过VPC网络策略控制访问（无需依赖Cloud Run的IAM认证）。

2. 配置后服务如何寻址？能否使用简洁的一级DNS名称？ #

Cloud Run服务接入VPC后，默认不会自动注册apione、apitwo这类一级DNS名称，但你可以通过Cloud DNS私有区域实现类似效果：

• 创建一个私有DNS区域（比如internal.yourdomain.com），并关联到你的自定义VPC
• 为每个Cloud Run服务添加CNAME记录，将apione.internal.yourdomain.com指向该服务的官方域名（比如apione-xxxxxx-uc.a.run.app）
• 配置VPC的DNS搜索域为internal.yourdomain.com，这样其他服务只需输入apione就能自动解析到对应的Cloud Run服务

这种方式能让你用接近一级DNS的简洁名称寻址，无需记忆冗长的官方域名。

3. 如果无法使用简洁DNS，有没有服务发现机制？ #

如果手动维护DNS记录太麻烦，你可以使用Google的Service Directory托管服务发现：

• 将Cloud Run服务的地址信息注册到Service Directory的命名空间中
• 其他服务可以通过Service Directory的API查询目标服务的地址，或者配置Cloud DNS与Service Directory集成，自动生成DNS记录
• 这样无需手动更新记录，服务扩缩容或地址变化时能自动同步

4. 托管式Cloud SQL PostgreSQL部署到该网络，能否控制其DNS名称？ #

托管Cloud SQL实例使用私有IP接入VPC时，会有一个默认的私有DNS名称（格式为private-<实例名>:<区域>.sql.goog），你无法直接修改这个默认名称，但同样可以通过Cloud DNS私有区域添加CNAME记录，将你想要的自定义名称（比如postgres-db）指向这个默认私有域名，实现自定义寻址。

5. 潜在问题与注意事项 #

除了上述配置，还有几个关键点需要留意：

• 实例保活：Cloud Run默认会缩容到0实例，若你的服务需要长期运行，必须设置--min-instances=1（或更高），避免无流量时实例被关闭导致TCP/UDP连接中断
• Connector带宽限制：Serverless VPC Connector的规格（如e2-small、e2-medium）对应不同的带宽上限，需根据你的流量需求选择合适的规格，避免成为瓶颈
• 网络策略配置：要确保VPC网络策略允许Cloud Run服务之间、Cloud Run与Cloud SQL之间的TCP/UDP端口通信，否则流量会被拒绝
• 端口与Ingress设置：部署非HTTP服务时，需用--port指定监听端口；同时设置--ingress=internal（仅允许VPC内部访问）或--ingress=internal-and-cloud-load-balancing，避免公网访问，保证通信私有性
• 区域一致性：Serverless VPC Connector必须与Cloud Run服务在同一区域，否则无法接入

如果当前的workaround无法满足你的需求，确实值得为相关的官方功能请求投票，推动官方直接支持VPC内部的简洁DNS名称或原生服务发现。

内容的提问来源于stack exchange，提问作者Alexander Trauzzi