Chapter 2. Service Mesh Installation

2.1. Preparing to install Red Hat OpenShift Service Mesh

Before you can install Red Hat OpenShift Service Mesh, review the installation activities, ensure that you meet the prerequisites:

Prerequisites

Possess an active OpenShift Container Platform subscription on your Red Hat account. If you do not have a subscription, contact your sales representative for more information.
Review the OpenShift Container Platform 4.1 overview.
Install OpenShift Container Platform 4.1.
Install the version of the OpenShift Container Platform command line utility (the oc client tool) that matches your OpenShift Container Platform version and add it to your path.
- If you are using OpenShift Container Platform 4.1, see About the CLI.

2.1.1. Red Hat OpenShift Service Mesh supported configurations

The following are the only supported configurations for the Red Hat OpenShift Service Mesh 1.0.10:

Red Hat OpenShift Container Platform version 4.1.

Note

OpenShift Online and OpenShift Dedicated are not supported for Red Hat OpenShift Service Mesh 1.0.10.

The deployment must be contained to a single OpenShift Container Platform cluster that is not federated.
This release of Red Hat OpenShift Service Mesh is only available on OpenShift Container Platform x86_64.
Red Hat OpenShift Service Mesh is only suited for OpenShift Container Platform Software Defined Networking (SDN) configured as a flat network with no external providers.
This release only supports configurations where all Service Mesh components are contained in the OpenShift cluster in which it operates. It does not support management of microservices that reside outside of the cluster, or in a multi-cluster scenario.
This release only supports configurations that do not integrate external services such as virtual machines.

2.1.1.1. Supported configurations for Kiali on Red Hat OpenShift Service Mesh

The Kiali observability console is only supported on the two most recent releases of the Chrome, Edge, Firefox, or Safari browsers.

2.1.1.2. Supported Mixer adapters

This release only supports the following Mixer adapter:
- 3scale Istio Adapter

2.1.2. Red Hat OpenShift Service Mesh installation activities

To install the Red Hat OpenShift Service Mesh Operator, you must first install these Operators:

Warning

Please see Configuring Elasticsearch for details on configuring the default Jaeger parameters for Elasticsearch in a production environment.

Elasticsearch - Based on the open source Elasticsearch project that enables you to configure and manage an Elasticsearch cluster for tracing and logging with Jaeger.
Jaeger - based on the open source Jaeger project, lets you perform tracing to monitor and troubleshoot transactions in complex distributed systems.
Kiali - based on the open source Kiali project, provides observability for your service mesh. By using Kiali you can view configurations, monitor traffic, and view and analyze traces in a single console.

After you install the Elasticsearch, Jaeger, and Kiali Operators, then you install the Red Hat OpenShift Service Mesh Operator. The Service Mesh Operator defines and monitors the ServiceMeshControlPlane resources that manage the deployment, updating, and deletion of the Service Mesh components.

Red Hat OpenShift Service Mesh - based on the open source Istio project, lets you connect, secure, control, and observe the microservices that make up your applications.

Next steps

Install Red Hat OpenShift Service Mesh in your OpenShift Container Platform environment.

2.2. Installing Red Hat OpenShift Service Mesh

Installing the Service Mesh involves installing the Elasticsearch, Jaeger, Kiali and Service Mesh Operators, creating and managing a ServiceMeshControlPlane resource to deploy the control plane, and creating a ServiceMeshMemberRoll resource to specify the namespaces associated with the Service Mesh.

Note

Mixer’s policy enforcement is disabled by default. You must enable it to run policy tasks. See Update Mixer policy enforcement for instructions on enabling Mixer policy enforcement.

Note

Multi-tenant control plane installations are the default configuration starting with Red Hat OpenShift Service Mesh 1.0.

Prerequisites

Follow the Preparing to install Red Hat OpenShift Service Mesh process.
An account with cluster administration access.

2.2.1. Installing the Operators from OperatorHub

The Service Mesh installation process uses the OperatorHub to install the ServiceMeshControlPlane custom resource definition within the openshift-operators project. The Red Hat OpenShift Service Mesh defines and monitors the ServiceMeshControlPlane related to the deployment, update, and deletion of the control plane.

Starting with Red Hat OpenShift Service Mesh 1.0.10, you must install the Elasticsearch Operator, the Jaeger Operator, and the Kiali Operator before the Red Hat OpenShift Service Mesh Operator can install the control plane.

2.2.1.1. Installing the Elasticsearch Operator

You must install the Elasticsearch Operator for the Red Hat OpenShift Service Mesh Operator to install the control plane.

Warning

Do not install Community versions of the Operators. Community Operators are not supported.

Prerequisites

Access to the OpenShift Container Platform web console.

Procedure

Log in to the OpenShift Container Platform web console.
Navigate to Catalog OperatorHub.
Type Elasticsearch into the filter box to locate the Elasticsearch Operator.
Click the Elasticsearch Operator to display information about the Operator.
Click Install.
On the Create Operator Subscription page, select All namespaces on the cluster (default). This installs the Operator in the default openshift-operators project and makes the Operator available to all projects in the cluster.
Select the preview Update Channel.
Select the Automatic Approval Strategy.
Note
The Manual approval strategy requires a user with appropriate credentials to approve the Operator install and subscription process.
Click Subscribe.
The Subscription Overview page displays the Elasticsearch Operator’s installation progress.

2.2.1.2. Installing the Jaeger Operator

You must install the Jaeger Operator for the Red Hat OpenShift Service Mesh Operator to install the control plane.

Warning

Do not install Community versions of the Operators. Community Operators are not supported.

Prerequisites

Access to the OpenShift Container Platform web console.
The Elasticsearch Operator must be installed.

Procedure

Log in to the OpenShift Container Platform web console.
Navigate to Catalog OperatorHub.
Type Jaeger into the filter box to locate the Jaeger Operator.
Click the Jaeger Operator provided by Red Hat to display information about the Operator.
Click Install.
On the Create Operator Subscription page, select All namespaces on the cluster (default). This installs the Operator in the default openshift-operators project and makes the Operator available to all projects in the cluster.
Select the stable Update Channel.
Select the Automatic Approval Strategy.
Note
The Manual approval strategy requires a user with appropriate credentials to approve the Operator install and subscription process.
Click Subscribe.
The Subscription Overview page displays the Jaeger Operator’s installation progress.

2.2.1.3. Installing the Kiali Operator

You must install the Kiali Operator for the Red Hat OpenShift Service Mesh Operator to install the control plane.

Warning

Do not install Community versions of the Operators. Community Operators are not supported.

Prerequisites

Access to the OpenShift Container Platform web console.

Procedure

Log in to the OpenShift Container Platform web console.
Navigate to Catalog OperatorHub.
Type Kiali into the filter box to find the Kiali Operator.
Click the Kiali Operator provided by Red Hat to display information about the Operator.
Click Install.
On the Create Operator Subscription page, select All namespaces on the cluster (default). This installs the Operator in the default openshift-operators project and makes the Operator available to all projects in the cluster.
Select the stable Update Channel.
Select the Automatic Approval Strategy.
Note
The Manual approval strategy requires a user with appropriate credentials to approve the Operator install and subscription process.
Click Subscribe.
The Subscription Overview page displays the Kiali Operator’s installation progress.

2.2.1.4. Installing the Red Hat OpenShift Service Mesh Operator

Prerequisites

Access to the OpenShift Container Platform web console.
The Elasticsearch Operator must be installed.
The Jaeger Operator must be installed.
The Kiali Operator must be installed.

Procedure

Log in to the OpenShift Container Platform web console.
Navigate to Catalog OperatorHub.
Type Red Hat OpenShift Service Mesh into the filter box to find the Red Hat OpenShift Service Mesh Operator.
Click the Red Hat OpenShift Service Mesh Operator to display information about the Operator.
On the Create Operator Subscription page, select All namespaces on the cluster (default). This installs the Operator in the default openshift-operators project and makes the Operator available to all projects in the cluster.
Click Install.
Select the 1.0 Update Channel.
Select the Automatic Approval Strategy.
Note
The Manual approval strategy requires a user with appropriate credentials to approve the Operator install and subscription process.
Click Subscribe.
The Subscription Overview page displays the Red Hat OpenShift Service Mesh Operator’s installation progress.

2.2.2. Deploying the Red Hat OpenShift Service Mesh control plane

You can deploy the Service Mesh control plane by using the OpenShift Container Platform web console or the CLI.

2.2.2.1. Deploying the control plane with the web console

Follow this procedure to deploy the Red Hat OpenShift Service Mesh control plane by using the web console.

Prerequisites

The Red Hat OpenShift Service Mesh Operator must be installed.
Review the Customize the Red Hat OpenShift Service Mesh installation instructions.

Procedure

Log in to the OpenShift Container Platform web console.
Create a project named istio-system.
Navigate to Catalogs Installed Operators.
Click the Red Hat OpenShift Service Mesh Operator.
Under Provided APIs, the Operator enables you to create two resource types:
- A ServiceMeshControlPlane resource
- A ServiceMeshMemberRoll resource
Click Create New under Istio Service Mesh Control Plane.
Modify the minimal ServiceMeshControlPlane template.
Note
Review Customize the Red Hat OpenShift Service Mesh installation for additional information on customizing the control plane and control plane parameters.
Click Create to create the control plane.
The Operator starts up the pods, services, and Service Mesh control plane components.
Click the Istio Service Mesh Control Plane tab.
Click the name of the new control plane.
Click the Resources tab to see the Red Hat OpenShift Service Mesh control plane resources the Operator created and configured.

2.2.2.2. Deploying the control plane from the CLI

Follow this procedure to deploy the Red Hat OpenShift Service Mesh control plane by using the CLI.

Prerequisites

The Red Hat OpenShift Service Mesh Operator must be installed.
Review the Customize the Red Hat OpenShift Service Mesh installation instructions.
Access to the OpenShift Container Platform Command-line Interface (CLI) also known as oc.

Note

Review Customize the Red Hat OpenShift Service Mesh installation for additional information on customizing the control plane and control plane parameters.

Procedure

Log in to the OpenShift Container Platform CLI.
Create a ServiceMeshControlPlane file named istio-installation.yaml.

Run this command to deploy the control plane:

$ oc create -n istio-system -f istio-installation.yaml

Run this command to watch the progress of the pods during the installation process:
```
$ oc get pods -n istio-system -w
```

2.2.3. Updating your application pods

If you selected the Automatic Approval Strategy when you were installing your Operators, then the Operators update the control plane automatically, but not your applications. Existing applications continue to be part of the mesh and function accordingly. The application administrator must restart applications to upgrade the sidecar.

If your deployment uses Automatic sidecar injection, you can update the pod template in the deployment by adding or modifying an annotation. Run the following command to redeploy the pods:

$ oc patch deployment/<deployment> -p '{"spec":{"template":{"metadata":{"annotations":{"kubectl.kubernetes.io/restartedAt": "'`date -Iseconds`'"}}}}}'

If your deployment does not use automatic sidecar injection, you must manually update the sidecars by modifying the sidecar container image specified in the deployment or pod.

2.2.4. Configure the Red Hat OpenShift Service Mesh member roll

You must create a ServiceMeshMemberRoll resource named default associated with the Service Mesh in the same project as the ServiceMeshControlPlane.

Warning

If Container Network Interface (CNI) plugin is enabled, manual sidecar injection will work, but pods will not be able to communicate with the control plane unless those pods are specified in the ServiceMeshMemberRoll resource.

Note

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

You can add any number of projects, but a project can only belong to one ServiceMeshMemberRoll resource.

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

2.2.4.1. Configure the member roll from the OpenShift Container Platform web console

Follow this procedure to add the Bookinfo project to the Service Mesh member roll by using the web console.

Prerequisites

An installed, verified Red Hat OpenShift Service Mesh Operator.

Procedure

Log in to the OpenShift Container Platform web console.
Click to Home Projects.
Click Create Project.
Enter a Project Name (for example, bookinfo), a Display Name, and a Description, then click Create.
Click Catalog Installed Operators.
Click the Project menu and choose istio-system from the list.
Click the Istio Service Mesh Member Roll link under Provided APIs for the Red Hat OpenShift Service Mesh Operator.
Click on All Instances, click Create New, and then click Create Istio Service Mesh Member Roll.
Note
It can take a short time for the Operator to finish creating the projects, therefore you may need to refresh the screen before the web console presents the Create Istio Service Mesh Member Roll button.
Edit the default Service Mesh Member Roll YAML and add bookinfo to the members list.
Click Create to save the updated Service Mesh Member Roll.

2.2.4.2. Configure the member roll from the CLI

This example joins the Bookinfo project to the Service Mesh from the CLI.

Prerequisites

An installed, verified Service Mesh Operator.
Name of the project with the ServiceMeshMemberRoll resource.
Access to the OpenShift Container Platform Command-line Interface (CLI) also known as oc.

Procedure

Log in to the OpenShift Container Platform CLI.
Create ServiceMeshMemberRoll resource in the same project as the ServiceMeshControlPlane resource.
Name the resource default.
Add the Bookinfo project to the member list in the ServiceMeshMemberRoll. In this example, the bookinfo project is joined to the Service Mesh deployed in the same project as the ServiceMeshMembereRoll resource.
Project configuration example
```
  apiVersion: maistra.io/v1
  kind: ServiceMeshMemberRoll
  metadata:
    name: default
  spec:
    members:
    # a list of projects joined into the service mesh
    - bookinfo
```

Next steps

Customize the Red Hat OpenShift Service Mesh installation.
Prepare to deploy applications on Red Hat OpenShift Service Mesh.

2.3. Customizing the Red Hat OpenShift Service Mesh installation

You can customize your Red Hat OpenShift Service Mesh by modifying the default Service Mesh custom resource or by creating a new custom resource.

Prerequisites

An account with the cluster-admin role.
Completed the Preparing to install Red Hat OpenShift Service Mesh process.
Have installed the operators.

2.3.1. Red Hat OpenShift Service Mesh custom resources

Note

The istio-system project is used as an example throughout the Service Mesh documentation, but you can use other projects as necessary.

A custom resource allows you to extend the API in an Red Hat OpenShift Service Mesh project or cluster. When you deploy Service Mesh it creates a default ServiceMeshControlPlane that you can modify to change the project parameters.

The Service Mesh operator extends the API by adding the ServiceMeshControlPlane resource type, which enables you to create ServiceMeshControlPlane objects within projects. By creating a ServiceMeshControlPlane object, you instruct the Operator to install a Service Mesh control plane into the project, configured with the parameters you set in the ServiceMeshControlPlane object.

This example ServiceMeshControlPlane definition contains all of the supported parameters and deploys Red Hat OpenShift Service Mesh 1.0.10 images based on Red Hat Enterprise Linux (RHEL).

Important

The 3scale Istio Adapter is deployed and configured in the custom resource file. It also requires a working 3scale account (SaaS or On-Premises).

Full example istio-installation.yaml

  apiVersion: maistra.io/v1
  kind: ServiceMeshControlPlane
  metadata:
    name: full-install
  spec:

    istio:
      global:
        proxy:
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 128Mi

      gateways:
        istio-egressgateway:
          autoscaleEnabled: false
        istio-ingressgateway:
          autoscaleEnabled: false

      mixer:
        policy:
          autoscaleEnabled: false

        telemetry:
          autoscaleEnabled: false
          resources:
            requests:
              cpu: 100m
              memory: 1G
            limits:
              cpu: 500m
              memory: 4G

      pilot:
        autoscaleEnabled: false
        traceSampling: 100

      kiali:
        enabled: true

      grafana:
        enabled: true

      tracing:
        enabled: true
        jaeger:
          template: all-in-one

2.3.2. `ServiceMeshControlPlane` parameters

The following examples illustrate use of the ServiceMeshControlPlane parameters and the tables provide additional information about supported parameters.

Important

The resources you configure for Red Hat OpenShift Service Mesh with these parameters, including CPUs, memory, and the number of pods, are based on the configuration of your OpenShift cluster. Configure these parameters based on the available resources in your current cluster configuration.

2.3.2.1. Istio global example

Here is an example that illustrates the Istio global parameters for the ServiceMeshControlPlane and a description of the available parameters with appropriate values.

Note

In order for the 3scale Istio Adapter to work, disablePolicyChecks must be false.

Example global parameters

  istio:
    global:
      tag: 1.0.0
      hub: registry.redhat.io/openshift-service-mesh/
      proxy:
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 128Mi
      mtls:
        enabled: false
      disablePolicyChecks: true
      policyCheckFailOpen: false
      imagePullSecrets:
        - MyPullSecret

Table 2.1. Global parameters
Parameter	Description	Values	Default value
`disablePolicyChecks`	This parameter enables/disables policy checks.	`true`/`false`	`true`
`policyCheckFailOpen`	This parameter indicates whether traffic is allowed to pass through to the Envoy sidecar when the Mixer policy service cannot be reached.	`true`/`false`	`false`
`tag`	The tag that the Operator uses to pull the Istio images.	A valid container image tag.	`1.0.0`
`hub`	The hub that the Operator uses to pull Istio images.	A valid image repository.	`maistra/` or `registry.redhat.io/openshift-service-mesh/`
`mtls`	This parameter controls whether to enable/disable Mutual Transport Layer Security (mTLS) between services by default.	`true`/`false`	`false`
`imagePullSecrets`	If access to the registry providing the Istio images is secure, list an imagePullSecret here.	redhat-registry-pullsecret OR quay-pullsecret	None

These parameters are specific to the proxy subset of global parameters.

Table 2.2. Proxy parameters
Type	Parameter	Description	Values	Default value
Resources	`cpu`	The amount of CPU resources requested for Envoy proxy.	CPU resources, specified in cores or millicores (for example, 200m, 0.5, 1) based on your environment’s configuration.	`100m`
	`memory`	The amount of memory requested for Envoy proxy	Available memory in bytes(for example, 200Ki, 50Mi, 5Gi) based on your environment’s configuration.	`128Mi`
Limits	`cpu`	The maximum amount of CPU resources requested for Envoy proxy.	CPU resources, specified in cores or millicores (for example, 200m, 0.5, 1) based on your environment’s configuration.	`2000m`
	`memory`	The maximum amount of memory Envoy proxy is permitted to use.	Available memory in bytes (for example, 200Ki, 50Mi, 5Gi) based on your environment’s configuration.	`128Mi`

2.3.2.2. Istio gateway configuration

Here is an example that illustrates the Istio gateway parameters for the ServiceMeshControlPlane and a description of the available parameters with appropriate values.

Example gateway parameters

  gateways:
       istio-egressgateway:
         autoscaleEnabled: false
         autoscaleMin: 1
         autoscaleMax: 5
       istio-ingressgateway:
         autoscaleEnabled: false
         autoscaleMin: 1
         autoscaleMax: 5

Table 2.3. Istio Gateway parameters
Type	Parameter	Description	Values	Default value
`istio-egressgateway`	`autoscaleEnabled`	This parameter enables/disables autoscaling.	`true`/`false`	`true`
	`autoscaleMin`	The minimum number of pods to deploy for the egress gateway based on the `autoscaleEnabled` setting.	A valid number of allocatable pods based on your environment’s configuration.	`1`
	`autoscaleMax`	The maximum number of pods to deploy for the egress gateway based on the `autoscaleEnabled` setting.	A valid number of allocatable pods based on your environment’s configuration.	`5`
`istio-ingressgateway`	`autoscaleEnabled`	This parameter enables/disables autoscaling.	`true`/`false`	`true`
	`autoscaleMin`	The minimum number of pods to deploy for the ingress gateway based on the `autoscaleEnabled` setting.	A valid number of allocatable pods based on your environment’s configuration.	`1`
	`autoscaleMax`	The maximum number of pods to deploy for the ingress gateway based on the `autoscaleEnabled` setting.	A valid number of allocatable pods based on your environment’s configuration.	`5`

2.3.2.3. Istio Mixer configuration

Here is an example that illustrates the Mixer parameters for the ServiceMeshControlPlane and a description of the available parameters with appropriate values.

Example mixer parameters

mixer:
  enabled: true
  policy:
    autoscaleEnabled: false
  telemetry:
    autoscaleEnabled: false
    resources:
      limits:
        cpu: 500m
        memory: 4G
      requests:
        cpu: 100m
        memory: 1G

Table 2.4. Istio Mixer policy parameters
Parameter	Description	Values	Default value
`enabled`	This parameter enables/disables Mixer.	`true`/`false`	`true`
`autoscaleEnabled`	This parameter enables/disables autoscaling. Disable this for small environments.	`true`/`false`	`true`
`autoscaleMin`	The minimum number of pods to deploy based on the `autoscaleEnabled` setting.	A valid number of allocatable pods based on your environment’s configuration.	`1`
`autoscaleMax`	The maximum number of pods to deploy based on the `autoscaleEnabled` setting.	A valid number of allocatable pods based on your environment’s configuration.	`5`

Table 2.5. Istio Mixer telemetry parameters
Type	Parameter	Description	Values	Default
Resources	`cpu`	The percentage of CPU resources requested for Mixer telemetry.	CPU resources in millicores based on your environment’s configuration.	`100m`
	`memory`	The amount of memory requested for Mixer telemetry.	Available memory in bytes (for example, 200Ki, 50Mi, 5Gi) based on your environment’s configuration.	`1G`
Limits	`cpu`	The maximum percentage of CPU resources Mixer telemetry is permitted to use.	CPU resources in millicores based on your environment’s configuration.	`500m`
	`memory`	The maximum amount of memory Mixer telemetry is permitted to use.	Available memory in bytes (for example, 200Ki, 50Mi, 5Gi) based on your environment’s configuration.	`4G`

2.3.2.4. Istio Pilot configuration

Here is an example that illustrates the Istio Pilot parameters for the ServiceMeshControlPlane and a description of the available parameters with appropriate values.

Example pilot parameters

  pilot:
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
    autoscaleEnabled: false
    traceSampling: 100

Table 2.6. Istio Pilot parameters
Parameter	Description	Values	Default value
`cpu`	The percentage of CPU resources requested for Pilot.	CPU resources in millicores based on your environment’s configuration.	`500m`
`memory`	The amount of memory requested for Pilot.	Available memory in bytes (for example, 200Ki, 50Mi, 5Gi) based on your environment’s configuration.	`2048Mi`
`autoscaleEnabled`	This parameter enables/disables autoscaling. Disable this for small environments.	`true`/`false`	`true`
`traceSampling`	This value controls how often random sampling occurs. Note: Increase for development or testing.	A valid percentage.	`100`

2.3.3. Configuring Kiali

When the Service Mesh Operator creates the ServiceMeshControlPlane it also processes the Kiali resource. The Kiali Operator then uses this object when creating Kiali instances.

The default Kiali parameters specified in the ServiceMeshControlPlane are as follows:

Example Kiali parameters

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
    kiali:
      enabled: true
      dashboard:
        viewOnlyMode: false
      ingress:
        enabled: true

Table 2.7. Kiali parameters
Parameter	Description	Values	Default value
enabled	This parameter enables/disables Kiali. Kiali is enabled by default.	`true`/`false`	`true`
dashboard viewOnlyMode	This parameter enables/disables view-only mode for the Kiali console. When view-only mode is enabled, users cannot use the console to make changes to the Service Mesh.	`true`/`false`	`false`
ingress enabled	This parameter enables/disables ingress for Kiali.	`true`/`false`	`true`

2.3.3.1. Configuring Kiali for Grafana

When you install Kiali and Grafana as part of Red Hat OpenShift Service Mesh the Operator configures the following by default:

Grafana is enabled as an external service for Kiali
Grafana authorization for the Kiali console
Grafana URL for the Kiali console

Kiali can automatically detect the Grafana URL. However if you have a custom Grafana installation that is not easily auto-detectable by Kiali, you must update the URL value in the ServiceMeshControlPlane resource.

Additional Grafana parameters

spec:
  kiali:
    enabled: true
    dashboard:
      viewOnlyMode: false
      grafanaURL:  "https://grafana-istio-system.127.0.0.1.nip.io"
    ingress:
      enabled: true

2.3.3.2. Configuring Kiali for Jaeger

When you install Kiali and Jaeger as part of Red Hat OpenShift Service Mesh the Operator configures the following by default:

Jaeger is enabled as an external service for Kiali
Jaeger authorization for the Kiali console
Jaeger URL for the Kiali console

Kiali can automatically detect the Jaeger URL. However if you have a custom Jaeger installation that is not easily auto-detectable by Kiali, you must update the URL value in the ServiceMeshControlPlane resource.

Additional Jaeger parameters

spec:
  kiali:
    enabled: true
    dashboard:
      viewOnlyMode: false
      jaegerURL: "http://jaeger-query-istio-system.127.0.0.1.nip.io"
    ingress:
      enabled: true

2.3.4. Configuring Jaeger

When the Service Mesh Operator creates the ServiceMeshControlPlane resource it also creates the Jaeger resource. The Jaeger Operator then uses this object when creating Jaeger instances.

The default Jaeger parameters specified in the ServiceMeshControlPlane are as follows:

Default all-in-one Jaeger parameters

  apiVersion: maistra.io/v1
  kind: ServiceMeshControlPlane
  spec:
    istio:
      tracing:
        enabled: true
        jaeger:
          template: all-in-one

Table 2.8. Jaeger parameters
Parameter	Description	Values	Default value
tracing enabled	This parameter enables/disables tracing in Service Mesh. Jaeger is installed by default.	`true`/`false`	`true`
jaeger template	This parameter specifies which Jaeger deployment strategy to use.	`all-in-one`- For development, testing, demonstrations, and proof of concept. `production-elasticsearch` - For production use.	`all-in-one`

Note

The default template in the ServiceMeshControlPlane resource is the all-in-one deployment strategy which uses in-memory storage. For production, the only supported storage option is Elasticsearch, therefore you must configure the ServiceMeshControlPlane to request the production-elasticsearch template when you deploy Service Mesh within a production environment.

2.3.4.1. Configuring Elasticsearch

The default Jaeger deployment strategy uses the all-in-one template so that the installation can be completed using minimal resources. However, because the all-in-one template uses in-memory storage, it is only recommended for development, demo, or testing purposes and should NOT be used for production environments.

If you are deploying Service Mesh and Jaeger in a production environment you must change the template to the production-elasticsearch template, which uses Elasticsearch for Jaeger’s storage needs.

Elasticsearch is a memory intensive application. The initial set of nodes specified in the default OpenShift Container Platform installation may not be large enough to support the Elasticsearch cluster. You should modify the default Elasticsearch configuration to match your use case and the resources you have requested for your OpenShift Container Platform installation. You can adjust both the CPU and memory limits for each component by modifying the resources block with valid CPU and memory values. Additional nodes must be added to the cluster if you want to run with the recommended amount (or more) of memory. Ensure that you do not exceed the resources requested for your OpenShift Container Platform installation.

Default production-elasticsearch parameters

  apiVersion: maistra.io/v1
  kind: ServiceMeshControlPlane
  spec:
    istio:
      tracing:
      enabled: true
      ingress:
        enabled: true
      jaeger:
        template: production-elasticsearch
        elasticsearch:
          nodeCount: 3
          redundancyPolicy:
          resources:
            requests:
              cpu: "1"
              memory: "16Gi"
            limits:
              cpu: "1"
              memory: "16Gi"

Table 2.9. Elasticsearch parameters
Parameter	Description	Values	Default Value	Examples
tracing: enabled	This parameter enables/disables tracing in Service Mesh. Jaeger is installed by default.	`true`/`false`	`true`
ingress: enabled	This parameter enables/disables ingress for Jaeger.	`true`/`false`	`true`
jaeger template	This parameter specifies which Jaeger deployment strategy to use.	`all-in-one`/`production-elasticsearch`	`all-in-one`
elasticsearch: nodeCount	Number of Elasticsearch nodes to create.	Integer value.	1	Proof of concept = 1, Minimum deployment =3
requests: cpu	Number of central processing units for requests, based on your environment’s configuration.	Specified in cores or millicores (for example, 200m, 0.5, 1).	1Gi	Proof of concept = 500m, Minimum deployment =1
requests: memory	Available memory for requests, based on your environment’s configuration.	Specified in bytes (for example, 200Ki, 50Mi, 5Gi).	500m	Proof of concept = 1Gi, Minimum deployment = 16Gi*
limits: cpu	Limit on number of central processing units, based on your environment’s configuration.	Specified in cores or millicores (for example, 200m, 0.5, 1).		Proof of concept = 500m, Minimum deployment =1
limits: memory	Available memory limit based on your environment’s configuration.	Specified in bytes (for example, 200Ki, 50Mi, 5Gi).		Proof of concept = 1Gi, Minimum deployment = 16Gi*
	* Each Elasticsearch node can operate with a lower memory setting though this is not recommended for production deployments. For production use, you should have no less than 16Gi allocated to each Pod by default, but preferably allocate as much as you can, up to 64Gi per Pod.

Procedure

Log in to the OpenShift Container Platform web console as a user with the cluster-admin role.
Navigate to Catalogs Installed Operators.
Click the Red Hat OpenShift Service Mesh Operator.
Click the Istio Service Mesh Control Plane tab.
Click the name of your control plane file, for example, basic-install.
Click the YAML tab.
Edit the Jaeger parameters, replacing the default all-in-one template with parameters for the production-elasticsearch template, modified for your use case. Ensure that the indentation is correct.
Click Save.
Click Reload. OpenShift Container Platform redeploys Jaeger and creates the Elasticsearch resources based on the specified parameters.

For more information about configuring Elasticsearch with OpenShift Container Platform, see Configuring Elasticsearch.

2.3.5. 3scale configuration

Here is an example that illustrates the 3scale Istio Adapter parameters for the Red Hat OpenShift Service Mesh custom resource and a description of the available parameters with appropriate values.

Example 3scale parameters

  threeScale:
      enabled: false
      PARAM_THREESCALE_LISTEN_ADDR: 3333
      PARAM_THREESCALE_LOG_LEVEL: info
      PARAM_THREESCALE_LOG_JSON: true
      PARAM_THREESCALE_LOG_GRPC: false
      PARAM_THREESCALE_REPORT_METRICS: true
      PARAM_THREESCALE_METRICS_PORT: 8080
      PARAM_THREESCALE_CACHE_TTL_SECONDS: 300
      PARAM_THREESCALE_CACHE_REFRESH_SECONDS: 180
      PARAM_THREESCALE_CACHE_ENTRIES_MAX: 1000
      PARAM_THREESCALE_CACHE_REFRESH_RETRIES: 1
      PARAM_THREESCALE_ALLOW_INSECURE_CONN: false
      PARAM_THREESCALE_CLIENT_TIMEOUT_SECONDS: 10
      PARAM_THREESCALE_GRPC_CONN_MAX_SECONDS: 60

Table 2.10. 3scale parameters
Parameter	Description	Values	Default value
`enabled`	Whether to use the 3scale adapter	`true`/`false`	`false`
`PARAM_THREESCALE_LISTEN_ADDR`	Sets the listen address for the gRPC server	Valid port number	`3333`
`PARAM_THREESCALE_LOG_LEVEL`	Sets the minimum log output level.	`debug`, `info`, `warn`, `error`, or `none`	`info`
`PARAM_THREESCALE_LOG_JSON`	Controls whether the log is formatted as JSON	`true`/`false`	`true`
`PARAM_THREESCALE_LOG_GRPC`	Controls whether the log contains gRPC info	`true`/`false`	`true`
`PARAM_THREESCALE_REPORT_METRICS`	Controls whether 3scale system and backend metrics are collected and reported to Prometheus	`true`/`false`	`true`
`PARAM_THREESCALE_METRICS_PORT`	Sets the port that the 3scale `/metrics` endpoint can be scrapped from	Valid port number	`8080`
`PARAM_THREESCALE_CACHE_TTL_SECONDS`	Time period, in seconds, to wait before purging expired items from the cache	Time period in seconds	`300`
`PARAM_THREESCALE_CACHE_REFRESH_SECONDS`	Time period before expiry when cache elements are attempted to be refreshed	Time period in seconds	`180`
`PARAM_THREESCALE_CACHE_ENTRIES_MAX`	Max number of items that can be stored in the cache at any time. Set to `0` to disable caching	Valid number	`1000`
`PARAM_THREESCALE_CACHE_REFRESH_RETRIES`	The number of times unreachable hosts are retried during a cache update loop	Valid number	`1`
`PARAM_THREESCALE_ALLOW_INSECURE_CONN`	Allow to skip certificate verification when calling `3scale` APIs. Enabling this is not recommended.	`true`/`false`	`false`
`PARAM_THREESCALE_CLIENT_TIMEOUT_SECONDS`	Sets the number of seconds to wait before terminating requests to 3scale System and Backend	Time period in seconds	`10`
`PARAM_THREESCALE_GRPC_CONN_MAX_SECONDS`	Sets the maximum amount of seconds (+/-10% jitter) a connection may exist before it is closed	Time period in seconds	60

Next steps

Prepare to deploy applications on Red Hat OpenShift Service Mesh.

2.4. Removing Red Hat OpenShift Service Mesh

This process allows you to remove Red Hat OpenShift Service Mesh from an existing OpenShift Container Platform instance.

2.4.1. Removing the Red Hat OpenShift Service Mesh control plane

You can remove the Service Mesh control plane by using the OpenShift Container Platform web console or the CLI.

2.4.1.1. Removing the control plane with the web console

Follow this procedure to remove the Red Hat OpenShift Service Mesh control plane by using the web console.

Prerequisites

The Red Hat OpenShift Service Mesh control plane must be deployed.

Procedure

Log in to the OpenShift Container Platform web console.
Click the Project menu and choose the istio-system project from the list.
Navigate to Catalogs Installed Operators.
Click on Service Mesh Control Plane under Provided APIs.
Click the ServiceMeshControlPlane menu .
Click Delete Service Mesh Control Plane.
Click Delete on the confirmation dialog window to remove the ServiceMeshControlPlane.

2.4.1.2. Removing the control plane from the CLI

Follow this procedure to remove the Red Hat OpenShift Service Mesh control plane by using the CLI.

Prerequisites

The Red Hat OpenShift Service Mesh control plane must be deployed.
Access to the OpenShift Container Platform Command-line Interface (CLI) also known as oc.

Procedure

When you remove the ServiceMeshControlPlane, Service Mesh tells the Operator to begin uninstalling everything it installed.

Tip

You can use the shortened smcp alias in place of servicemeshcontrolplane.

Log in to the OpenShift Container Platform CLI.
Run this command to retrieve the name of the installed ServiceMeshControlPlane:
```
$ oc get servicemeshcontrolplanes -n istio-system
```
Replace <name_of_custom_resource> with the output from the previous command, and run this command to remove the custom resource:
```
$ oc delete servicemeshcontrolplanes -n istio-system <name_of_custom_resource>
```

2.4.2. Removing the installed Operators

You must remove the Operators to successfully remove Red Hat OpenShift Service Mesh. Once you remove the Red Hat OpenShift Service Mesh Operator, you must remove the Jaeger Operator, Kiali Operator, and the Elasticsearch Operator.

2.4.2.1. Removing the Red Hat OpenShift Service Mesh Operator

Follow this procedure to remove the Red Hat OpenShift Service Mesh Operator.

Prerequisites

Access to the OpenShift Container Platform web console.
The Red Hat OpenShift Service Mesh Operator must be installed.

Procedure

Log in to the OpenShift Container Platform web console.
Navigate to Catalogs Operator Management.
Click the Project menu, and then click openshift-operators.
Click the servicemeshoperator Options menu , and then click Remove Subscription.
Select Also completely remove the Operator from the selected namespace, and then click Remove.

2.4.2.2. Removing the Jaeger Operator

Follow this procedure to remove the Jaeger Operator.

Prerequisites

Access to the OpenShift Container Platform web console.
The Jaeger Operator must be installed.

Procedure

Log in to the OpenShift Container Platform web console.
Navigate to Catalogs Operator Management.
Click the Project menu, and then click openshift-operators.
Click the jaegeroperator Options menu , and then click Remove Subscription.
Select Also completely remove the Operator from the selected namespace, and then click Remove.

2.4.2.3. Removing the Kiali Operator

Follow this procedure to remove the Kiali Operator.

Prerequisites

Access to the OpenShift Container Platform web console.
The Kiali Operator must be installed.

Procedure

Log in to the OpenShift Container Platform web console.
Navigate to Catalogs Operator Management.
Click the Project menu, and then click openshift-operators.
Click the kiali-ossm Options menu , and then click Remove Subscription.
Select Also completely remove the Operator from the selected namespace, and then click Remove.

2.4.2.4. Removing the Elasticsearch Operator

Follow this procedure to remove the Elasticsearch Operator.

Prerequisites

Access to the OpenShift Container Platform web console.
The Elasticsearch Operator must be installed.

Procedure

Log in to the OpenShift Container Platform web console.
Navigate to Catalogs Operator Management.
Click the Project menu, and then click openshift-operators.
Click the elasticsearch-operator Options menu , and then click Remove Subscription.
Select Also completely remove the Operator from the selected namespace, and then click Remove.

2.4.2.5. Clean up Operator resources

Follow this procedure to manually remove resources left behind after removing the Red Hat OpenShift Service Mesh Operator by using the OperatorHub interface.

Prerequisites

An account with cluster administration access.
Access to the OpenShift Container Platform Command-line Interface (CLI) also known as oc.

Procedure

Run the following commands to clean up resources after uninstalling the Operators:

Note

Replace <operator-project> with the name of the project where the Red Hat OpenShift Service Mesh Operator was installed. This is typically openshift-operators.

$ oc delete validatingwebhookconfiguration/<operator-project>.servicemesh-resources.maistra.io
$ oc delete -n <operator-project> daemonset/istio-node
$ oc delete clusterrole/istio-admin clusterrole/istio-cni clusterrolebinding/istio-cni
$ oc get crds -o name | grep '.*\.istio\.io' | xargs -r -n 1 oc delete
$ oc get crds -o name | grep '.*\.maistra\.io' | xargs -r -n 1 oc delete

Chapter 2. Service Mesh Installation

2.1. Preparing to install Red Hat OpenShift Service Mesh

2.1.1. Red Hat OpenShift Service Mesh supported configurations

2.1.1.1. Supported configurations for Kiali on Red Hat OpenShift Service Mesh

2.1.1.2. Supported Mixer adapters

2.1.2. Red Hat OpenShift Service Mesh installation activities

2.2. Installing Red Hat OpenShift Service Mesh

2.2.1. Installing the Operators from OperatorHub

2.2.1.1. Installing the Elasticsearch Operator

2.2.1.2. Installing the Jaeger Operator

2.2.1.3. Installing the Kiali Operator

2.2.1.4. Installing the Red Hat OpenShift Service Mesh Operator

2.2.2. Deploying the Red Hat OpenShift Service Mesh control plane

2.2.2.1. Deploying the control plane with the web console

2.2.2.2. Deploying the control plane from the CLI

2.2.3. Updating your application pods

2.2.4. Configure the Red Hat OpenShift Service Mesh member roll

2.2.4.1. Configure the member roll from the OpenShift Container Platform web console

2.2.4.2. Configure the member roll from the CLI

2.3. Customizing the Red Hat OpenShift Service Mesh installation

2.3.1. Red Hat OpenShift Service Mesh custom resources

2.3.2. ServiceMeshControlPlane parameters

2.3.2.1. Istio global example

2.3.2.2. Istio gateway configuration

2.3.2.3. Istio Mixer configuration

2.3.2.4. Istio Pilot configuration

2.3.3. Configuring Kiali

2.3.3.1. Configuring Kiali for Grafana

2.3.3.2. Configuring Kiali for Jaeger

2.3.4. Configuring Jaeger

2.3.4.1. Configuring Elasticsearch

2.3.5. 3scale configuration

2.4. Removing Red Hat OpenShift Service Mesh

2.4.1. Removing the Red Hat OpenShift Service Mesh control plane

2.4.1.1. Removing the control plane with the web console

2.4.1.2. Removing the control plane from the CLI

2.4.2. Removing the installed Operators

2.4.2.1. Removing the Red Hat OpenShift Service Mesh Operator

2.4.2.2. Removing the Jaeger Operator

2.4.2.3. Removing the Kiali Operator

2.4.2.4. Removing the Elasticsearch Operator

2.4.2.5. Clean up Operator resources

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links

2.3.2. `ServiceMeshControlPlane` parameters