Deployment topologies
Kong provides different modes for you to deploy Kong Gateway in. Each mode has benefits and limitations, so it is important to consider them carefully when deciding which mode to use to in production installations.
Looking for ways to host your Data Plane? See the Supported Data Plane hosting options.
Hybrid mode
In hybrid mode, Kong Gateway nodes in a cluster are split into two roles: Control Plane (CP), where configuration is managed, and Data Plane (DP), which serves traffic for the proxy.
Hybrid mode deployments have the following benefits:
- Users can deploy groups of Data Planes in different data centers, geographies, or zones without needing a local clustered database for each DP group.
- The availability of the database does not affect the availability of the Data Planes. If a Control Plane is offline, Data Planes will run using their last known configuration.
- Drastically reduces the amount of traffic to and from the database, since only CP nodes need a direct connection to the database.
- If one of the DP nodes is compromised, an attacker won’t be able to affect other nodes in the Kong Gateway cluster.
Works on: Konnect, self-managed Kong Gateway
flowchart TD A(Dev Portal • Gateway Manager • Analytics • Service Catalog) B(Control Plane #40;Kong Gateway instance#41;) B2(
Control Plane #40;Kong Gateway instance#41;) C(
Data Plane 1 #40;Kong Gateway instance#41;) D(
Data Plane 2 #40;Local Kong Gateway instance#41;) E(
Data Plane 3 #40;Cloud-hosted Kong Gateway instance#41;) subgraph id1 [Konnect] A --- B & B2 end id1 --Kong proxy configuration---> id2 & id3 subgraph id2 [Kong-managed cloud node] C end subgraph id3 ["Self-managed nodes"] D E end style id1 stroke-dasharray:3,rx:10,ry:10 style id2 stroke-dasharray:3,rx:10,ry:10 style id3 stroke-dasharray:3,rx:10,ry:10
Traditional mode
In traditional mode, Kong Gateway requires a database to store configured entities such as Routes, Services, and plugins. In a traditional deployment, all Kong Gateway nodes connect to the database. Each node manages its own configuration.
Traditional mode is the only deployment topology that supports plugins that require a database, like rate limiting with the cluster strategy, or OAuth2.
However, there are some downsides:
- When running in traditional mode, every Kong Gateway node runs as both a Control Plane (CP) and Data Plane (DP). This means that if any of your nodes are compromised, the entire running gateway configuration is compromised.
- If you’re running Kong Gateway Enterprise with Kong Manager, request throughput may be reduced on nodes running Kong Manager due to expensive calculations being run to render analytics data and graphs.
Works on: Self-managed Kong Gateway
flowchart TD A[(Database)] B(Kong Gateway instance) C(
Kong Gateway instance) D(
Kong Gateway instance) A <---> B & C & D
DB-less mode
You can enable DB-less mode to reduce complexity of and create more flexible deployment patterns. In this mode, configured entities such as Routes, Services, and plugins are stored in-memory on the node. When running in DB-less mode, configuration is provided to Kong Gateway using a second file. This file contains your configuration in YAML or JSON format using Kong Gateway’s declarative configuration syntax.
The combination of DB-less mode and declarative configuration has a number of benefits:
- Reduced number of dependencies: no need to manage a database installation if the entire setup for your use case fits in memory.
- Your configuration is always in a known state. There is no intermediate state between creating a Service and a Route using the Admin API.
- DB-less mode is a good fit for automation in CI/CD scenarios. Configuration for entities can be kept in a single source of truth managed via a Git repository.
There are a few limitations of this mode:
- The Admin API is read only.
- Any plugin that stores information in the database, like rate limiting (cluster mode), doesn’t fully function.
Works on: Self-managed Kong Gateway