You are browsing documentation for an outdated version.
See the latest documentation here.
When services need to receive traffic from the outside, commonly called North/South, the Kong Mesh Gateway enables routing network traffic from outside a Kong Mesh mesh to services inside the mesh. The gateway is also responsible for security at the entrance of the Mesh.
Kong Mesh Gateway deploys as a Kong Mesh
, that’s an instance of the
Like all Kong Mesh
Dataplanes, the Kong Mesh Gateway
Dataplane manages an Envoy proxy process that does the actual network traffic proxying.
You can distinguish two types of gateways:
- delegated: Allows users to use any existing gateway like Kong.
- builtin: Configures the data plane proxy to expose external listeners to drive traffic inside the mesh.
Gateways exist within a mesh.
If you have multiple meshes, each mesh requires its own gateway. You can easily connect your meshes together using cross-mesh gateways.
Below visualization shows the difference between delegated and builtin gateways:
Builtin with Kong Gateway to handle the inbound traffic:
Delegated with Kong Gateway:
The blue lines represent traffic not managed by Kong Mesh, which needs configuring in the Gateway.
Dataplane entity can operate in
gateway mode. This way you can integrate Kong Mesh with existing API Gateways like Kong.
gateway mode lets you skip exposing inbound listeners so it won’t be intercepting ingress traffic. When you use a data plane proxy with a service, both inbound traffic to a service and outbound traffic from the service flows through the proxy. In the
gateway mode, you want inbound traffic to go directly to the gateway, otherwise, clients require dynamically generated certificates for communication between services within the mesh. The gateway itself should handle security at an entrance to the mesh.
The builtin gateway is integrated into the core Kong Mesh control plane.
You can configure gateway listeners and routes to service directly using Kong Mesh policies.
The builtin gateway is configured on a
A builtin gateway
Dataplane does not have either inbound or outbound configuration.
To configure your gateway Kong Mesh has these resources:
MeshGateway is used to configure listeners exposed by the gateway
MeshGatewayRoute is used to configure route to route traffic from listeners to other services.
Kong Mesh gateways are configured with the Envoy best practices for edge proxies.
You can create and configure a gateway that listens for traffic from outside of your mesh
and forwards it to the
demo app frontend
Now let’s create a
MeshGateway to configure the listeners:
MeshGateway creates a listener on port 8080 and will accept any traffic which has the
Host header set to
Notice that listeners have tags like
Dataplanes. This will be useful when binding routes to listeners.
These are Kong Mesh policies so if you are running on multi-zone they need to be created on the Global CP.
See the dedicated section for using builtin gateways on
Now, you can define a
MeshGatewayRoute to forward your traffic based on the
matched URL path.
The builtin gateway also supports TCP
- port: 8080
The TCP configuration only supports the
backends key (no
filters). There are no TCP-generic ways to filter or match traffic so it can only load balance.
The Kong Mesh Gateway resource types,
MeshGatewayRoute, are synced across zones by the Kong Mesh control plane.
If you have a multi-zone deployment, follow existing Kong Mesh practice and create any Kong Mesh Gateway resources in the global control plane.
Once these resources exist, you can provision serving capacity in the zones where it is needed by deploying builtin gateway
Dataplanes (in Universal zones) or
MeshGatewayInstances (Kubernetes zones).
Mesh abstraction allows users
to encapsulate and isolate services
inside a kind of submesh with its own CA.
With a cross-mesh
you can expose the services of one
Meshes by defining an API with
All traffic remains inside the Kong Mesh data plane protected by mTLS.
All meshes involved in cross-mesh communication must have mTLS enabled.
To enable cross-mesh functionality for a
- port: 8080
If the listener includes a
the cross-mesh listener will be reachable
Meshes at this
In this case, the URL
Otherwise it will be reachable at the host:
Without transparent proxy
If transparent proxy isn’t set up, you’ll have to add the listener explicitly as
an outbound to your
Dataplane objects if you want to access it:
- port: 8080
protocol supported is
Like service to service traffic,
all traffic to the gateway is protected with mTLS
but appears to be HTTP traffic
to the applications inside the mesh.
In the future, this limitation may be relaxed.
There can be only one entry in
Not all Kong Mesh policies are applicable to Kong Mesh Gateway (see table below).
Kong Mesh connection policies are selected by matching the source and destination expressions against sets of Kong Mesh tags.
In the case of Kong Mesh Gateway the source selector is always matched against the Gateway listener tags, and the destination expression is matched against the backend destination tags configured on a Gateway Route.
When a Gateway Route forwards traffic, it may weight the traffic across multiple services.
In this case, matching the destination for a connection policy becomes ambiguous.
Although the traffic is proxied to more than one distinct service, Kong Mesh can only configure the route with one connection policy.
In this case, Kong Mesh employs some simple heuristics to choose the policy.
If all the backend destinations refer to the same service, Kong Mesh will choose the oldest connection policy that has a matching destination service.
However, if the backend destinations refer to different services, Kong Mesh will prefer a connection policy with a wildcard destination (i.e. where the destination service is
Kong Mesh may select different connection policies of the same type depending on the context.
For example, when Kong Mesh configures an Envoy route, there may be multiple candidate policies (due to the traffic splitting across destination services), but when Kong Mesh configures an Envoy cluster there is usually only a single candidate (because clusters are defined to be a single service).
This can result in situations where different policies (of the same type) are used for different parts of the Envoy configuration.
You can find in each policy’s dedicated information with regard to builtin gateway support.