mode : postgresql (I have a requirement to use OAuth2 plugin which restrict me away from db-less mode)
helm-version : 2.14.1
chart-version : 0.26.1
istio-version : 1.4
kubernetes-version : v1.15.5
Since I labeled the installing namespace as istio-injection=enabled for the auto-injection. When I installed the kong through helm install stable/kong, the migration job cannot be completed normally. I find it’s a sidecar issue on Job resources (https://github.com/istio/istio/issues/11045).
I tried to disable the sidecar injection on Migration Job, it turns out that the migration job cannot find the postgersql pod.
In the meantime, I tried to terminate the job manually through kubectl exec gateway-kong-init-migrations-pq5cl-c istio-proxy -- curl -X POST localhost:15000/quitquitquit, however, the kong pod stood still as “PodInitilizing”.
Since I’d like to view the traffic through kong api-gateway and do the monitoring and logging things, I want to integrate the kong into the service mesh layer. What can I do? Is there a way to modify the chart to complete the installation or just replace the kong pod later?
There is nothing much that Kong can do for this bug with Istio/Kubernetes.
One hack, that will require some heavy lifting is to add an init-container to the postgresql pod, which runs Kong migrations instead. This will strictly be a workaround though.
Do you really need a database for your use-case?
You can deploy without a Database and essentially get almost the same set of features (with much simpler operations model).
Thanks for your suggestion, I will try it later.
Yeah, I think dbless mode is good and suits the cloud native principle. However, I need OAuth2 plugin. There will be a lot of workloads if I change the authorization way. btw, does kong have any special support or plan to enable OAuth2 in dbless mode?
