Data synchronization between multiple pods in Kong DB mode

After the data is synchronized to the database through one pod, are the other pods fully or incrementally synchronized?

See https://github.com/Kong/kong/blob/master/kong.conf.default#L990-L1016

Configuration propagation happens in several phases:

  1. Whichever node receives the admin API request writes a change event (indicating what was modified and when) to the database.
  2. All nodes scan the events table at regular intervals (by default, every 5 seconds). When they see a new event, they retrieve the new configuration as needed.
  3. Routing and plugin configuration differs a bit from most configuration because of the way it’s stored locally. Those changes result in an event that indicates a change to the router version, and Kong checks to see if its router version is up to date either on every request (strict) or at a set interval (eventual, default 1 second intervals). If the version is out of date, Kong rebuilds the router.

The built router is handled per-worker, and workers’ intervals may start at slightly different times. eventual can therefore lead to workers briefly having a different configuration (e.g. for a new route, one worker routes the traffic while another 404s it). However, eventual generally results in less database load, as strict can encounter a scenario where many changes are made in quick succession, and it has to rebuild the router several times. eventual is fine for most use cases.

Hello Traines,

Thank you for the information, it’s very helpful, I have some other questions, could you please answer this question:

  1. For DB-less mode of Kong deployed in different Kubernetes clusters, when we make changes to one Kong instance, such as modifying the timeout parameters, how do the data planes in different clusters communicate (synchronize)?
  2. For DB mode of Kong, where both Kong and its associated data planes are deployed in different Kubernetes clusters, how do the data planes communicate (synchronize) when we make changes to one Kong instance?

I understand that we can use external third-party services to achieve this synchronization, such as database replication mechanisms like master-slave or multi-master replication, service discovery mechanisms (such as Kubernetes Service or external load balancers), or methods like GitOps or configuration management tools to store Kong’s configuration files in a version control system and propagate configuration changes to all clusters using automated processes. However, I would like to know if there are any native features within Kong that can be used for this purpose?

Many thanks,
James

@James_Wang - DB less mode is stand alone component hence the configurations are not propagated to other nodes. As they are not synchronised you need to make changes to all the nodes separately. Read More

With DB mode, you can install Kong in Hybrid Topology where there is one Control Plane attached with DB and one or more Data planes (runtime). When you publish changes to control plane using declarative file (using decK cli) it writes to DB, and all the data planes attached to control plane gets the changes. Read More

Hope this clarifies your question.

1 Like

Hello @JohnWilliams,

Thank you for your kindly help, it is very helpful.

Best Regards.

Hello @JohnWilliams

Thank you for your help, we also want to know is there anything that would is only supportive in the traditional Database full approach?
Because, by consulting Kong’s official documentation, it seems that except for some plugin incompatibilities (we can all implement it ourselves, right?) DB-less is almost as good (or even better?) than traditional mode.
Such synchronization configuration, although the DB-less mode does not have a natural mechanism for synchronization, but if we don’t often dynamically adjust configurations. We can also put them in the git repository and deploy them in batches only when needed.
So, if there is nothing critical that only the traditional database model can do, then the DB-less model is very attractive. But I’m not confident about this, May I get you kindly help to answer it? Thank you so much.
Best Regards,

@James_Wang Just my opinions - I do not belong to Kong team to give you a concrete answer. Also, I do not have any experience in implementing Kong DB less mode in production grade.

It totally depends on your use cases, if your infrastructure does not require dynamically scalable nodes (which would require that latest config to be available when new node starts) then you can manage your runtime nodes with controlled deployments and update the nodes when rolling out new APIs/configurations. This can take away your pain of managing a DB and totally rely on your git for source of truth.

1 Like

@JohnWilliams

Thank you for your kindly help.

Best Regards,