Yes, it is wise to do that. If you don't want the overhead of running your own SQL instance, you definitely don't want the overhead of running it on kubernetes;

Yes, it is wise to do that. If you don't want the overhead of running your own SQL instance, you definitely don't want the overhead of running it on kubernetes; it's quite tricky (but the addition of StatefulSets in 1.5 has made it easier). If you're running a CloudSQL instance, you can use a sidecar container to manage proxying the connection to the database: https://github.com/GoogleCloudPlatform/cloudsql-proxy https://github.com/GoogleCloudPlatform/cloudsql-proxy "The Cloud SQL Proxy allows a user with the appropriate permissions to connect to a Second Generation Cloud SQL database without having to deal with IP whitelisting or SSL certificates manually."