The Red Hat OpenShift Service Mesh operator supports multi-tenant control plane installations.

  • You cannot use multi-tenant control plane installations in conjunction with a cluster-wide control plane installation. Red Hat OpenShift Service Mesh installations must either be multi-tenant or single, cluster-wide installations.

  • Single-tenant control plane installations are known to cause issues with OpenShift Container Platform restarts and upgrades. Multi-tenant control plane installations are the default configuration starting with Red Hat OpenShift Service Mesh 0.12.TechPreview.

Prerequisites

Known issues with multi-tenant Red Hat OpenShift Service Mesh installations

Here is a summary of the known issues with multi-tenant Service Mesh installations.

Automatic route creation is currently incompatible with multi-tenant Service Mesh installations. Ensure that it is disabled, by setting ior_enabled to false in your ServiceMeshControlPlane if you plan to attempt a multi-tenant installation.

  • MeshPolicy is still a cluster-scoped resource and applies to all control planes installed in OpenShift. This can prevent the installation of multiple control planes or cause unknown behavior if one control plane is deleted.

  • The Jaeger agent runs as a DaemonSet, therefore tracing may only be enabled for a single ServiceMeshControlPlane instance.

  • If you delete the project that contains the control plane before you delete the ServiceMeshControlPlane resource, some parts of the installation may not be removed:

    • Service accounts added to the SecurityContextConstraints may not be removed.

    • OAuthClient resources associated with Kiali may not be removed, or its list of redirectURIs may not be accurate.

Differences between multi-tenant and cluster-wide installations

The main difference between a multi-tenant installation and a cluster-wide installation is the scope of privileges used by the control plane deployments, for example, Galley and Pilot. The components no longer use cluster-scoped Role Based Access Control (RBAC) ClusterRoleBinding, but rely on namespace-scoped RBAC RoleBinding.

Every namespace in the members list will have a RoleBinding for each service account associated with a control plane deployment and each control plane deployment will only watch those member namespaces. Each member namespace has a maistra.io/member-of label added to it, where the member-of value is the namespace containing the control plane installation.

Installing Red Hat OpenShift Service Mesh with multi-tenancy

This procedure describes the how to enable multi-tenancy.

Prerequisites
  • An installed, verified Service Mesh Operator.

  • A custom resource file that defines the parameters of your Red Hat OpenShift Service Mesh control plane.

Procedure
  • Set the multitenant option to true in the istio section of the ServiceMeshControlPlane resource. For example:

    Multi-tenant custom resource example
      apiVersion: maistra.io/v1
      kind: ServiceMeshControlPlane
      spec:
        istio:
          global:
          # enable multitenant
                  multitenant: true
           # additional control plane configuration details

Configuring namespaces in multi-tenant installations

A multi-tenant control plane installation only affects namespaces configured as part of the Service Mesh. You must specify the namespaces associated with the Service Mesh in a ServiceMeshMemberRoll resource located in the same namespace as the ServiceMeshControlPlane resource and name it default.

If Container Network Interface (CNI) is enabled, manual sidecar injection will work, but pods will not be able to communicate with the control plane unless they are a part of the ServiceMeshMemberRoll resource.

The member namespaces are only updated if the Service Mesh control plane installation succeeds.

  • You can add any number of namespaces, but a namespace can only belong to one ServiceMeshMemberRoll.

  • ServiceMeshMemberRoll resources are reconciled in response to the following events:

    • The ServiceMeshMemberRoll is created, updated, or deleted

    • The ServiceMeshControlPlane resource in the namespace containing the ServiceMeshMemberRoll is created or updated

    • A namespace listed in the ServiceMeshMemberRoll is created or deleted

The ServiceMeshMemberRoll is deleted when its corresponding ServiceMeshControlPlane resource is deleted.

Here is an example that joins the bookinfo namespace into the Service Mesh:

Prerequisites
  • An installed, verified Service Mesh Operator.

  • Location of the namespace where the custom resource installed the control plane.

Procedure
  1. Create a custom resource file named ServiceMeshMemberRoll in the same namespace as the ServiceMeshControlPlane custom resource.

  2. Name the resource default.

  3. Add the namespaces to the member list in the ServiceMeshMemberRoll. The bookinfo namespace is joined to the Service Mesh in this example.

    Namespace configuration example
      apiVersion: maistra.io/v1
      kind: ServiceMeshMemberRoll
      metadata:
        name: default
      spec:
        members:
        # a list of namespaces joined into the service mesh
        - bookinfo
Next steps
  • Prepare to deploy applications on Red Hat OpenShift Service Mesh.