When trying to configure Kong to connect to a separate Postgres deployment inside the same Kubernetes cluster, Kong won't start because of the following error in the kong logs:
Not using custom proxy SSL certificate. Override
by defining PROXY_SSL_CERT and PROXY_SSL_KEY.
Kubernetes Mode, picking up database host from env var.
Using kong database host: 10.0.36.3
Trusting all IPs to send correct X-Forwarded-Proto values
wait-for-it.sh: waiting 30 seconds for 10.0.36.3:5432
wait-for-it.sh: 10.0.36.3:5432 is available after 0 seconds
Error: [postgres error] could not retrieve server_version: FATAL: password authentication failed for user "kong"
The host, database, user and password are supplied using postgres configuration in the overrides.yaml for the wicked helm chart, and are correctly set in secrets and configmaps, but Kong says it cannot authenticate with the database.
It seems that instead of connecting to the specified host, it tries to connect to an IP of another kong-database (from a 0.12.5 installation of wicked) running in the same cluster, because it finds the KONG_DATABASE_SERVICE_HOST env variable set by the old installation.
In order to migrate from 0.12.5 to 1.0.0 we need to be able to deploy to deploy both wicked installations in the same cluster, since we need a transition phase for one of our applications.
When trying to configure Kong to connect to a separate Postgres deployment inside the same Kubernetes cluster, Kong won't start because of the following error in the kong logs:
The host, database, user and password are supplied using postgres configuration in the overrides.yaml for the wicked helm chart, and are correctly set in secrets and configmaps, but Kong says it cannot authenticate with the database.
It seems that instead of connecting to the specified host, it tries to connect to an IP of another kong-database (from a 0.12.5 installation of wicked) running in the same cluster, because it finds the KONG_DATABASE_SERVICE_HOST env variable set by the old installation.
In order to migrate from 0.12.5 to 1.0.0 we need to be able to deploy to deploy both wicked installations in the same cluster, since we need a transition phase for one of our applications.