Access external database resource wrapped in service without selector

While is fine to access services within the cluster using a service without selectors, an alternative approach that might fit your particular scenario would be using an ExternalName Service:

Services of type ExternalName map a Service to a DNS name, not to a typical selector such as my-service or cassandra

Additionally and considering that you're using a Cloud SQL on GCP, a more reliable way to connect to the database without having to whitelist the node IP addresses would be using Cloud SQL proxy:

The Cloud SQL Proxy provides secure access to your Cloud SQL Second Generation instances without having to whitelist IP addresses or configure SSL.

Regarding your second question, since the service that is currently connected to the database exists only within the cluster, you'll need to get access to the cluster network in order to be able to reach whatever external endpoint is mapped into it.

As you mentioned, executing a pod's shell session allows you to reach your PostgreSQL service since the pod is within the cluster network and can communicate with the service. You can expose the database service using any Kubernetes service exposing method and then, use your local client to hit the exposed service so that it relays the communication to your database.

The problem was discussed here and there is a solution to set up port forwarding to a service without selector/pod (e.g. ExternalName service) by deploying a proxy pod inside K8s:

kubectl -n production run mysql-tunnel-$USER -it --image=alpine/socat --tty --rm --expose=true --port=3306 tcp-listen:3306,fork,reuseaddr tcp-connect:your-internal-mysql-server:3306
kubectl -n production port-forward svc/mysql-tunnel-$USER 3310:3306

In the example above the MySQL server at your-internal-mysql-server:3306 will be available on localhost:3310 on your machine.