Kong Event Gateway with Kong Operator

Kong Operator reconciles Kong Event Gateway resources and deploys a matching KegDataPlane workload in your Kubernetes cluster.

For a step-by-step walkthrough you can apply directly to a cluster, see the Kong Event Gateway getting started guide.

The operator manages three layers:

• A KonnectEventGateway control plane in konnect.konghq.com/v1alpha1
• Event Gateway configuration resources in configuration.konghq.com/v1alpha1
• A KegDataPlane workload in eventgateway.konghq.com/v1alpha1

Here are the Kubernetes resources that form a typical Kong Event Gateway deployment:

Resources reference each other in this order:

1. EventGatewayBackendCluster.spec.gatewayRef points to a KonnectEventGateway
2. EventGatewayVirtualCluster.spec.eventGatewayBackendClusterRef points to an EventGatewayBackendCluster
3. EventGatewayListener.spec.gatewayRef points to the same KonnectEventGateway
4. EventGatewayListenerPolicy.spec.eventGatewayListenerRef points to an EventGatewayListener
5. Consume and produce policies point to an EventGatewayVirtualCluster
6. KegDataPlane.spec.controlPlaneRef points to the KonnectEventGateway

There are two ways to expose Kong Event Gateway with the operator:

• LoadBalancer with portMapping. Use this pattern if:
  • you need a fast local validation loop
  • you can expose one port per broker
  • a stable external IP is acceptable for clients
• Gateway with TLSRoute and SNI. Use this pattern if:
  • you want a production-oriented edge pattern
  • you need a single public Kafka listener
  • you want broker metadata returned as DNS names on one port
  • you plan to front multiple virtual clusters behind one entrypoint

LoadBalancer with portMapping

This pattern suits local validation and simple deployments where exposing one port per broker is acceptable. The KegDataPlane exposes a LoadBalancer Service with one port for bootstrap traffic and one port per broker.

The listener policy uses forwardToVirtualCluster.config.type: portMapping:

apiVersion: configuration.konghq.com/v1alpha1
kind: EventGatewayListenerPolicy
metadata:
  name: example-listener-policy
  namespace: kong
spec:
  apiSpec:
    type: forwardToVirtualCluster
    forwardToVirtualCluster:
      name: forward
      config:
        type: portMapping
        portMapping:
          advertisedHost: "10.0.1.1"
          bootstrapPort: at_start
          destination:
            name: example_virtual_cluster
  eventGatewayListenerRef:
    type: namespacedRef
    namespacedRef:
      name: example-listener

Set advertisedHost explicitly. Kafka clients use it when resolving broker metadata after bootstrap.

In a three-broker cluster, the data plane Service exposes:

• 9092 for bootstrap
• 9093 for broker 0
• 9094 for broker 1
• 9095 for broker 2

For a full deployment walkthrough, see Deploy Kong Event Gateway with port mapping.

Gateway with TLSRoute and SNI

This is the production-oriented pattern. A single TLS listener at the Kubernetes edge routes Kafka traffic to the correct virtual cluster by SNI:

• A Kubernetes Gateway exposes a single TLS listener
• A TLSRoute forwards encrypted traffic to the KegDataPlane Service
• An EventGatewayListenerPolicy with type: tlsServer terminates TLS in Kong Event Gateway
• A second EventGatewayListenerPolicy with forwardToVirtualCluster.config.type: sni routes clients by SNI

This keeps the public edge to a single port and returns broker metadata as stable DNS names instead of distinct ports.

The SNI forwarding policy looks like this:

apiVersion: configuration.konghq.com/v1alpha1
kind: EventGatewayListenerPolicy
metadata:
  name: sni-forward
  namespace: kong
spec:
  apiSpec:
    type: forwardToVirtualCluster
    forwardToVirtualCluster:
      name: forward_sni
      config:
        type: sni
        sni:
          sniSuffix: ".keg.example.com"
          brokerHostFormat:
            type: per_cluster_suffix
          advertisedPort: 9092
  eventGatewayListenerRef:
    type: namespacedRef
    namespacedRef:
      name: sni-listener

With a virtual cluster dnsLabel of vc-tls-1, clients receive metadata like:

• bootstrap.vc-tls-1.keg.example.com:9092
• broker-0.vc-tls-1.keg.example.com:9092
• broker-1.vc-tls-1.keg.example.com:9092
• broker-2.vc-tls-1.keg.example.com:9092

In production, configure wildcard DNS so that the advertised bootstrap and broker hostnames resolve to the Gateway address.

For a full deployment walkthrough, see Deploy Kong Event Gateway with TLSRoute and SNI.