Kong Operator architecture

Kong Operator is a Kubernetes Operator that manages the lifecycle of Kong Gateway deployments on Kubernetes. It supports two primary deployment models: a self-hosted control plane and a Konnect-hosted control plane.

In self-hosted mode, Kong Operator manages both the control plane and the data plane within your Kubernetes cluster.

 
flowchart LR
    subgraph K8s[Kubernetes Cluster]
        K[Kubernetes API Server]

        subgraph kongNS[kong-system]
            KO["Kong Operator Pod
(Controller Manager
+ in-memory KIC per Gateway)"]
        end

        subgraph ClusterScoped[Cluster-scoped resources]
            GWClass[GatewayClass]
        end

        subgraph AppNS[Application Namespace]
            GWConfig[GatewayConfiguration]
            GW[Gateway]
            Routes["HTTPRoute / GRPCRoute
TCPRoute / UDPRoute"]
            DP["Data plane
(Kong Gateway, DB-less)"]
            S[Upstream services]
        end

        GWConfig -.->|parametersRef| GWClass
        GWClass -.->|gatewayClassName| GW
        K <-->|Watch CRD events| KO
        Routes -->|Watched & translated| KO
        KO -->|Deploys| DP
        KO -->|mTLS config sync| DP
        DP -->|Proxy traffic| S
    end

    Client([Client]) --> DP
  

Kong Operator watches for GatewayClass resources with spec.controllerName: konghq.com/gateway-operator. For each Gateway associated with such a GatewayClass, Kong Operator:

1. Starts an in-memory Kong Ingress Controller instance to act as the control plane for that Gateway. This isn’t a separately deployed Pod; it runs embedded inside the Kong Operator process.
2. Deploys a data plane: a Kong Gateway instance running in DB-less mode.
3. Continuously pushes routing configuration from the in-memory KIC to the data plane over mTLS via the Admin API.

Kong Operator defines the routing rules using Gateway API resources (HTTPRoute, GRPCRoute, TCPRoute, UDPRoute). The embedded KIC instance translates these into Kong configuration and syncs them to the data plane.

Use a GatewayConfiguration resource, referenced via GatewayClass.spec.parametersRef, to customize the data plane container image, environment variables, and other deployment settings.

To deploy multiple isolated gateways (for example, a public-facing and a private internal gateway), create a GatewayConfiguration, GatewayClass, and Gateway for each. Each Gateway results in:

• One embedded KIC instance (within the same Kong Operator Pod).
• One separate data plane deployment.

In Konnect mode, the control plane runs in Konnect rather than in your cluster.

 
flowchart LR
    subgraph Konnect["Kong Konnect"]
        KCP[Control plane]
        KAPI[Konnect API]
    end

    subgraph K8s[Kubernetes Cluster]
        K[Kubernetes API Server]

        subgraph kongNS[kong-system]
            KO["Kong Operator
(Controller Manager)"]
        end

        subgraph AppNS[Application Namespace]
            KonnectCRs["KonnectAPIAuthConfiguration
KonnectGatewayControlPlane
Kong entity CRDs"]
            DP["Data plane + KonnectExtension
(Kong Gateway, DB-less)"]
            S[Upstream services]
        end

        K <-->|Watch CRD events| KO
        KonnectCRs -->|Reconciled by| KO
        KO -->|Deploys| DP
        DP -->|Proxy traffic| S
    end

    KO -->|"HTTPS — sync resources"| KAPI
    KCP -->|WSS config sync| DP
    Client([Client]) --> DP
  

Kong Operator reconciles Kubernetes CRDs, such as KonnectAPIAuthConfiguration, KonnectGatewayControlPlane, and Kong entity CRDs, against the Konnect API over HTTPS.

For data plane connectivity, Kong Operator deploys data plane Pods annotated with a KonnectExtension. These Pods connect to the Konnect-hosted control plane over a secure WebSocket (WSS) connection to receive their configuration. There is no in-memory KIC in this model. Konnect acts as the control plane.