Introducing OpenShift Service Mesh 2.3

We are pleased to announce the release of OpenShift Service Mesh 2.3. OpenShift Service Mesh is based on the Istio project, with Kiali as the management console for Service Mesh, and is included and installed via an operator as part of all subscription levels of Red Hat OpenShift. OpenShift Service Mesh 2.3 updates the underlying version of Istio to 1.14 and Kiali to 1.57. This brings in several new features from Istio and Kiali including improved performance, stability and maturity. This release also takes our first steps toward a greater convergence between OpenShift Service Mesh and upstream Istio - with much more to come in future releases.

Istio Updates

Users upgrading from Service Mesh 2.2 will see numerous updates from Istio 1.13 and 1.14. Some of the more notable additions include the addition of a new ProxyConfig API for managing proxy-level configuration, the ability to configure automatic SNI inclusion and many other enhancements and configuration options. For a full list, review the Istio 1.13 and 1.14 change notes.

Gateway Injection is now Generally Available

Istio Ingress and Egress Gateways manage traffic entering and exiting the mesh. To date, OpenShift Service Mesh has created and managed gateways as part of the control plane via the ServiceMeshControlPlane resource. OpenShift Service Mesh 2.3 (and 2.2.4+) bring GA support for the ability to create and manage Gateways via injection into a Deployment instance. This provides additional flexibility in configuring gateways and the ability to individually manage the lifecycle of gateways. This is particularly useful where Gateways are to be managed with applications in the mesh, rather than the control plane. While users may still create and manage Gateways via the ServiceMeshControlPlane, our recommendation is to use Gateway injection for creating gateways in a namespace other than the control plane going forward. This aligns with upstream Istio’s recommendations of creating gateways in a namespace that is separate from the control plane.

Introducing a Cluster Level Topology

Red Hat OpenShift is often deployed in large enterprises that need to support multiple teams or business units, making multi-tenancy a common requirement. Since multi-tenancy was not a feature of Istio when OpenShift Service Mesh was first released, Red Hat includes modifications to Istio to enable a multi-tenant deployment model. This allows users to create multiple Istio service meshes within a single cluster - to be used by different teams with “soft” separation.

While this is ideal for clusters with multiple meshes, we have seen cases where it is suboptimal for a single large mesh within a single cluster. In particular, when it comes to startup and reconciliation performance, managing hundreds of namespaces can put a significant load on the Kubernetes API server. Running the Istio control plane at cluster level avoids this issue.

Thus, we are introducing a cluster-wide topology option in 2.3, which is optimized around a single mesh deployed to a single cluster. This is consistent with upstream Istio’s deployment topology and will provide better performance and resource utilization for large meshes.

While this is a tech preview feature in OpenShift Service Mesh 2.3, with multi-tenant remaining the default installation topology, the cluster-wide topology will become the default topology in a future release of OpenShift Service Mesh. Thus, we encourage customers to experiment with cluster-wide installations and provide feedback to Red Hat.

It’s important to note that we will continue to support our customers with multi-tenant use cases. We have seen that there is no one size fits all when it comes to multi-tenant needs, so you can look for us to provide a variety of features that enable users to manage service meshes across multiple teams or tenants. There has also been significant progress in upstream Istio for better supporting multi-tenancy, which we intend to support, build on and collaborate with the community on.

OpenShift Service Mesh Console

One of the benefits of OpenShift Service Mesh is tight integration with the OpenShift’s user experience. In this release, we are introducing the OpenShift Service Mesh Console operator as a technical preview feature. This operator brings a wide range of service mesh utilities to the OpenShift Console - most notably a new “Service Mesh” tab that provides features normally accessed via Kiali, such as the topology graph.

In addition to the new Service Mesh menu, service mesh information - including application metrics, traces, logs and Envoy details are added to the Deployment and Service consoles. This will make it easier to take advantage of service mesh information when managing workloads and services on OpenShift.

This enhancement can be installed via the new OpenShift Service Mesh Console operator.

Note that we will continue to support the standalone community Kiali console. Red Hat is proud to create and maintain what has become the defacto standard open source dashboard for managing Istio service meshes and we will continue to advance it.

Kiali Updates

This release includes several Kiali updates from releases 1.49-1.57. For a full list of updates, see the Kiali blog posts - 1.49 to 1.52 and 1.53 to 1.57. As always, the Kiali team posts their Sprint demos to the Kiali YouTube channel. Some of the more notable additions in this release are described below.

Control Plane Overview

A common challenge for service mesh users is monitoring and managing resources for the Isto control plane. Many users want to know how to size their control plane, and while we provide helpful defaults to start out - optimizing resource usage is best done by monitoring applications in production or with a production-like load. To help with this, Kiali now includes a monitoring overview of the control plane, highlighting key health metrics such as memory, CPU and proxy push time.

Improved Validations

Kiali can be used to validate Istio configurations to detect issues with configurations before they are applied. This has been enhanced with a new “Configuration Analysis” panel which displays validation results as Error or Warning codes, with a tool tip providing more information.

Gateway API Support

OpenShift Service Mesh 2.2 introduced tech preview support for the up and coming Kubernetes Gateway API. OpenShift Service Mesh 2.3 release brings initial support to Kiali as well, allowing users to configure Gateway API specifications via Kiali:

What’s Next for OpenShift Service Mesh?

This release provides several hints of what is to come for OpenShift Service Mesh - in particular, increasing convergence with upstream Istio, an embrace of Kubernetes Gateway API as well as improved integrations with the OpenShift ecosystem. Customers can expect us to not just continue but accelerate down this path.

It’s an exciting time in the Istio community - with the Istio now a part of the Cloud Native Compute Foundation (CNCF) and the recent announcement of “ambient mesh” - an Istio data plane option without sidecars.

For more information on OpenShift Service Mesh 2.3, see the full documentation here.