How does the Kong Ingress Controller work with Hybrid Mode Deployment


Kong 2.0.0 just released recently with a Hybrid Mode Deployment, which introduce the control plane and the data plane.

However, the kong ingress controller with DB also has the control plane and data plane like the diagram shows here:

In kong ingress controller, the control plane writes into the DB. In hybrid mode, the config is pushed to data plane directly. Another main difference is that in hybrid mode, there could be several data planes sharing one control plane. But it feels like more suitable to have one data plane with several control planes from different namespaces in kong ingress controller. It seems to be two different approaches to config and manage the kong now.

May I ask what are the use cases for hybrid mode and kong ingress controller? How should we decide which way to go?

Hey @namco,

Thank you for the question.
There are a number of ways you can deploy Kong in the Ingress Controller deployment, and each has it’s pros and cons.

  1. The figure mentioned above. The controller pushes config into Kong’s DB via Kong’s Admin API, which is picked up by other Kong nodes (pub-sub via database).
  2. Use Kong in DB-less mode and the controller manages configuration for Kong. In this mode, you deploy one controller for each Kong node. As of today, this is the officially recommended approach.
  3. Use Kong’s Hybrid mode (your question). In this case, the controller pushes configuration to Kong via Kong’s Admin API on the CP node, which takes care of pushing the configuration to other DP Kong nodes. This requires a DB. This is technical possible and easy to achieve today out of the box with some custom YAMLs.
  4. A single controller configures multiple Kong DB-less nodes. This is on the roadmap. This bypasses Kong’s hybrid mode to avoid the dependency on the database.

Use (1) or (2) for production today. (2) is the easiest operationally and the easiest to install, manage and debug.