Service Mesh deployment models

Cluster-Wide (Single Tenant) mesh deployment model
Multitenant deployment model
- About migrating to a cluster-wide mesh
Multimesh or federated deployment model

Red Hat OpenShift Service Mesh supports several different deployment models that can be combined in different ways to best suit your business requirements.

In Istio, a tenant is a group of users that share common access and privileges for a set of deployed workloads. You can use tenants to provide a level of isolation between different teams. You can segregate access to different tenants using NetworkPolicies, AuthorizationPolicies, and exportTo annotations on istio.io or service resources.

edit

Cluster-Wide (Single Tenant) mesh deployment model

A cluster-wide deployment contains a Service Mesh Control Plane that monitors resources for an entire cluster. Monitoring resources for an entire cluster closely resembles Istio functionality in that the control plane uses a single query across all namespaces to monitor Istio and Kubernetes resources. As a result, cluster-wide deployments decrease the number of requests sent to the API server.

Similar to Istio, a cluster-wide mesh includes namespaces with the istio-injection=enabled namespace label by default. You can change this label by modifying the spec.labelSelectors field of the ServiceMeshMemberRoll resource.

edit

Multitenant deployment model

Red Hat OpenShift Service Mesh installs a ServiceMeshControlPlane that is configured for multitenancy by default. Red Hat OpenShift Service Mesh uses a multitenant Operator to manage the Service Mesh control plane lifecycle. Within a mesh, namespaces are used for tenancy.

Red Hat OpenShift Service Mesh uses ServiceMeshControlPlane resources to manage mesh installations, whose scope is limited by default to namespace that contains the resource. You use ServiceMeshMemberRoll and ServiceMeshMember resources to include additional namespaces into the mesh. A namespace can only be included in a single mesh, and multiple meshes can be installed in a single OpenShift cluster.

Typical service mesh deployments use a single Service Mesh control plane to configure communication between services in the mesh. Red Hat OpenShift Service Mesh supports “soft multitenancy”, where there is one control plane and one mesh per tenant, and there can be multiple independent control planes within the cluster. Multitenant deployments specify the projects that can access the Service Mesh and isolate the Service Mesh from other control plane instances.

The cluster administrator gets control and visibility across all the Istio control planes, while the tenant administrator only gets control over their specific Service Mesh, Kiali, and Jaeger instances.

You can grant a team permission to deploy its workloads only to a given namespace or set of namespaces. If granted the mesh-user role by the service mesh administrator, users can create a ServiceMeshMember resource to add namespaces to the ServiceMeshMemberRoll.

edit

About migrating to a cluster-wide mesh

In a cluster-wide mesh, one ServiceMeshControlPlane (SMCP) watches all of the namespaces for an entire cluster. You can migrate an existing cluster from a multitenant mesh to a cluster-wide mesh using Red Hat OpenShift Service Mesh version 2.5 or later.

If a cluster must have more than one SMCP, then you cannot migrate to a cluster-wide mesh.

By default, a cluster-wide mesh discovers all of the namespaces that comprise a cluster. However, you can configure the mesh to access a limited set of namespaces. Namespaces do not receive sidecar injection by default. You must specify which namespaces receive sidecar injection.

Similarly, you must specify which pods receive sidecar injection. Pods that exist in a namespace that receives sidecar injection do not inherit sidecar injection. Applying sidecar injection to namespaces and to pods are separate operations.

If you change the Istio version when migrating to a cluster-wide mesh, then you must restart the applications. If you use the same Istio version, the application proxies will connect to the new SMCP for the cluster-wide mesh, and work the same way they did for a multitenant mesh.

edit

Including and excluding namespaces from a cluster-wide mesh by using the web console

By default, the Red Hat OpenShift Service Mesh Operator uses discovery selectors to identify the namespaces that make up the mesh. Namespaces that do not contain the label defined in the ServiceMeshMemberRoll resource are not matched by the discovery selector and are excluded from the mesh.

Prerequisites

You have installed the Red Hat OpenShift Service Mesh Operator.
You have deployed a ServiceMeshControlPlane resource.
You are logged in as a user with the cluster-admin role. If you use Red Hat OpenShift Dedicated, you are logged in as a user with the dedicated-admin role.

Procedure

Log in to the Red Hat OpenShift Service on AWS web console.
Navigate to Operators → Installed Operators.
Click the Red Hat OpenShift Service Mesh Operator.
Click Istio Service Mesh Control Plane.
Click the name of the control plane.
Click YAML.

Modify the YAML file so that the spec.discoverySelectors field of the ServiceMeshMemberRoll resource includes the discovery selector. The following example uses istio-discovery: enabled:

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  mode: ClusterWide
  meshConfig:
    discoverySelectors:
    - matchLabels:
        istio-discovery: enabled (1)
    - matchExpressions:
      - key: kubernetes.io/metadata.name (2)
        operator: NotIn
        values:
        - bookinfo
        - httpbin

1	Ensures that the mesh discovers namespaces that contain the label `istio-discovery: enabled`. The mesh does not discover namespaces that do not contain the label.
2	Ensures that the mesh does not discover namespaces `bookinfo` and `httpbin`.

Save the file.

edit

Including and excluding namespaces from a cluster-wide mesh by using the CLI

Prerequisites

You have installed the Red Hat OpenShift Service Mesh Operator.
You have deployed a ServiceMeshControlPlane resource.
You are logged in as a user with the cluster-admin role. If you use Red Hat OpenShift Dedicated, you are logged in as a user with the dedicated-admin role.

Procedure

Log in to the Red Hat OpenShift Service on AWS CLI.
Open the ServiceMeshControlPlane resource as a YAML file by running the following command:
```
$ oc -n istio-system edit smcp <name> (1)
```
1 <name> represents the name of the ServiceMeshControlPlane resource.

Modify the YAML file so that the spec.discoverySelectors field of the ServiceMeshMemberRoll resource includes the discovery selector. The following example uses istio-discovery: enabled:

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  mode: ClusterWide
  meshConfig:
    discoverySelectors:
    - matchLabels:
        istio-discovery: enabled (1)
    - matchExpressions:
      - key: kubernetes.io/metadata.name (2)
        operator: NotIn
        values:
        - bookinfo
        - httpbin

1	Ensures that the mesh discovers namespaces that contain the label `istio-discovery: enabled`. The mesh does not discover namespaces that do not contain the label.
2	Ensures that the mesh does not discover namespaces `bookinfo` and `httpbin`.

Save the file and exit the editor.

edit

Defining which namespaces receive sidecar injection in a cluster-wide mesh by using the web console

By default, the Red Hat OpenShift Service Mesh Operator uses member selectors to identify which namespaces receive sidecar injection. Namespaces that do not match the istio-injection=enabled label as defined in the ServiceMeshMemberRoll resource do not receive sidecar injection.

Using discovery selectors to determine which namespaces the mesh can discover has no effect on sidecar injection. Discovering namespaces and configuring sidecar injection are separate operations.

Prerequisites

You have installed the Red Hat OpenShift Service Mesh Operator.
You have deployed a ServiceMeshControlPlanae resource with the mode: ClusterWide annotation.
You are logged in as a user with the cluster-admin role. If you use Red Hat OpenShift Dedicated, you are logged in as a user with the dedicated-admin role.

Procedure

Log in to the Red Hat OpenShift Service on AWS web console.
Navigate to Operators → Installed Operators.
Click the Red Hat OpenShift Service Mesh Operator.
Click Istio Service Mesh Member Roll.
Click the ServiceMeshMemberRoll resource.
Click YAML.
Modify the spec.memberSelectors field in the ServiceMeshMemberRoll resource by adding a member selector that matches the inject label. The following example uses istio-injection: enabled:
```
apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
  name: default
spec:
  memberSelectors:
  - matchLabels:
      istio-injection: enabled (1)
```
1 Ensures that the namespace receives sidecar injection.
Save the file.

edit

Defining which namespaces receive sidecar injection in a cluster-wide mesh by using the CLI

Using discovery selectors to determine which namespaces the mesh can discover has no effect on sidecar injection. Discovering namespaces and configuring sidecar injection are separate operations.

Prerequisites

You have installed the Red Hat OpenShift Service Mesh Operator.
You have deployed a ServiceMeshControlPlanae resource with the mode: ClusterWide annotation.
You are logged in as a user with the cluster-admin role. If you use Red Hat OpenShift Dedicated, you are logged in as a user with the dedicated-admin role.

Procedure

Edit the ServiceMeshMemberRoll resource.

$ oc edit smmr -n <controlplane-namespace>

Modify the spec.memberSelectors field in the ServiceMeshMemberRoll resource by adding a member selector that matches the inject label. The following example uses istio-injection: enabled:
```
apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
  name: default
spec:
  memberSelectors:
  - matchLabels:
      istio-injection: enabled (1)
```
1 Ensures that the namespace receives sidecar injection.
Save the file and exit the editor.

edit

Excluding individual pods from a cluster-wide mesh by using the web console

A pod receives sidecar injection if it has the sidecar.istio.io/inject: true annotation applied, and the pod exists in a namespace that matches either the label selector or the members list defined in the ServiceMeshMemberRoll resource.

If a pod does not have the sidecar.istio.io/inject annotation applied, it cannot receive sidecar injection.

Prerequisites

You have installed the Red Hat OpenShift Service Mesh Operator.
You have deployed a ServiceMeshControlPlane resource with the mode: ClusterWide annotation.
You are logged in as a user with the cluster-admin role. If you use Red Hat OpenShift Dedicated, you are logged in as a user with the dedicated-admin role.

Procedure

Log in to the Red Hat OpenShift Service on AWS web console.
Navigate to Workloads → Deployments.
Click the name of the deployment.
Click YAML.

Modify the YAML file to deploy one application that receives sidecar injection and one that does not, as shown in the following example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: 'true' (1)
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-without-sidecar
spec:
  selector:
    matchLabels:
      app: nginx-without-sidecar
  template:
    metadata:
      labels:
        app: nginx-without-sidecar (2)
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

1	This pod has the `sidecar.istio.io/inject` annotation applied, so it receives sidecar injection.
2	This pod does not have the annotation, so it does not receive sidecar injection.

Save the file.

edit

Excluding individual pods from a cluster-wide mesh by using the CLI

If a pod does not have the sidecar.istio.io/inject annotation applied, it cannot receive sidecar injection.

Prerequisites

You have installed the Red Hat OpenShift Service Mesh Operator.
You have deployed a ServiceMeshControlPlane resource with the mode: ClusterWide annotation.
You are logged in as a user with the cluster-admin role. If you use Red Hat OpenShift Dedicated, you are logged in as a user with the dedicated-admin role.

Procedure

Edit the deployment by running the following command:

$ oc edit deployment -n <namespace> <deploymentName>

Modify the YAML file to deploy one application that receives sidecar injection and one that does not, as shown in the following example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: 'true' (1)
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-without-sidecar
spec:
  selector:
    matchLabels:
      app: nginx-without-sidecar
  template:
    metadata:
      labels:
        app: nginx-without-sidecar (2)
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

1	This pod has the `sidecar.istio.io/inject` annotation applied, so it receives sidecar injection.
2	This pod does not have the annotation, so it does not receive sidecar injection.

Save the file.

edit

Multimesh or federated deployment model

Federation is a deployment model that lets you share services and workloads between separate meshes managed in distinct administrative domains.

The Istio multi-cluster model requires a high level of trust between meshes and remote access to all Kubernetes API servers on which the individual meshes reside. Red Hat OpenShift Service Mesh federation takes an opinionated approach to a multi-cluster implementation of Service Mesh that assumes minimal trust between meshes.

A federated mesh is a group of meshes behaving as a single mesh. The services in each mesh can be unique services, for example a mesh adding services by importing them from another mesh, can provide additional workloads for the same services across the meshes, providing high availability, or a combination of both. All meshes that are joined into a federated mesh remain managed individually, and you must explicitly configure which services are exported to and imported from other meshes in the federation. Support functions such as certificate generation, metrics and trace collection remain local in their respective meshes.

Cluster-Wide (Single Tenant) mesh deployment model

Multitenant deployment model

About migrating to a cluster-wide mesh

Including and excluding namespaces from a cluster-wide mesh by using the web console

Including and excluding namespaces from a cluster-wide mesh by using the CLI

Defining which namespaces receive sidecar injection in a cluster-wide mesh by using the web console

Defining which namespaces receive sidecar injection in a cluster-wide mesh by using the CLI

Excluding individual pods from a cluster-wide mesh by using the web console

Excluding individual pods from a cluster-wide mesh by using the CLI

Multimesh or federated deployment model