Comparison with Istio

Comparing Maistra and Istio installations

An installation of Maistra differs from an installation of Istio in multiple ways. The modifications to Maistra are sometimes necessary to resolve issues, provide additional features, or to handle differences when deploying on OpenShift or OKD.


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.

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

Maistra configures each member project to ensure network access between itself, the control plane, and other member projects. The exact configuration differs depending on how OpenShift software-defined networking (SDN) is configured.

  • NetworkPolicy: Maistra creates a NetworkPolicy resource in each member project allowing ingress to all pods from the other members and the control plane. If you remove a member from mesh, this NetworkPolicy resource is deleted from the project.

This also restricts ingress to only member projects. If you require ingress from non-member projects, you need to create a NetworkPolicy to allow that traffic through.
  • Multitenant: Maistra joins the NetNamespace for each member project to the NetNamespace of the control plane project (for example, invoking oc adm pod-network join-projects --to istio-system myproject). If you remove a member from the mesh, its NetNamespace is isolated from the control plane (for example, invoking oc adm pod-network isolate-projects myproject).

  • Subnet: no additional configuration is performed.

Automatic Injection

Enabling automatic injection for your deployments differs between the upstream Istio releases and the Maistra releases. The upstream sidecar injector injects all deployments within labeled projects whereas the Maistra version relies on presence of the annotation and the project being listed in the ServiceMeshMemberRoll. For more information please refer to the the automatic injection section.

Istio CNI

The Istio CNI plugin replaces proxy-init on OpenShift 4 clusters. Using CNI eliminates the need for the NET_ADMIN privilege on application containers.

The Istio CNI plugin is enabled through Multus CNI. The Istio operator creates a NetworkAttachmentDefinition object in each project that is part of the mesh. This object is referenced in the annotation, which is added to a pod during injection.

Using Istio CNI with other Multus CNI plugins

By default, if a pod contains an existing annotation, such as when using Multus CNI to add a macvlan network to the pod, the value of the annotation is overwritten. To preserve the value and instead append Istio CNI to the end, the field spec.istio.sidecarInjectorWebhook.injectPodRedirectAnnot must be set to true in the ServiceMeshControlPlane object as shown in the following example.

kind: ServiceMeshControlPlane
      injectPodRedirectAnnot: true

In previous Maistra versions, only the text form of the annotation was supported. The JSON form support was introduced in version 1.1.5.


Maistra does not package any version of the istioctl utility. Some of this functionality is available in Kiali.

Istio operator

Maistra uses a multi-tenant operator to manage the control plane lifecycle. Whereas upstream Istio takes a single tenant approach, Maistra supports multiple independent control planes within the cluster. This is discussed in more detail during installation

External Workloads

Maistra does not yet support external workloads (virtual machines).

WebAssembly Extensions

Maistra 2.0 introduces WebAssembly extensions to Envoy proxy as a Technology Preview. Note that the upstream Istio built-in WASM extensions are not supported in Maistra 2.0.

Federation and Multicluster

Maistra does not yet support federated or multicluster service meshes.

  • Federated service meshes are a set of service mesh control planes which interact with each other but are configured independently.

  • Clustered service meshes are a set of service mesh control planes which act as a single control plane and are configured as single entity.

Component modifications

  • Godebug has been removed from all templates

  • A maistra-version label has been added to all resources.

  • The istio-multi ServiceAccount and ClusterRoleBinding have been removed, as well as the istio-reader ClusterRole.

  • All Ingress resources have been converted to OpenShift Route resources.

  • Grafana, Tracing (Jaeger), and Kiali are enabled by default and exposed through OpenShift routes.