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 ingress from non-member projects is required, 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 will
inject all deployments within specifically labeled namespaces 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 CNI plugin replaces proxy-init on OpenShift 4 clusters. Using CNI eliminates
the need for the NET_ADMIN privilege on application containers.
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
Upstream Istio has two cluster scoped resources that it relies on. The MeshPolicy and the ClusterRbacConfig. These are not compatible with a multitenant cluster and have been replaced as described below.
ServiceMeshPolicy replaces MeshPolicy for configuration of control-plane-wide authentication policies. This must be created in the same namespace as the control plane.
ServicemeshRbacConfig replaces ClusterRbacConfig for configuration of control-plane-wide role based access control. This must be created in the same namespace as the control plane.
For more information on how to use them, see these examples:
ServiceMeshPolicy: Enabling Mesh-wide Strict mTLS
ServiceMeshRbacConfig: Enabling Mesh-wide RBAC Policy Enforcement.
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 via OpenShift routes.