Kong-Ingress-Controller with database

Kubernetes
#1

I often destroy and redeploy a cluster.

For the initial launch, I do the following:

  • build a new cluster
  • deploy an empty postgresql db
  • deploy kong-ingress-controller
  • execute kong migrate bootstrap

To create a new Kong Consumer, I create a new KongConsumer k8s object which will create a new consumer entry in kong postgresql db.

Then, I do the following:

  • save my postgresql kong db
  • destroy my cluster
  • rebuilding a new cluster
  • deploy postgresql db
  • import saved postgresql kong db
  • deploy kong-ingress-controller
  • execute kong migrate bootstrap

I notice that all the KongConsumer that I have created in my initial deployment no longer exists when I redeploy to a new cluster. I was under the assumption that kong-ingress-controller would automatically recreate a KongConsumer object for each consumer that do not already exists in the current kubernetes state but do exists in the postgresql kong db.

Question:

If a consumer make a request to the api gateway and this consumer exists in the postgresql kong db but not as a k8s object, will kong-ingress-controller still recognize it ?

#2

The controller translates Kubernetes resources (e.g. a KongConsumer resource) into Kong proxy configuration (the contents of the database). It does so continuously, i.e. it attempts to ensure that the configuration in Kong’s database always matches the current set of Kubernetes resources.

That process doesn’t work in reverse: the controller doesn’t create Kubernetes resources that reflect the contents of the Kong database.

Furthermore, the controller deletes configuration in the Kong database if it doesn’t see a matching Kubernetes resource, which is what you’re seeing after you restore the Postgres backup. That’s by design: if you want to back up those resources and restore them later, you should back up and restore the Kubernetes resources, not the database contents.

1 Like
#3

Hi, based on your explanation, what is the role of Postgres db in such a deployment topology? Why would one want to keep a database in the back?

#4

There are some features that require a database and different operational characteristics (DB-less instances consume more memory): DB-less and Declarative Configuration - v2.3.x | Kong - Open-Source API Management and Microservice Management

© 2019 Kong Inc.    Terms  â€˘  Privacy  â€˘  FAQ