Delegated gateways

Delegated gateways allow you to integrate existing API gateway solutions into your mesh.

In delegated gateway mode, Kong Mesh configures an Envoy sidecar for your API gateway. Handling incoming traffic is left to the API gateway while Envoy and Kong Mesh take care of traffic leaving the gateway for the mesh. The non-Kong Mesh gateway is in charge of policy such as security or timeouts related to incoming traffic, and Kong Mesh takes over after traffic leaves the gateway for the mesh.

At a technical level, the delegated gateway sidecar is similar to any other sidecar in the mesh, except that incoming traffic bypasses the sidecar and directly reaches the gateway.

See Use Kong as a delegated gateway with Kong Mesh to get started with delegated gateways.

Kubernetes

Kong Mesh supports most ingress controllers. However, the recommended gateway in Kubernetes is Kong Gateway. You can use Kong Operator to implement authentication, transformations, and other functionality across Kubernetes clusters with zero downtime.

Service upstream

Kong Mesh takes over from kube-proxy when managing endpoints for Service traffic. Kong Gateway does the same for upstream traffic. To prevent these from conflicting, configure Kong Operator to forward traffic to the Service IP rather than directly to Pod endpoints by setting serviceUpstream: true in an IngressClassParameters resource:

apiVersion: configuration.konghq.com/v1alpha1
kind: IngressClassParameters
metadata:
  name: kong-params
  namespace: default
spec:
  serviceUpstream: true

Then reference this in your IngressClass:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: kong
spec:
  controller: ingress-controllers.konghq.com/kong
  parameters:
    apiGroup: configuration.konghq.com
    kind: IngressClassParameters
    name: kong-params
    namespace: default
    scope: Namespace

Kong Mesh then routes this Service traffic to endpoints as configured by the mesh.

Delegated gateway data planes

To use the delegated gateway feature, add the kuma.io/gateway: enabled annotation to your gateway’s Pod. The control plane automatically generates Dataplane objects.

For example:

apiVersion: apps/v1
kind: Deployment
metadata:
  ...
spec:
  template:
    metadata:
      annotations:
        kuma.io/gateway: enabled
      ...

Now the gateway can send traffic to any services in the mesh including other zones.

In order to send multi-zone traffic, you can either use the .mesh address or create a Service of type ExternalName that points to that URL.

Universal

On Universal, you should define the Dataplane entity like this:

type: Dataplane
mesh: default
name: kong-01
networking:
  ...
  gateway:
    type: DELEGATED
    tags:
      kuma.io/service: kong

Traffic that should go through the gateway should be sent directly to the gateway process. When configuring your API Gateway to forward traffic to the mesh, configure the Dataplane object as any other Dataplane on Universal.