Create multiple service meshes in a cluster
This resource describes a very important concept in Kuma, and that is the ability of creating multiple isolated service meshes within the same Kuma cluster which in turn make Kuma 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 is the parent resource of every other resource in Kuma, including:
In order to use Kuma 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 Kuma 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.
- Traffic Metrics, to setup metrics backend that will be used to collect and visualize metrics of our service mesh and service traffic within the Mesh.
- Traffic Trace, to setup tracing backends that will be used to collect traces of our service traffic within the Mesh.
- Zone Egress
, to setup if
ZoneEgressshould be used for cross zone and external service communication.
- Non-mesh traffic, to setup if
passthroughmode should be used for the non-mesh traffic.
When Mutual TLS is enabled in
builtin mode, each
Mesh will provision its own CA root certificate and key unless we explicitly decide to use the same CA by sharing the same certificate and key across multiple meshes. When the CAs of our Meshes are different, data plane proxies from one
Mesh will not be able to consume data plane proxies belonging to another
Mesh and an intermediate API Gateway must be used in order to enable cross-mesh communication. Kuma supports a gateway mode to make this happen.
The easiest way to create a
Mesh is to specify its
name. The name of a Mesh must be unique.
apiVersion: kuma.io/v1alpha1 kind: Mesh metadata: name: default
We will apply the configuration with
kubectl apply -f [..].
Creating resources in a Mesh
It is possible to determine to what
Mesh other resources belong to in the following ways.
Data plane proxies
Every time we start a data plane proxy, we need to specify to what
Mesh it belongs, this can be done in the following way:
By using the
kuma.io/mesh annotation in a
apiVersion: apps/v1 kind: Deployment metadata: name: example-app namespace: kuma-example spec: ... template: metadata: ... annotations: # indicate to Kuma what is the Mesh that the data plane proxy belongs to kuma.io/mesh: default spec: containers: ...
Mesh may span multiple Kubernetes namespaces. Any Kuma resource in the cluster which
specifies a particular
Mesh will be part of that
You can control which data plane proxies are allowed to join the mesh using [mesh constraints] (/docs/2.4.x/production/secure-deployment/dp-membership/) .
When creating new Policies we also must specify to what
Mesh they belong. This can be done in the following way:
By using the
mesh property, like:
apiVersion: kuma.io/v1alpha1 kind: TrafficRoute mesh: default # indicate to Kuma what is the Mesh that the resource belongs to metadata: name: route-1 spec: ...
Kuma consumes all Policies on the cluster and joins each to an individual
Mesh, identified by this property.