This resource describes a very important concept in Kong Mesh, and that is the ability of creating multiple isolated service meshes within the same Kong Mesh cluster which in turn make Kong Mesh a very simple and easy project to operate in environments where more than one mesh is required based on security, segmentation or governance requirements.
Typically, we would want to create a Mesh
per line of business, per team, per application or per environment or for any other reason. Typically multiple meshes are being created so that a service mesh can be adopted by an organization with a gradual roll-out that doesn’t require all the teams and their applications to coordinate with each other, or as an extra layer of security and segmentation for our services so that - for example - policies applied to one Mesh
do not affect another Mesh
.
Mesh
is the parent resource of every other resource in Kong Mesh, including:
In order to use Kong Mesh at least one Mesh
must exist, and there is no limit to the number of Meshes that can be created. When a data plane proxy connects to the control plane (kuma-cp
) it specifies to what Mesh
resource it belongs: a data plane proxy can only belong to one Mesh
at a time.
When starting a new Kong Mesh cluster from scratch a
default
Mesh is being created automatically.
Besides the ability of being able to create virtual service mesh, a Mesh
resource will also be used for:
-
Mutual TLS, to secure and encrypt our service traffic and assign an identity to the data plane proxies within the Mesh.
-
Zone Egress, to setup if
ZoneEgress
should be used for cross zone and external service communication. -
Non-mesh traffic, to setup if
passthrough
mode should be used for the non-mesh traffic.
To support cross-mesh communication an intermediate API Gateway must be used. Kong Mesh checkout Kong Mesh’s builtin gateway to set this up.
Previously, observability and locality awareness were configured within the
Mesh
object.However, for enhanced flexibility and granular control, these configurations have been extracted into separate policies:
MeshAccessLog
,MeshTrace
andMeshMetric
for observability, andMeshLoadBalancingStrategy
for locality awareness.This separation allows for more fine-grained adjustments of each aspect, ensuring that observability and locality awareness are tailored to specific requirements.