Very little documentation for DB version of Kong with Kubernetes

We did a POC by integrating Kong OSS (Postgres DB version) with our company requirements and we were pretty satisfied by what we were able to achieve. Now we have dockerized everything along with our custom plugins and we want to deploy this to production. We use K8s with EKS in our production and are planning to integrate Kong Ingress Controller along with this. I went through your official documentation and found that you recommended using a DB-less version of Kong with Kubernetes deployments. We are hesitant to switch to this due to two reasons -

  1. We don’t want to lose Konga which we are using to easily update any services, routes, consumers, plugins, etc from a nice GUI.
  2. Switching to the DB-less version will force us to update all our thousands of customers with their authentication details in the YAML file which might make it very hard to maintain and may also cause memory issues (mind you we plan to use in-memory caching too).

Also, I found that there were very few resources and tutorials covering the DB version Kong deployment on Kubernetes as all the tutorials are focused on the DB-less versions. What do you people suggest? Also, if I am missing something or if you have relevant documentation for the DB version Kong K8s deployment please let me know.

Looking forward to your reply.
Thank you

Hi Reetik, how are you?

In this case, I think the best way to move for EKS is to use DBaaS like RDS and declare connection strings on helm3 deployments on env section. Look’s this repo charts/values.yaml at main · Kong/charts (github.com) you can find some samples of how you can deploy Kong.

On dbless mode to avoid huge manifests you can create a configmap to write kong.yaml, but always you change some autorized keys you connect on pod for restart kong :worried: .

Best regards.

The tutorials tend to use DB-less because you have to use one or the other and DB-less has fewer dependencies. It’s not exactly a recommendation, it’s just simpler for many users.

There isn’t much in the way of controller-specific DB-backed documentation because you don’t need to configure much differently. Setting your database configuration in the Kong container’s environment variables is all you need to do: you still configure K8S resources (Ingresses, KongPlugins, etc.) the same as you would with DB-less. The controller automatically determines whether Kong is using a database or not and updates its behavior (effectively, whether it uses the /config admin API endpoint or the individual /routes and /services endpoints) accordingly, without any user interaction.

Large numbers of consumers is one of the main cases where we do actually recommend a DB-backed instance instead, because it puts less strain on etcd. When using a database, you can create consumers and credentials directly, without creating KongConsumers and Secrets, the same as you would without the controller. The controller adds a managed-by-ingress-controller tag to resources it creates and ignores other resources, so controller-managed and user-managed configuration can coexist.

We do recommend that you choose one method or the other for resource types (e.g. you manage all consumers directly and manage all routes via Ingresses, rather than having some consumers that are added manually and some that are associated with a KongConsumer), though this is mostly a guideline to improve simplicity. There’s no technical limitation on mixing controller-managed and user-managed resources of the same type, but having a mix can make it a bit confusing to keep track of which is which.

Konga will work fine with controller-managed instances, but you’ll want to avoid editing controller-managed resources and only use it to view those. The controller will overwrite changes to any managed resources.


© 2019 Kong Inc.    Terms  •  Privacy  •  FAQ