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
.
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.
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 OpenShift Dedicated 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.
Including and excluding namespaces from a cluster-wide mesh by using the CLI
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 OpenShift Dedicated 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.
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 OpenShift Dedicated 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.
Defining which namespaces receive sidecar injection in a cluster-wide mesh by using the CLI
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 OpenShift Dedicated CLI.
-
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.
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 OpenShift Dedicated 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.
Excluding individual pods from a cluster-wide mesh by using the CLI
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 OpenShift Dedicated CLI.
-
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.