Red Hat OpenShift Service Mesh 3: Now technology preview

Last year, a new operator for Istio on Red Hat OpenShift was announced as a developer preview for the third major release of OpenShift Service Mesh. We provided an additional update near the end of that year. Since then, we have been working hard to make this next generation of OpenShift Service Mesh a reality, while continuing to support our growing customer base on OpenShift Service Mesh 2. Now we are pleased to announce that OpenShift Service Mesh 3 is available on Red Hat OpenShift as a technology preview.

This article will provide an update on OpenShift Service Mesh 3 and how to get started with it. I also answer the most frequently asked questions I've received about it so far.

A new beginning for service mesh on OpenShift

Red Hat OpenShift includes OpenShift Service Mesh. This supports zero-trust networking at scale, and removes the need for common code across a large number of services to improve developer productivity.

OpenShift Service Mesh 3 represents a new beginning for service mesh on OpenShift. This means supporting OpenShift customers on the latest stable Istio features, while increasing our commitment and contributions to the Istio community.

A new operator for Istio

As part of OpenShift Service Mesh 3, we are developing a new operator for Istio, which is located upstream in the istio-ecosystem organization as the sail-operator project. This operator differs from the current OpenShift Service Mesh operator in a few significant ways:

1. Flexibility: The operator is responsible for managing Istio components, and does not manage observability components such as Prometheus or Kiali. Following the single responsibility principle, Kiali, metrics and tracing components are managed by independent operators. This may seem like a loss of convenience, but it actually gives you the flexibility to configure these components for unique environments, or to use third-party tools or services, with OpenShift Service Mesh
2. Simplicity: Designed with simplicity in mind, the operator uses community Helm configuration rather than mapping Istio configuration into a large custom resource object (the ServiceMeshControlPlane, often called SMCP, in OpenShift Service Mesh 2). This is replaced with the simplified Istio resource
3. Cluster-wide: Defaulting to a cluster-wide installation, the operator creates only cluster-scoped installations of Istio managed by cluster-level resources. This aligns with the community version Istio. Multi-tenant use cases continue to be addressed, but with a variety of mesh scoping features Istio's multiple control plane feature (more on this below)
4. Community: The operator uses a Red Hat distribution of the community Istio project, rather than the midstream Maistra.io project used with OpenShift Service Mesh 2. The Maistra.io downstream project, which maintained additional features for OpenShift, will no longer be maintained after OpenShift Service Mesh 2.6 reaches end of life. While many of Maistra.io’s OpenShift-specific features have been contributed to community Istio, the remainder of this blog will discuss the feature impacts of this change

While these changes significantly simplify the operator for OpenShift Service Mesh 3, the new operator adds support for the incremental update of workloads using Istio’s revision feature. 

Canary style control plane updates

We have many customers that run service mesh at a large scale, with hundreds of namespaces and thousands of workloads. When making a change, such as an upgrade or major configuration changes, it's safer to make those changes incrementally so they can be validated at a small scale before being applied across the entire mesh. For application workloads, this is commonly done using canary or blue-green deployment strategies. Istio supports similar strategies for upgrading a service mesh, using revisions.

OpenShift Service Mesh 2 only supports in-place upgrades of Istio, meaning that the control plane is upgraded to a new version, and then all workload proxies must be updated with a pod restart. While this is a simple procedure, it's all or nothing. Once the control plane is updated, all workloads must be moved to the new version of the control plane. If a rollback is necessary, all workloads must move back to the old version.

With a canary-style control plane upgrade, the new instance of the service mesh control plane (istiod) is deployed alongside the old version, allowing you to incrementally move workloads to the new version of Istio using workload or namespace labels. This provides peace of mind and extra assurance that the updated control plane and data plane are performing as expected before commencing a full scale upgrade.

Multi-tenancy: A set of use cases, not a feature

One of the defining features of the Maistra.io project was that it defaulted to deploying the Istio control plane as a namespace-scoped resource. This made it straightforward to manage multiple service mesh instances within the same cluster, and optimized resources for this use case. This has been an important feature, but it was also a notable divergence from community Istio, where the Istio control plane is always deployed as a cluster-scoped resource with the assumption that there is one mesh for each cluster. In practice, the Maistra.io approach turned out to be sub-optimal for the majority of our customers who, like upstream, ran a single service mesh instance for each cluster, because it increased the load on the Kubernetes API server when there were a large number of namespaces to reconcile. For that reason, OpenShift Service Mesh 3 and beyond aligns with community Istio, and requires all instances of the Istio control plane to be cluster-scoped.

This doesn't mean we are abandoning multi-tenant or multi-control plane use cases. Istio provides a variety of features for creating multiple control planes within a single cluster, and for segregating a cluster into different tenants. We plan to provide different recommendations depending on the specific needs that motivate a multi-tenant topology.

We have also seen that for many customers, the additional overhead of multiple control planes is not needed for their multi-tenant setup. This is particularly true where a single infrastructure team manages a service mesh control plane for multiple application teams. In these cases, the infrastructure team manages the control plane, and individual application teams are given a scoped down portion of a mesh. Istio features such as sidecar resources and exportTo annotations are used to reduce the scope of the mesh and its resources, while AuthorizationPolicies can limit access. While these features are mature and can be used today, we are also exploring ways of making this configuration easier.

For customers requiring multiple control planes for each cluster (such as cases where each mesh is managed by a separate infrastructure team, or where the scope of the cluster exceeds what can reasonably be part of a single mesh), we plan to provide support for Istio’s multiple control plane topologies. This set of features uses the same Istio revisions feature used for canary control plane upgrades to manage multiple control planes in parallel on an ongoing basis.

Multi-cluster service mesh approaches

While OpenShift Service Mesh 2 provided support for mesh federation, support for Istio’s multi-cluster topologies has been a gap in our offering to date. Federation supports multi-cluster use cases where each cluster retains its own independent Istio control plane, effectively bridging individual service meshes. Istio’s multi-cluster topologies stretches a single service mesh across multiple clusters using either a remote control plane or a multi-primary topology. This is particularly useful for supporting multi-cluster high-availability or failover use cases with locality-based load balancing or to support complex cluster migrations while maintaining application traffic across both clusters.

We recently published a blog post discussing different topologies and how to implement a multi-primary topology using OpenShift Service Mesh 2.6 as a developer preview feature. In OpenShift Service Mesh 3 and beyond, we plan to provide general available support for not only the multi-primary topology, but also primary-remote and external control planes. For more information, read the documentation about configuring multi-cluster topologies with OpenShift Service Mesh 3's sail-operator.

Service mesh federation

While Istio’s multi-cluster topologies enable a single service mesh to be stretched across multiple tightly coupled clusters, this is not always desirable or feasible when scaling service mesh across a large organization. Large organizations are often made up of different groups maintaining independent sets of applications. In such cases, it's often desirable to limit information sharing to a need-to-know basis between groups of applications. This both reduces the blast radius should a set of applications become compromised, and improves scalability by reducing the number of applications under the management of any one team.

In such cases, it is desirable to maintain independent service meshes (independent control planes and data planes) and “federate” meshes to facilitate service-to-service interactions when needed. For this reason, we implemented federation in OpenShift Service Mesh 2.1.

As OpenShift Service Mesh’s support for federation was a feature of the Maistra.io project, we're developing a new implementation of federation as an independent controller that helps to manage the federation between Istio service meshes. This work is ongoing, and may not be generally available in time for the 3.0 release of OpenShift Service Mesh. We will provide more information on this feature as its development progresses.

Istioctl: Istio command-line utility

While OpenShift Service Mesh is installed and managed with an operator, the istioctl command-line utility provides a wide range of administrative, diagnostic and debugging commands that can be used with Istio. To improve the user experience for OpenShift Service Mesh, we're including support for the Istio command-line utility with OpenShift Service Mesh 3 for select commands. Installation and upgrades continue to be supported with the OpenShift Service Mesh operator. 

Getting started with OpenShift Service Mesh 3

OpenShift Service Mesh 3 is now available from OpenShift’s operator hub. To get started, follow the instructions in the Service Mesh 3 technology preview documentation for installing the operator and setting up an Istio custom resource definition. For details on how to customize the installation, see the community operator and API reference documentation. We have also provided documentation to get started with Istio's example application.

Keeping the scope of support for technology preview features in mind, questions and feedback can be provided through Red Hat’s support portal. We also welcome collaboration around the new operator and configuration in the sail-operator’s community repository and Slack channel #sail-operator in the Istio organization.

Try the Technology Preview edition of OpenShift Service Mesh 3 today!

Continue reading Red Hat OpenShift Service Mesh 3: Frequently Asked Questions