kind: ServiceMeshControlPlane
...
spec:
istio:
sidecarInjectorWebhook:
injectPodRedirectAnnot: true
...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 maistra.io/member-of 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.
|
Note
|
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.
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
sidecar.istio.io/inject annotation and the project being listed in the
ServiceMeshMemberRoll. For more information please refer to the
the automatic injection section.
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 k8s.v1.cni.cncf.io/networks annotation, which
is added to a pod during injection.
By default, if a pod contains an existing k8s.v1.cni.cncf.io/networks 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
...
spec:
istio:
sidecarInjectorWebhook:
injectPodRedirectAnnot: true
...Maistra does not package any version of the istioctl utility. Some of this functionality is available in Kiali.
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
Maistra does not yet support external workloads (virtual machines).
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.
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.
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.