Introducing OpenShift Service Mesh 2.2

We are pleased to announce the release of OpenShift Service Mesh 2.2. OpenShift Service Mesh is included and installed via an operator as part of the OpenShift Open Hybrid Cloud Platform and is based on the Istio project, with Kiali as the management console for Service Mesh. Service Mesh 2.2 updates the underlying version of Istio to 1.12 and Kiali to 1.48. This brings in several new features from Istio and Kiali, including improved performance, stability, and maturity of Istio 1.12.

Red Hat OpenShift on AWS (ROSA)

The release of Service Mesh 2.2 coincides with support for service mesh on Red Hat OpenShift on AWS (ROSA), including multi-cluster federation. For more information, see our supported configurations documentation. 

Istio Updates

Users moving from OpenShift Service Mesh 2.1 to 2.2 will be upgrading from Istio 1.9 to 1.12, bringing in a wide range of new features and updates from Istio 1.10, 1.11, and 1.12. Some of the more notable new features include:

WasmPlugin API

Istio 1.12 brings in the new WebAssembly API, WasmPlugin. As this was contributed to the upstream by the Red Hat team, it shares a lot in common with the ServiceMeshExtensions API that we currently support, thus migrating will be very straightforward. With the introduction of WasmPlugin, the ServiceMeshExtensions API will be deprecated.

Failover Priority 

With the introduction of federation in Service Mesh 2.1, users have begun to federate service meshes for the purpose of high-availability failover use cases with Destination Rules and locality load balancing. Istio 1.12 introduces a failoverPriority field to Locality Load Balancing configuration of Destination Rule to allow users to set an ordered list of labels to sort endpoints for priority based load balancing.

In addition to the above, the following features are available for technology preview in Service Mesh 2.2. Tech Preview features are for customer evaluation purposes only and may require a configuration flag to be enabled for use. Support from Red Hat is on a best effort basis.

AuthorizationPolicy “Dry Run”

A service mesh provides a critical infrastructure layer for enforcing zero-trust network policies, but creating those policies so that they provide fine-grained, "need to know" access can be a challenge. This is particularly true on a live production mesh, where users will not want to interfere with running production traffic. To help with these scenarios, Istio has added an experimental feature to AuthorizationPolicy called Dry Run. This allows users to specify a flag on AuthorizationPolicy resources to indicate that the policy is for "dry run" purposes. This means it will not interfere with network traffic but will generate metrics and traces with “dry_run” tags that will allow traffic to be observed as if the policy had been active. This way, one can validate that the AuthorizationPolicy would have the expected impact without interfering with traffic.  

Istio Telemetry API 

This API was introduced in Istio 1.11 to bring a standardized API for configuring tracing, logging, and metrics in Istio. This allows users to tightly scope and customize tracing, logging, and metric configuration as required by their specific workloads. See the documentation for full details.

Kubernetes Gateway API 

Istio 1.12 includes the v1alpha2 release of the Kubernetes Gateway API. Red Hat is an active contributor in the Gateway API Kubernetes SIG, which aims to unify the set of APIs used by Istio, Kubernetes Ingress, and other proxy technologies to define a single set of powerful, extensible APIs for routing traffic. While we do not recommend using Gateway APIs for production workloads just yet, as they are highly likely to change, this gives the opportunity for those looking to try the next generation of Kubernetes/Istio Ingress to take their first steps. Note that the Gateway API is disabled by default and must be enabled through the ServiceMeshControlPlane configuration (see the release notes for details).

gRPC Proxyless Service Mesh 

Istio 1.11 added experimental support for adding gRPC services directly to the mesh (i.e., without an Envoy sidecar). This is made possible by the fact that the gRPC project has added support for a subset of Envoy’s xDS APIs. The current implementation of the xDS APIs within gRPC is limited in some areas compared to Envoy. For more information on the available features, see this blog post.

Kiali Updates

Users moving from OpenShift Service Mesh 2.1 to 2.2 will be upgrading from Kiali 1.36 to 1.48, bringing in a wide range of new features and updates. For a full list of new features and updates, review the Kiali release blog posts and release notes. Some of the more notable new features include:

Improved Scalability

A frequent challenge customers have encountered with Kiali is navigating large service meshes. We’ve witnessed at multiple customer sites how Kiali became difficult to navigate when there is a large number of services and edges. The Kiali community continues to introduce new enhancements to improve this. This release brings the first series of these enhancements.

The graph is now “zoom-aware,” such that the level of detail will automatically adjust when there is a large amount of information on the graph. In previous releases, this view would display a lot more information about each service - though this would not have been readable at this zoomed level of detail, and it would negatively impact Kiali’s performance. 

Kiali has also introduced several new graph layouts, such as Grid, Concentric, BreadthFirst, and namespace-oriented views, which provide different ways of visualizing larger meshes. This allows users to choose the layout that best fits their mesh - with the desired level of detail.

There have also been several backend enhancements to optimize the fetching of health statuses.

For a much more thorough overview of the scalability improvements in Kiali and how to utilize the above views, see the demo for the 1.45 release and 1.48 release.

Graph: Find/Hide by Labels

While the above layout is particularly helpful when services are nicely grouped around namespaces, there will be times when users want to find or hide a portion of the mesh based on a different criteria. For these cases, Kiali has the ability to find or hide portions of the graph based on custom labeling.

Preview Istio Resource Creation

One of Kiali’s core features is its ability to modify the Istio configuration using easy-to-use Wizards that abstract much of the lower level Istio configuration. We’ve seen that users have different levels of comfort for doing this. Some want Kiali to be read-only, which is why we include a viewOnly configuration option. Still, others just want to have more confidence and comfort when making configuration changes. 

For those cases, Kiali has introduced Istio config Previews. This allows the Kiali users to modify the YAML files manually before applying or even copy/download those files. The feature has been added to the Overview page, Service Wizards, and in the Istio Config creation.

Certificate Information

Kiali now displays the information about certificates used for internal service communication (Mutual TLS), which is useful for easily checking a certificate’s details and validity. This feature is configurable in the Kiali custom resource and is enabled by default for the secrets named cacerts and istio-ca-secret.

Log Levels of Proxies

When troubleshooting service mesh problems, the Envoy proxy logs and configuration is one of the first places to look. Kiali provides access to both of these for all workloads. Now Kiali also allows users to increase/decrease the verbosity of the logs per Workload, without restarting the Pod. This will be particularly useful when debugging live or sporadic issues.

Upgrading to Service Mesh 2.2

Upgrading OpenShift Service Mesh is handled via the OpenShift Service Mesh operator. If you're using the default "Automatic" approval strategy for updates, the Service Mesh operator will automatically be updated to the latest 2.2.x version. This version of the operator does not automatically upgrade your Service Mesh control plane. It will support all currently supported versions of OpenShift Service Mesh. To upgrade your control plane, follow the directions in the service mesh upgrades documentation.

Support Notes

At the time of release, OpenShift Service Mesh 2.2 will be supported on the OpenShift Container Platform 4.9 and 4.10. For support information related to earlier versions of Service Mesh and OCP, see the Service Mesh section of the OpenShift Lifecycle Policy page.

With the release of OpenShift Service Mesh 2.2, OpenShift Service Mesh 1.1 goes out of support. Customers who are still running the 1.1 control plane should upgrade immediately, as we will no longer be issuing security or bug fixes for 1.1. 

OpenShift Service Mesh 2.0 and 2.1 will continue to be supported, though they are now in maintenance mode. 

Going Forward

Going forward, OpenShift Service Mesh aims to continue aligning with and supporting the Istio ecosystem. We are thrilled that Istio has begun the process of joining the CNCF and look forward to increasing our collaboration with the community. While we maintain several differences from upstream Istio to support OpenShift customer use cases, our aim is to reduce this delta over time while offering an integrated experience with the OpenShift platform. 

We are also extremely proud of Kiali, which has become the defacto standard open source management console for Istio. OpenShift users should be on the lookout for even greater integration between Kiali and the OpenShift management experience.