Kuma Star

Careful!

You are browsing documentation for a version of Kuma that is not the latest release.

Configuring your Mesh and multi-tenancy

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.

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

  • Traffic Trace

  • 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. Kuma checkout Kuma’s builtin gateway to set this up.

Usage

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 Deployment, like:

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:
        ...

A Mesh may span multiple Kubernetes namespaces. Any Kuma resource in the cluster which specifies a particular Mesh will be part of that Mesh.

You can control which data plane proxies are allowed to join the mesh using mesh constraints.

Policies

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.

Skipping default resource creation

By default, to help users get started we create the following default policies:

apiVersion: kuma.io/v1alpha1
kind: MeshTimeout
metadata:
  name: mesh-gateways-timeout-all-default
  namespace: kuma-system
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: MeshSubset
    proxyTypes:
    - Gateway
  to:
  - targetRef:
      kind: Mesh
    default:
      idleTimeout: 1h
      http:
        streamIdleTimeout: 5s
  from:
  - targetRef:
      kind: Mesh
    default:
      idleTimeout: 5m
      http:
        streamIdleTimeout: 5s
        requestHeadersTimeout: 500ms
---
apiVersion: kuma.io/v1alpha1
kind: MeshTimeout
metadata:
  name: mesh-timeout-all-default
  namespace: kuma-system
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: Mesh
    proxyTypes:
    - Sidecar
  to:
  - targetRef:
      kind: Mesh
    default:
      connectionTimeout: 5s
      idleTimeout: 1h
      http:
        requestTimeout: 15s
        streamIdleTimeout: 30m
  from:
  - targetRef:
      kind: Mesh
    default:
      connectionTimeout: 10s
      idleTimeout: 2h
      http:
        requestTimeout: 0s
        streamIdleTimeout: 1h
        maxStreamDuration: 0s
---
apiVersion: kuma.io/v1alpha1
kind: MeshRetry
metadata:
  name: mesh-retry-all-default
  namespace: kuma-system
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: Mesh
  to:
  - targetRef:
      kind: Mesh
    default:
      tcp:
        maxConnectAttempt: 5
      http:
        numRetries: 5
        perTryTimeout: 16s
        backOff:
          baseInterval: 25ms
          maxInterval: 250ms
      grpc:
        numRetries: 5
        perTryTimeout: 16s
        backOff:
          baseInterval: 25ms
          maxInterval: 250ms
---
apiVersion: kuma.io/v1alpha1
kind: MeshCircuitBreaker
metadata:
  name: mesh-circuit-breaker-all-default
  namespace: kuma-system
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: Mesh
  to:
  - targetRef:
      kind: Mesh
    default:
      connectionLimits:
        maxConnections: 1024
        maxPendingRequests: 1024
        maxRetries: 3
        maxRequests: 1024

If you want to not have these policies be added on creation of the mesh set the configuration: skipCreatingInitialPolicies:

apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: default
spec:
  skipCreatingInitialPolicies: ['*']

You can also skip creating the default mesh by setting the control-plane configuration: KUMA_DEFAULTS_SKIP_MESH_CREATION=true.

All options