Introducing OpenShift Service Mesh 2.6

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

This release includes updates from Istio 1.19 and 1.20 including subsequent patch releases up to Istio 1.20.8. Most notably, this release brings generally available support for Kubernetes Gateway API to manage cluster-wide deployments of OpenShift Service Mesh and a developer preview of Istio’s multi-primary multi-cluster topology.

This release also brings important distributed tracing updates. With the general availability of Tempo based distributed tracing stack, both Jaeger and Elasticsearch are now deprecated and due for removal. As of OpenShift Service Mesh 2.6, Jaeger and Elasticsearch will no longer be installed with service mesh by default.

Kubernetes Gateway API and Istio

While the Kubernetes Ingress API was designed as a simple abstraction for configuring traffic into a cluster in a manner that supported many different load balancer implementations, its simplicity meant that each implementation required customization while leaving many challenges of managing traffic for users to solve.

Kubernetes Gateway API aims to address these shortcomings with a set of APIs that target a broader set of use cases while taking into account the challenges of Kubernetes in a large organization.  Like the Ingress API, Kubernetes Gateway API is a universal specification with many implementations, including Istio. Building on this, Kubernetes Gateway API is also:

• Role-oriented - Gateway API models organizational roles that use and configure Kubernetes networking. Different roles, such as cluster-admins and application developers have different needs that map to different APIs
• Expressive - Gateway API includes things like header-matching, traffic-weighting and other capabilities. This has enabled the APIs to cover Ingress use cases, as well as use cases supported by service meshes
• Extensible - Finally, Gateway API provides much more extensibility, by allowing custom resources to be linked at various layers within API, making much more granular customization within the API possible

Put together, this allows Kubernetes Gateway API to not just address “north-south” traffic (“ingress” and “egress”) use cases, but also “east-west” use cases handled by a service mesh. With this in mind, the GAMMA initiative was formed to define how Kubernetes Gateway API can be used to manage a service mesh. Istio, as a part of this initiative, has the long term goal of having Kubernetes Gateway API as the default set of APIs used to configure Istio, while continuing to support the existing Istio APIs that users are familiar with (e.g. VirtualService, DestinationRule, etc).

OpenShift Service Mesh 2.6 includes support for Kubernetes Gateway API 1.0, and thus, we are making support for Gateway API generally available when used with a cluster-wide mesh topology.

The feature will remain available as a technology preview for multitenant mode, because in this mode Istiod operates as a namespace scoped resource and thus, is not able to support some of Gateway API’s features which require cluster-level access. In OpenShift Service Mesh 3 and beyond, all topologies, including multiple control planes, will require Istiod to run as a cluster-scoped resource and thus Kubernetes Gateway API will be fully generally available in 3.0.

We encourage users to get started with Kubernetes Gateway API for new Istio projects, and only fallback to the Istio APIs when advanced features are required. This blog on the Istio community site provides more information.

As the new standard for Kubernetes networking, Gateway API support will be expanding across the platform! Later this year, OpenShift Networking will introduce a technology preview release of OpenShift Ingress operator with support for Gateway API.

Important distributed tracing updates

In late 2023, OpenShift Distributed Tracing 3.0 was released, based on the Tempo and OpenTelemetry collector operators, and the Jaeger and Elasticsearch operators were deprecated. In OpenShift Service Mesh 2.5, we introduced support for using service mesh with the Tempo based tracing stack. In OpenShift Service Mesh 2.6, we will build on this with improved documentation for migrating to both the Tempo and OpenTelemetry operators with service mesh.

As Jaeger and Elasticsearch are both slated for removal in a later release, we are no longer installing them by default with new installations of OpenShift Service Mesh. We recommend new OpenShift Service Mesh installations be configured to use Tempo after installation, while existing installations of OpenShift Service Mesh should be migrated to the Tempo based tracing stack as soon as possible.

Note that since the Jaeger and Elasticsearch operators are supported as part of OpenShift Distributed Tracing, they may reach end of life before OpenShift Service Mesh 2.6. You will be required to migrate off of Jaeger and Elasticsearch before upgrading to OpenShift Service Mesh 3.0.

Kubernetes startup probes

The Istio 1.19 and 1.20 releases contain a wide range of updates, and we wanted to call out a couple of enhancements to managing pod lifecycles in a service mesh - startup probes and Kubernetes native sidecars.

As introduced in Istio 1.20, the proxy sidecar container now has a startup probe configured by default. A startup probe is used by Kubernetes to know when a container application has started. If a startup probe is configured, Kuberentes liveness and readiness probes will only begin once the startup probe has succeeded. Startup probes are particularly useful when the expected time for an application to initialize is different from the time to determine if the application is still alive (liveness probes) or still responsive (readiness probes).

For Istio’s proxy sidecar containers, the startup probe is set more aggressively (1s) than a readiness probe (15s) which would run throughout the entire pod lifecycle, allowing the pod to start more quickly while reducing the number of probe calls over the life of the pod. If the startup probe does not pass after 10 minutes, the pod will be terminated. Previously, the pod would not terminate even if the proxy was unable to start indefinitely.

Kubernetes-native sidecars and init containers

While Istio is known for the “sidecar” pattern - a proxy container is deployed with your application container within the same pod, native support for managing this pattern in Kubernetes has only been added recently.

The lack of this native support for sidecars resulted in several potential challenges when it came to managing the lifecycle of the proxy and application containers together. This blog post describes those challenges, most notably using Istio with jobs that run to completion or with init containers that require network access before Istio’s proxy was ready.

Kubernetes-native sidecars address these challenges. It graduated to beta in Kubernetes 1.29, and is now available as part of Red Hat OpenShift 4.16. Kubernetes sidecars are implemented as init containers that remain running after Pod startup. This means that sidecar containers benefit from the sequential ordering guarantees of init containers, and can be mixed with regular init containers to create more complex pod initialization workflows - addressing the challenges of both run to completion jobs and init containers requiring network access. 

Kubernetes-native sidecars may be used with OpenShift Service Mesh 2.6 and OpenShift 4.16 or later by setting the “ENABLE_NATIVE_SIDECARS” environment variable to “true” for the “pilot” container of the ServiceMeshControlPlane resource.

Kiali and OpenShift Service Mesh Console updates

OpenShift Service Mesh 2.6 will continue to use Kiali 1.73 - the same version as OpenShift Service Mesh 2.5. Kiali is also used to support the OpenShift Service Mesh console plugin. While we usually ship a new version of Kiali with each new OpenShift Service Mesh release, a compatibility challenge between Kiali, the console plugin, and OpenShift console meant that newer versions of Kiali that are built with Patternfly 5 will require OpenShift 4.15+. As we expect a large number of customers to adopt OpenShift Service Mesh 2.6 on OpenShift 4.14, we have made the decision to retain Kiali 1.73 to ensure that OpenShift 4.14 customers are able to use Kiali with the OpenShift Service Mesh console plugin.

We will resume updates of Kiali in OpenShift Shift Service Mesh 3.0, with significant updates including a new mesh topology view, support for Istio’s multi-cluster topologies, and Istio’s ambient mode. We anticipate that Istio’s ambient mode will be developer preview in OpenShift Service Mesh 3.0.

Multi-cluster “multi-primary” preview

Service Mesh 3.0 will provide support for Istio’s multi-cluster topologies, such as multi-primary, primary-remote, and external control planes. In anticipation of this support, we have published a blog post that describes the multi-primary topology, how it compares to the currently supported federation model, and how to begin experimenting with the feature using OpenShift Service Mesh 2.6. This is an important read for users considering a multi-cluster deployment of service mesh, and we welcome user feedback on this feature.

Update on OpenShift Service Mesh 3.0

We anticipate that this will be the final release of OpenShift Service Mesh 2, with the next generally available release planned to be OpenShift Service Mesh 3.0 late this year. In the coming weeks, we will announce a technology preview release of OpenShift Service Mesh 3.0, based on the sail-operator hosted in the istio-ecosystem organization. OpenShift Service Mesh 3.0 will no longer be based on the Maistra.io project, but rather a direct productization of Istio, hosted in the OpenShift Service Mesh Github repository.

The technology preview announcement will contain more details on OpenShift Service Mesh 3.0, its development progress, and the anticipated migration path. We are in the process of recruiting customers for a “high-touch” early access program. If you are interested, please reach out to your Red Hat account team for more information.

Preparing for OpenShift Service Mesh 3.0

In case you missed it, we published a blog post called Preparing for OpenShift Service Mesh 3, which discusses several important changes coming with OpenShift Service Mesh 3.0, and how users can prepare. These are steps that will need to be taken in advance of migrating to OpenShift Service Mesh 3.0 when it is available, so we strongly recommend that OpenShift Service Mesh users review the blogpost.

In addition to the distributed tracing migration discussed above, OpenShift Service Mesh 2.6 includes documented procedures to migrate off of control plane managed Gateways and Istio OpenShift Routing (IOR). These procedures will have to be carried out prior to upgrading to OpenShift Service Mesh 3.0.

As a reminder, the developer preview of OpenShift Service Mesh 3 continues to be available for OpenShift users via OperatorHub as the Sail Operator. Users may ask questions or provide feedback regarding this community operator via the Istio community “sail-operator” Slack channel.

Learn more about OpenShift Service Mesh