Postgres db for kong OSS

We have recently started using kong and we are using kong OSS deployed via kubernetes to a GKE cluster. In order to make use of the cluster policy to share plugin data across nodes we would like to add a postgres DB to the setup, but I am having trouble adding this.

I have followed the Kubernetes installation documentation for OSS and this works fine, and I have deployed a postgres DB deployment to the same cluster and namespace, which I am also able to connect to without issue, but the problem arrises when trying to connect them together. Essentially what I am trying to do is to replicate the Docker installation method for OSS, but with kubectl instead.
In order to achieve this I have set the KONG_DATABASE env variable to postgres for the proxy container, and the KONG_PG_HOST env variable to the name of the exposing service for the DB, in this case kong-database. As far as I understand this should set the username and password to their default values of “kong” and “kongpass” respectively, which is what I have set in the database itself. However, once deployed the proxy container fails to start with CrashLoopBackOff due to the probes being refused connection:

Warning  BackOff    26s (x3 over 29s)  kubelet            Back-off restarting failed container
Warning  Unhealthy  16s (x2 over 26s)  kubelet            Liveness probe failed: Get "http://10.72.0.17:10254/healthz": dial tcp 10.72.0.17:10254: connect: connection refused
Warning  Unhealthy  13s (x6 over 29s)  kubelet            Readiness probe failed: Get "http://10.72.0.17:10254/readyz": dial tcp 10.72.0.17:10254: connect: connection refused

I am confused as I am able to connect to the database from another pod in the same namespace using the set credentials ie
psql postgresql://kong:kongpass@kong-database:5432/kong
and it seems strange that the probes would fail due to a credential misconfiguration.
I have also tried moving the database container into the ingess-kong deployment and using the default 127.0.0.1 value for host but I get the same result. As well as this I have tried explicitly setting the user and password values rather than relying on them using the default, but again, same issue.

Any help would be appreciated