Private service to service communication for Google Cloud Run

Question

I'd like to have my Google Cloud Run services privately communicate with one another over non-HTTP and/or without having to add bearer authentication in my code.

I'm aware of this documentation from Google which describes how you can do authenticated access between services, although it's obviously only for HTTP.

I think I have a general idea of what's necessary:

1. Create a custom VPC for my project
2. Enable the Serverless VPC Connector

What I'm not totally clear on is:

• Is any of this necessary? Can Cloud Run services within the same project already see each other?
• How do services address one another after this?
  • Do I gain the ability to use simpler by-convention DNS names? For example, could I have each service in Cloud Run manifest on my VPC as a single first level DNS name like apione and apitwo rather than a larger DNS name that I'd then have to hint in through my deployments?
  • If not, is there any kind of mechanism for services to discover names?
• If I put my managed Cloud SQL postgres database on this network, can I control its DNS name?

Finally, are there any other gotchas I might want to be aware of? You can assume my use case is very simple, two or more long lived services on Cloud Run, doing non-HTTP TCP/UDP communications.

---

I also found a potentially related Google Cloud Run feature request that is worth upvoting if this isn't currently possible.

Answer 1

Cloud Run services are only reachable through HTTP request. you can't use other network protocol (SSH to log into instances for example, or TCP/UDP communication).

However, Cloud Run can initiate these kind of connection to external services (for instance Compute Engine instances deployed in your VPC, thanks to the serverless VPC Connector).

the serverless VPC connector allow you to make a bridge between the Google Cloud managed environment (where live the Cloud Run (and Cloud Functions/App Engine) instances) and the VPC of your project where you have your own instances (Compute Engine, GKE node pools,...)

Thus you can have a Cloud Run service that reach a Kubernetes pods on GKE through a TCP connection, if it's your requirement.

---

About service discovery, it's not yet the case but Google work actively on that and Ahmet (Google Cloud Dev Advocate on Cloud Run) has released recently a tool for that. But nothing really build in.