An installation of Maistra Service Mesh differs from upstream Istio community installations in multiple ways. The modifications to Maistra Service Mesh are sometimes necessary to resolve issues, provide additional features, or to handle differences when deploying on OpenShift Container Platform.
The current release of Maistra Service Mesh differs from the current upstream Istio community release in the following ways:
Whereas upstream Istio takes a single tenant approach, Maistra Service Mesh supports multiple independent control planes within the cluster. Maistra Service Mesh uses a multitenant operator to manage the control plane lifecycle.
Maistra Service Mesh installs a multitenant control plane by default. You specify the projects that can access the Maistra, and isolate the Maistra from other control plane instances.
The main difference between a multitenant 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) resource 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 Service Mesh 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. See About OpenShift SDN for additional details.
If the OpenShift Container Platform cluster is configured to use the SDN plug-in:
NetworkPolicy: Maistra Service Mesh 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 Maistra, 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 |
Multitenant: Maistra Service Mesh joins the NetNamespace for each member project to the NetNamespace of the control plane project (the equivalent of running oc adm pod-network join-projects --to control-plane-project member-project). If you remove a member from the Maistra, its NetNamespace is isolated from the control plane (the equivalent of running oc adm pod-network isolate-projects member-project).
Subnet: No additional configuration is performed.
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 project as the control plane.
ServicemeshRbacConfig replaces ClusterRbacConfig for configuration of control-plane-wide role based access control. This must be created in the same project as the control plane.
An installation of Maistra Service Mesh differs from an installation of Istio in multiple ways. The modifications to Maistra Service Mesh are sometimes necessary to resolve issues, provide additional features, or to handle differences when deploying on OpenShift.
The command line tool for Maistra Service Mesh is oc. Maistra Service Mesh does not support istioctl.
Maistra Service Mesh does not support Istio installation profiles.
Maistra Service Mesh does not support canary upgrades of the service mesh.
Maistra Service Mesh does not yet support federated or multiclustered service meshes.
Federated: a set of Service Mesh control planes which interact with each other and are configured independently.
Clustered: a set of Service Mesh control planes which act as a single control plane and are configured as a single entity.
The upstream Istio community installation automatically injects the sidecar into pods within the projects you have labeled.
Maistra Service Mesh does not automatically inject the sidecar to any pods, but requires you to opt in to injection using an annotation without labeling projects. This method requires fewer privileges and does not conflict with other OpenShift capabilities such as builder pods. To enable automatic injection you specify the sidecar.istio.io/inject annotation as described in the Automatic sidecar injection section.
Istio Role Based Access Control (RBAC) provides a mechanism you can use to control access to a service. You can identify subjects by user name or by specifying a set of properties and apply access controls accordingly.
The upstream Istio community installation includes options to perform exact header matches, match wildcards in headers, or check for a header containing a specific prefix or suffix.
Maistra Service Mesh extends the ability to match request headers by using a regular expression. Specify a property key of request.regex.headers with a regular expression.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin-usernamepolicy
spec:
action: ALLOW
rules:
- when:
- key: 'request.regex.headers[username]'
values:
- "allowed.*"
selector:
matchLabels:
app: httpbinMaistra Service Mesh replaces BoringSSL with OpenSSL. OpenSSL is a software library that contains an open source implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. The Maistra Service Mesh Proxy binary dynamically links the OpenSSL libraries (libssl and libcrypto) from the underlying Red Hat Enterprise Linux operating system.
Maistra Service Mesh does not support external workloads (virtual machines).
A maistra-version label has been added to all resources.
All Ingress resources have been converted to OpenShift Route resources.
Grafana, Tracing (Jaeger), and Kiali are enabled by default and exposed through OpenShift routes.
Godebug has been removed from all templates
The istio-multi ServiceAccount and ClusterRoleBinding have been removed, as well as the istio-reader ClusterRole.
Maistra Service Mesh does not support QUIC-based services.
Maistra Service Mesh includes CNI plug-in, which provides you with an alternate way to configure application pod networking. The CNI plug-in replaces the init-container network configuration eliminating the need to grant service accounts and projects access to security context constraints (SCCs) with elevated privileges.
OpenShift routes for Istio Gateways are automatically managed in Maistra Service Mesh. Every time an Istio Gateway is created, updated or deleted inside the service mesh, an OpenShift route is created, updated or deleted.
A Maistra Service Mesh control plane component called Istio OpenShift Routing (IOR) synchronizes the gateway route. For more information, see Automatic route creation.
Catch-all domains ("*") are not supported. If one is found in the Gateway definition, Maistra Service Mesh will create the route, but will rely on OpenShift to create a default hostname. This means that the newly created route will not be a catch all ("*") route, instead it will have a hostname in the form <route-name>[-<project>].<suffix>. Refer to the OpenShift documentation for more information about how default hostnames work and how a cluster administrator can customize it.
Subdomains (e.g.: "*.domain.com") are supported. However this ability doesn’t come enabled by default in OpenShift. This means that Maistra Service Mesh will create the route with the subdomain, but it will only be in effect if OpenShift is configured to enable it.
Transport Layer Security (TLS) is supported. This means that, if the Gateway contains a tls section, the OpenShift Route will be configured to support TLS.
Maistra Service Mesh 2.0 introduces WebAssembly extensions to Envoy Proxy as a Technology Preview. Note that WASM extensions are not included in the proxy binary and that WASM filters from the upstream Istio community are not supported in Maistra Service Mesh 2.0.
Installing Kiali via the Service Mesh on OpenShift Container Platform differs from community Kiali installations in multiple ways. These modifications are sometimes necessary to resolve issues, provide additional features, or to handle differences when deploying on OpenShift Container Platform.
Kiali has been enabled by default.
Ingress has been enabled by default.
Updates have been made to the Kiali ConfigMap.
Updates have been made to the ClusterRole settings for Kiali.
Users should not manually edit the ConfigMap or the Kiali custom resource files as those changes might be overwritten by the Maistra or Kiali operators. All configuration for Kiali running on Maistra Service Mesh is done in the ServiceMeshControlPlane custom resource file and there are limited configuration options. Updating the operator files should be restricted to those users with cluster-admin privileges.
Installing Jaeger with the Service Mesh on OpenShift Container Platform differs from community Jaeger installations in multiple ways. These modifications are sometimes necessary to resolve issues, provide additional features, or to handle differences when deploying on OpenShift Container Platform.
Jaeger has been enabled by default for Maistra.
Ingress has been enabled by default for Maistra.
The name for the Zipkin port name has changed to jaeger-collector-zipkin (from http)
Jaeger uses Elasticsearch for storage by default.
The community version of Istio provides a generic "tracing" route. Maistra Service Mesh uses a "jaeger" route that is installed by the Jaeger operator and is already protected by OAuth.
Maistra Service Mesh uses a sidecar for the Envoy proxy, and Jaeger also uses a sidecar, for the Jaeger agent. These two sidecars are configured separately and should not be confused with each other. The proxy sidecar creates spans related to the pod’s ingress and egress traffic. The agent sidecar receives the spans emitted by the application and sends them to the Jaeger Collector.