You are browsing documentation for an older version. See the latest documentation here.

Kubernetes Topologies

Running Kong Gateway on Kubernetes is a common deployment pattern. When running on Kubernetes, there are two configuration options available:

• Hybrid mode, with a CP (either on-prem or via Konnect) and multiple DPs
• DB-less mode, configured using CRDs and the Kong Ingress Controller

Running Kong in Hybrid mode is commonly referred to as “Kong on Kubernetes”. Running Kong with Kong Ingress Controller is commonly referred to as “Kong for Kubernetes”, as it provides a Kubernetes native way of configuring Kong entities using Kong Ingress Controller.

You can also use Kong Ingress Controller to configure a Hybrid mode deployment. This should only be used in a small set of circumstances. We recommend using Hybrid mode without KIC, or DB-less mode with KIC, unless you’ve been otherwise advised by a member of the Kong team.

Hybrid mode

Deploying Kong Gateway in Hybrid mode uses Kubernetes as a runtime for your data planes.

Configuring Kong on Kubernetes is identical to deploying Kong running on a virtual machine or bare metal. The Data Planes connect to a Control Plane (Konnect, or an in-cluster control plane) and receive configuration from the CP. Configuration is managed using the UI, the Kong Admin API or via deck.

We provide detailed installation instructions for Hybrid mode, including ingress definitions for EKS, GKE and AKS.

DB-less mode with Kong Ingress Controller

Kong Ingress Controller provides a Kubernetes native way to configure Kong Gateway using custom resource definitions (CRDs). In this deployment pattern, Kong Gateway is deployed in DB-less mode, where the data plane configuration is held in memory.

Operators configure Kong Gateway using standard CRDs such as Ingress and HTTPRoute, and Kong Ingress Controller translates those resources in to Kong entities before sending a request to update the running data plane configurations.

In this topology, the Kubernetes API server is your source of truth. Kong Ingress Controller reads resources stored on the API server and translates them in to a valid Kong configuration object. You can think of Kong Ingress Controller as the control plane for your DB-less data planes.

For more information about Kong Gateway and Kong Ingress Controller, see the Kong Ingress Controller getting started guide. This guide walks you through installing Kong Gateway, configuring a service and route, then adding a rate limiting and caching plugin to your deployment.

Deciding which to use

Both topologies are supported by Kong, and deciding between the two options depends on your team’s capabilities.

If you’re a Kubernetes-native company who are comfortable managing CRDs and have pre-existing workflows around Kubernetes resources, we recommend using Kong Ingress Controller to manage your deployment. Kong Ingress Controller can be attached to Konnect to provide visibility in to the generated configuration and live traffic through analytics.

If your team is not familiar with CRDs, or you’re migrating an existing configuration from bare metal machines or VMs to Kubernetes, you should choose Hybrid mode. In this topology, Kubernetes is a place to run your data planes and nothing more. There are no CRDs to learn, no Ingress Controller to maintain and update. All configuration is stored in the control plane and send to data planes using the Hybrid mode protocol.