Introducing OpenShift Service Mesh 2.5

We are pleased to announce the release of Red Hat OpenShift Service Mesh 2.5. OpenShift Service Mesh is based on the Istio and Kiali projects, and is included as part of all subscription levels of Red Hat OpenShift. OpenShift Service Mesh 2.5 updates the underlying version of Istio to 1.18 and Kiali to 1.73.

This release includes updates from Istio 1.17 and 1.18 including subsequent patch releases up to Istio 1.18.7. Most notably, this includes support for Certificate Revocation Lists for external traffic, “developer preview” support for dual-stack IPv4/IPv6, and updates to Gateway API. This release also includes the general availability of the OpenShift Service Mesh Console plugin, which is now installed with the Kiali operator as well as updates to support the next generation of OpenShift Distributed Tracing based on Tempo.

Service Mesh on Arm is generally available

This release makes support for OpenShift Service Mesh on OpenShift clusters based on Arm^TM architecture generally available. This includes Kiali and distributed tracing with Jaeger. Red Hat OpenShift aims to give our customers the choice to run applications on the most appropriate infrastructure, so we are pleased to extend support for OpenShift Service Mesh to Arm. 

Certificate revocation lists for external traffic

OpenShift Service Mesh supports mutual TLS (mTLS) authentication for services communicating outside of the mesh. Depending on the use case, this can be setup by configuring credentials with an Ingress Gateway for services exposed to external traffic, a ServiceEntry for individual services to originate mTLS or an Egress Gateway for a gateway to originate mTLS. This release introduces the ability to revoke credentials using Certificate Revocation Lists (CRLs) for the above use cases and Online Certificate Status Protocol (OCSP) stapling for an Ingress Gateway. See the Ingress Gateway, Egress TLS Origination and Egress Gateway documentation for more details.

OpenShift Service Mesh Console plugin is generally available

OpenShift Service Mesh 2.3 introduced the OpenShift Service Mesh Console to bring Kiali’s topology view and other service mesh information into the OpenShift console. This adds a “Service Mesh” menu and introduces metrics and topology information into the workload and service menus. This provides a unified experience for managing services in Red Hat OpenShift with the benefit of information obtained from service mesh. 

OpenShift Service Mesh Console - Graph View

When the OpenShift Service Mesh Console was introduced, it was installed with a separate operator. Now that it is generally available, it has been integrated into the Kiali operator, and can be installed using the OSSMConsole custom resource definition (CRD).

Note that this plugin only supports pulling information from a single Kiali instance at this time. If multiple Kiali instances are present within a cluster (for example, to support multiple service mesh instances), the serviceNamespace configuration value can be used to specify which service mesh the console plugin will use.

Distributed tracing updates

The ability to automatically enable mesh-wide distributed tracing is a core feature of OpenShift Service Mesh. Tracing provides the ability to observe requests as they flow through a system of multiple services. This is critical for identifying bottlenecks, understanding system behavior and providing a more consistent experience to application consumers.

To date, tracing has been provided by the Jaeger and Elasticsearch components. While these have been incredibly reliable, we have heard from customers that they desire greater flexibility as well as support for greater scale, performance and more cost-effective solutions.

With this in mind, Red Hat OpenShift distributed tracing 3.0 was recently made generally available. This major update introduces a new architecture and new components for distributed tracing that OpenShift Service Mesh users should plan to migrate to.

OpenTelemetry and Tempo components

Two components make up the new distributed tracing architecture:

• Red Hat build of OpenTelemetry - a vendor-agnostic way of retrieving, processing and exporting telemetry data (not limited to tracing).
• Red Hat OpenShift distributed tracing platform (Tempo) - a component based on the Grafana Tempo project for ingesting tracing data via common protocols including Jaeger, Zipkin, and OpenTelemetry. For data persistence, Tempo can be configured to use a variety of object storage providers.

New observability extension providers

To enable integration with the above components and to provide additional integrations with OpenShift Service Mesh, we have added support for the “zipkin”, “opentelemetry” and “envoyOtelAls” Istio extension providers. These can now be configured using the “meshConfig.extensionProviders” setting in the “ServiceMeshControlPlane” CRD.

Kiali and Tempo

Kiali in OpenShift Service Mesh 2.5 includes support for integrating with Tempo by using the Jaeger API. This is configured in Tempo using the “jaegerQuery” setting in the TempoStack CRD and from Kiali using the “in_cluster_url” setting in the Kiali CRD. For more details, see the OpenShift Service Mesh 2.5 release notes.

Elasticsearch and Jaeger deprecation

With the introduction of the OpenTelemetry and Tempo based distributed tracing architecture, the Jaeger based distributed tracing platform operator and Elasticsearch operator have been deprecated and will be removed in a future release. While they will continue to be supported as part of their release lifecycles and as integrations with OpenShift Service Mesh, they will no longer receive further enhancements.

Configuring distributed tracing and service mesh

While by default OpenShift Service Mesh configures distributed tracing through the ServiceMeshControlPlane CRD, for production, we recommend that customers configure tracing using a separate Jaeger custom resource or the new Tempo operator. In addition to providing greater flexibility of configuration, this will better prepare users to migrate to both OpenShift Distributed Tracing 3 and OpenShift Service Mesh 3.

Where to start with Service Mesh and Tempo?

See the OpenShift Service Mesh 2.5 release notes and the “Metrics, logs, and tracing” section of the documentation for more information on using Tempo and the OpenTelemetry collector with Service Mesh.  

Automatic route creation

As communicated in our previous release, the automatic route creation feature (which uses a component called Istio OpenShift Routing - or IOR) has been deprecated and will be removed from OpenShift Service Mesh 3. Though this is a convenience feature for configuring gateways with service mesh, it has been our experience that explicitly creating and managing OpenShift routes provides a more transparent and robust production configuration - particularly across upgrades.

This release makes this feature disabled by default. This will not impact existing OpenShift Service Mesh users who were using the feature, as it will continue to be enabled post upgrade.

Users are encouraged to disable this feature and to manage OpenShift route resources for their Gateways independent of Service Mesh, as in addition to providing greater flexibility and control, it will simplify the future migration to OpenShift Service Mesh 3. This change is best made in conjunction with moving to gateway injection for managing all Istio gateways with applications rather than the ServiceMeshControlPlane, which manages gateways with the control plane. Gateway injection along with Gateway API will be the recommended ways to create and manage Gateways in OpenShift Service Mesh 3 and beyond.

Kiali updates

Kiali in dark mode theme

OpenShift Service Mesh 2.5 brings additional updates with Kiali 1.73, including:

• Use of Istio’s Discovery Selectors - Kiali will now take into account Istio’s discovery selectors when deciding which namespaces to display for the user. For more information, see Kiali’s namespace management documentation.
• Dark mode theme - Kiali now supports a dark mode theme similar to OpenShift Console’s dark mode, which also applies to the OpenShift Service Mesh Console plugin.
• Clusterwide mode - For more efficient caching, the Kiali CRD includes a new setting “deployment.cluster_wide_access”, which when set to “true” will give cluster permissions to the Kiali server. When set to false, the operator creates a role for each namespace that is part of the mesh.
• Kubernetes Gateway API management - Kiali now also includes the ability to manage multiple Gateway API implementations in parallel. This is done through the new “gateway_api_classes” in the Kiali custom resource definition (CRD). Users can then select the “Gateway Class” of their choosing when using the Kubernetes Gateway creation wizard.

For a full list of Kiali updates, see the project release notes.

Gateway API updates

OpenShift Service Mesh includes technology preview support for Kubernetes Gateway API resources with Istio. This release updates support for Kubernetes Gateway API, adding support for extra v1beta1 resources and updating the Gateway API version to 0.6.2. The release also includes updates to how Gateways (Kubernetes Gateways, not Istio Gateways) are automatically deployed. See more details on these changes here.

With Gateway API achieving general availability upstream and part of Istio 1.20 and beyond, we plan to make this feature generally available in the next minor release of OpenShift Service Mesh.

IPv4 / IPv6 dual stack is developer preview

This release introduces IPv4/IPv6 dual stack support as a developer preview feature, meaning that it is ready for development and experimentation. This was introduced as an experimental feature in Istio 1.17, with several updates since then to address bugs and remaining dual-stack gaps. The feature continues to evolve upstream as it progresses toward Alpha and beyond. As with all developer preview features, feedback is welcome so that we can help to incubate this feature toward general availability.  

Kiali Backstage plugin is developer preview

A service mesh does not stand on its own, but acts as a key infrastructure layer within a larger platform that will be made up of many different technologies. In addition to all of its security features and integrations, a service mesh is often an integral part of continuous integration/delivery (CI/CD) infrastructure and thus may drive one or more steps in the application delivery process.

The majority of our users are teams responsible for such platforms and processes. Their goals include making development teams happy and productive so that they can best support the business. It is with this group in mind that Red Hat has developed Red Hat Developer Hub, an enterprise grade offering based on the Backstage.io project. The Backstage project, contributed by Spotify, is an open source framework for building developer portals. Red Hat developed Project Janus, a community for building developer portals, built on Backstage.

To assist in building developer platforms with service mesh and Backstage, the team has recently contributed the Kiali plugin for Backstage. You can read more about using Kiali with the Red Hat developer hub in this blog. A demo of the plugin was provided at a Janus community meeting late last year.

Istio ambient mesh update

The Istio project introduced Istio ambient mesh as a sidecar-less Istio data plane implementation. While this is still under heavy development in the Istio community, it has the potential to significantly reduce the resource utilization required to operate a service mesh by shrinking the footprint of Istio by removing sidecars.

Though OpenShift Service Mesh 2.5 does not include support for Istio ambient mesh, the Istio community continues to evolve the design and implementation. Recently, the team at Solo.io contributed a notable architecture change regarding how traffic is redirected between workload pods and the ztunnel node proxy component. This enables ambient mesh to be compatible with the majority of Kubernetes Container Network Interface (CNI) plugins, including both OpenShift’s OVN-Kubernetes and SDN network plugins.

This change along with other Red Hat contributions has enabled our team to successfully validate Istio ambient mesh on OpenShift, confirming that initial support for Istio ambient mesh is planned for a future release of OpenShift Service Mesh. We have also contributed a new “openshift-ambient” profile, which will make testing ambient mesh on OpenShift easier beginning with Istio 1.22. In parallel, the Kiali team continues to add features in support of ambient mesh. Stay tuned for more on this topic, as we prepare to offer Istio ambient mesh as a developer preview feature with the Sail Operator and later in OpenShift Service Mesh 3!

OpenShift Service Mesh 3 update

In case you missed it, late last year we published a blog post update regarding the “Sail Operator”, which is a developer preview of OpenShift Service Mesh 3. This provides further updates on our progress on the next major release of OpenShift Service Mesh. We continue to develop this operator - including operator support for canary-style control plane upgrades. We will provide further updates in the coming months as we work toward a Technology Preview release of OpenShift Service Mesh 3. Watch the redhat.com blog for further updates.

Learn more about OpenShift Service Mesh