The Istio resource manages your Istio control planes. It is a cluster-wide resource, because the Istio control plane operates in and requires access to the entire cluster.

To select a namespace to run the control plane pods in, you can use the spec.namespace field.

You can access all Istio custom resource definition (CRD) options through spec.values fields similar to the following example:

apiVersion: sailoperator.io/v1
kind: Istio
metadata:
  name: default
spec:
  version: v1.22.3
  namespace: istio-system
  updateStrategy:
    type: InPlace
  values:
    pilot:
      resources:
        requests:
          cpu: 100m
          memory: 1024Mi

You can run the following command to see all the customization options:

$ oc explain istios.spec.values

To perform canary updates of the control plane, OpenShift Service Mesh supports many Istio versions. You can set the version field to the new version by either using the full version or the v<x>.<y>-latest alias to automatically select the latest version for a specific minor version. For example, setting v1.23-latest ensures that the Operator maintains the latest version of Istio 1.23.

OpenShift Service Mesh supports two different update strategies for your control planes:

After creating an Istio resource, OpenShift Service Mesh generates a revision name for the resource based on the updateStrategy, and creates a corresponding IstioRevision.

The IstioRevision is a cluster-wide resource and the lowest-level API OpenShift Service Mesh provides. It is usually not created by the user, but by the Operator itself. Its schema closely resembles that of the Istio resource. Instead of representing the state of a control plane you want to be present in your cluster, it represents a revision of that control plane.

A revision of the control plane you want to be present in your cluster is an instance of Istio with a specific version and revision name, and you can use its revision name to add workloads or entire namespaces to the mesh. For example: by using the istio.io/rev=<REVISION_NAME> label.

You can think of the relationship between the Istio and IstioRevision resources as similar to the relationship between Kubernetes' replica set and pod. Users can create a replica set, and results in the automatic creation of pods, which will trigger the instantiation of your containers.

Similarly, users create an Istio resource that instructs the OpenShift Service Mesh Operator to create a matching IstioRevision resource, which then in turn triggers the creation of the Istio control plane. To do that, the OpenShift Service Mesh Operator will copy all of your relevant configuration from the Istio resource to the IstioRevision resource.

The IstioRevisionTag resource represents a stable revision tag that functions as an alias for Istio control plane revisions. With the stable tag, prod, you can use the label istio.io/rev=prod to inject proxies into your workloads. When you perform an upgrade to a control plane with a new revision name, you can update your tag to point to the new revision instead of having to relabel your workloads and namespaces. For more information, see "Stable revision labels".

You can use the IstioRevisionTag resource with the OpenShift Service Mesh Operator. Therefore you can reference both an IstioRevision and an Istio resource. When using an Istio resource, after you update your control plane, the underlying IstioRevision resource changes, and the OpenShift Service Mesh Operator automatically updates your revision tag. You only need to restart your deployments to re-inject the new proxies.

The IstioRevisionTag has one field in its spec: field, targetRef, which can reference an Istio or IstioRevision resource. After deploying the IstioRevisionTag, you can use both the istio.io/rev=default and istio-injection=enabled labels to inject proxies into your workloads.

apiVersion: sailoperator.io/v1
kind: IstioRevisionTag
metadata:
  name: default
spec:
  targetRef:
    kind: Istio
    name: prod

The OpenShift Service Mesh Operator manages the lifecycle of Istio’s Container Network Interface (CNI) plugin separately. To install Istio’s CNI plugin, you create an IstioCNI resource.

The IstioCNI resource is a cluster-wide resource as it installs a daemon set that operates on all nodes of your cluster. You can select a version by setting the spec.version field, as you can see in the example that follows. To update the CNI plugin, change the version field to the version you want to install. Similar to the Istio resource, it also has a values field that exposes all of the options provided in the istio-cni chart:

apiVersion: sailoperator.io/v1
kind: IstioCNI
metadata:
  name: default
spec:
  version: v1.22.3
  namespace: istio-cni
  values:
    cni:
      cniConfDir: /etc/cni/net.d
      excludeNamespaces:
      - kube-system

In addition, Kiali depends on external services and components provided by the container application platform and Istio.

OpenShift Service Mesh integrates the Kiali console and provides the following capabilities:

The OpenShift Service Mesh Console (OSSMC) plugin is an OpenShift Container Platform plugin for Red Hat OpenShift Service Mesh. It integrates much of the Kiali Operator provided by Red Hat interface into the OpenShift Console, injecting both a Service Mesh main menu option with dedicated screens, and integrating Service Mesh tabs throughout console.

Kiali Operator provided by Red Hat installs the OSSMC plugin, that requires the Kiali Server component. OSSMC plugin has its own Custom Resource (CR) configuration.