Introducing OpenShift Service Mesh 2.4

We are pleased to announce the release of Red Hat OpenShift Service Mesh 2.4. 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.4 updates the underlying version of Istio to 1.16 and Kiali to 1.65. This release continues our progress toward a greater convergence between OpenShift Service Mesh and upstream Istio - with much more to come in the future.

In addition to the updates from the Istio and Kiali communities, this release brings generally available (GA) support for a cluster-wide deployment topology, an integration with cert-manager, external authorization, single stack IPv6 and a Prometheus extension provider for use with OpenShift monitoring or an external Prometheus.

Istio Updates

Users upgrading from OpenShift Service Mesh 2.3 will see improvements from Istio 1.15 and 1.16. While these releases are more incremental changes, they do contain a few notable updates and hints of what’s to come in Istio’s future. For a full list, review the Istio 1.15 and 1.16 change notes.

Cluster-Level Topology is Generally Available

OpenShift Service Mesh’s cluster-wide topology is now generally available. We introduced this feature in 2.3 as Technology Preview to provide an option for running Istio at the cluster-level as an alternative to the default “multi-tenant” topology, which installs Istio at a namespace level to allow multiple Istiod control planes to exist within a single cluster.

The new cluster-wide approach is consistent with community Istio and will be preferable for the majority of users who do not require multiple Istio control planes per cluster. This will provide superior performance and resource utilization for maintaining a large service mesh within a single cluster. It will significantly reduce the number of Kubernetes API Server calls in large meshes. While “multi-tenant” remains the default topology in 2.4, we recommend that users without the need for multiple Istio control planes in a single cluster use the new cluster-wide mode going forward.

The cluster-wide topology can be set using the `spec.mode` field in the ServiceMeshControlPlane resource. In this mode, Istiod will watch all namespaces. The Istio Discovery Selectors feature can be used to limit which namespaces are watched. As of 2.4, the Discovery Selectors feature has also been made generally available.

The ServiceMeshMemberRoll resource is then used to scope automated sidecar injection. Unlike the multi-tenant configuration (which has not changed), cluster-wide configuration uses label selectors to specify which namespaces are to be part of the service mesh. By default, namespaces with the label `istio-injection=enabled` will be added to the mesh. 

We will continue to support multi-tenant and multiple control plane use cases, though we will look to evolve our implementation to converge with experimental upstream work around multiple control planes in a single cluster. We believe it will be in the best interest of both our customers and the Istio community for OpenShift Service Mesh to evolve based on upstream features - more on this strategy in the “What’s Next” section below.

Cert-Manager Integration

While Istio provides an “all-inclusive” solution for end-to-end encryption and certificate management (including certificate creation, self-signing, distribution, rotation, etc), many enterprises want to manage credentials using a solution like Hashicorp Vault or Venafi. cert-manager, as an extensible Kubernetes certificate controller, enables such integrations.

With some much appreciated contributions from JetStack, OpenShift Service Mesh can now be configured to use cert-manager as a provider of certificates for workloads, rather than Istio’s internal CA (Citadel). Through cert-manager, service mesh can now issue certificates to workloads from any of cert-manager’s supported issuers, such as Vault, Let’s Encrypt, Venafi or a private PKI.

Note that the istio-csr agent is required for cert-manager to provide certificates to  Istio workloads. The documentation for the feature shows the use of the community istio-csr for demonstration purposes. OpenShift is expanding its support for cert-manager, with the recently made generally available cert-manager operator. We will aim to provide a fully supported integration - including istio-csr at a later time. cert-manager can be used to issue certificates for an Istio Gateway without istio-csr.

External Authorization is Generally Available

Back in Istio 1.9, a feature was added to allow Istio’s Authorization Policy to delegate access control to an external authorization system. This is especially useful for integrating with 3rd party authorization providers, such as Open Policy Agent (OPA) or an oauth2 proxy. To date, this feature has been Technology Preview.

In this release, we added three supported extensionProviders to the ServiceMeshControlPlane configuration - envoyExtAuthzHttp, envoyExtAuthzGrpc and Prometheus(see below). Support for the envoyExtAuthzGrpc provider will follow shortly in a minor release. The envoyExtAuthzHttp and envoyExtAuthzGrpc providers allow users to define an external authorizer, which can be used with Istio’s External Authorization feature. With this feature now promoted to beta in Istio 1.16, we are declaring it to be generally available as part of OpenShift Service Mesh 2.4.

IPv6 Support

Of particular interest to our telco customers, the service mesh team spent significant time over the past few months building up our quality engineering capabilities around IPv6. We are now in a position to declare generally available support for IPv6 with OpenShift Service Mesh. Note that this support is for single stack IPv6 clusters only, and mixed or dual-stack IPv4/IPv6 clusters are not supported with OpenShift Service Mesh. Work continues upstream to advance dual-stack support in future Istio releases, with the first experimental features contributed to 1.17. We look forward to contributing to these efforts to eventually bring full dual-stack support to Istio in the future.

Service Mesh and OpenShift Infrastructure Nodes

OpenShift infrastructure nodes are machines that host only infrastructure components, such as the default router, the integrated container image registry, and the components for cluster metrics and monitoring. These infrastructure machines are not counted toward the total number of subscriptions that are required to run the environment. We now provide official support and documentation for running the OpenShift Service Mesh’s control plane components on infrastructure nodes.

OpenShift Monitoring & Prometheus Integration

Since day 1, OpenShift Service Mesh has shipped with a supported Prometheus metrics stack. This allows developers to quickly get up and running with Istio and Kiali, without having to think about setting up a metrics stack. While this is convenient for development, it has some gaps when it comes to production monitoring.

Going forward, we will recommend that OpenShift Service Mesh users use OpenShift’s monitoring stack in production. OpenShift monitoring provides a production grade suite that includes features missing from Service Mesh’s stack, such as alerting.

This release provides the features for such an integration. With the new Prometheus extension provider in the ServiceMeshControlPlane, users can configure a Prometheus provider. Istio’s Telemetry API can then be used to expose Prometheus metrics from workloads that are part of the service mesh. With that in place, OpenShift’s cluster monitoring Prometheus (or a 3rd party Prometheus) can be configured to scrape metrics from service mesh workloads. We will provide more detailed documentation on this procedure in the near future.

Kubernetes Gateway API Update

Kubernetes Gateway API represents the next generation standard for networking across both Kubernetes and Service Mesh. We are continuing in our efforts to advance gateway API for both OpenShift Service Mesh and the next generation OpenShift Ingress. Openshift Service Mesh 2.4 updates its Gateway API support to beta. You will notice that additional Gateway API examples have been added throughout the community Istio documentation. The best place to start learning about how to use Gateway API with Istio is the Gateway API tasks section of the Istio documentation.

Kiali has also increased its Gateway API support, with new Gateway API creation wizards and “cross-object” validations to make it easier to find and fix errors across multiple resources.

Gateway API remains a Technology Preview for OpenShift Service Mesh. To use Gateway API with Openshift Service Mesh, it must be enabled in the ServiceMeshControlPlane. See the release notes for more details.

OpenShift Service Mesh Console

Our team continues to evolve the OpenShift Service Mesh Console - an operator plugin that adds a “Service Mesh” tab to the OpenShift console, and adds service mesh details and metrics throughout the console. This includes quick access to Kiali’s topology view and Istio and Envoy metrics to the Workload, Deployment, Networking and Service pages.

Kiali Updates

As with every release, Kiali brings in more features to make service mesh easier to navigate and understand. In this release, new information has been added to the control plane status to about different Istio components, such as the minimum mTLS version used in the mesh.

Kiali Access to Istiod

There are times when you may want to limit Kiali’s access to Istio resources. Some of our users want to limit Kiali’s capabilities for security reasons, while there may also be times when Kiali is unable to access certain resources. To make Kiali read-only, there is the viewOnlyMode setting (default: false). New in this release is the istio_api_enabled setting (default: true), which can be used when Kiali is unable(or it is undesirable) to access the Istiod control plane. When this setting is used, there are several restrictions imposed on Kiali.

Editing Annotations

Annotations can be used for many different things in Kubernetes. For example, in OpenShift Service Mesh, the annotation sidecar.istio.io/inject: 'true' is used to enable sidecar injection on a given pod template. Kiali now provides the ability to edit such annotations within the console via Actions in the Workload and Services pages.

Service Mesh in Production E-Book

Finally, we know that bringing service mesh to production can present a lot of challenges. There are many things to consider. This is why two of Red Hat’s Service Mesh experts, Stelios Kousouris and Ortwin Schneider have recently published a new ebook: Getting Started with OpenShift Service Mesh - A guide to production deployment and day 2 operations. This is the most extensive guide to service mesh that Red Hat has produced, and we recommend it to anyone looking to get started!

What’s Next?

The service mesh space continues to move quickly. We have started work on a 3rd major release that aims to largely converge OpenShift Service Mesh with community Istio. This convergence is taking place for several reasons - most importantly, that we feel it is in the best interest of both our customers and the community to deliver an offering that is as close to community Istio as possible. This means that our customers will more quickly obtain the benefits of the work done by the Istio community with full support from Red Hat for Istio as part of the OpenShift platform to build, modernize, and deploy applications at scale. For the community, this means our engineers will have more time to evolve service mesh in collaboration with the Istio community. We will have a preview release of OpenShift Service Mesh 3.0 later this year.

Beyond Sidecars

Istio Ambient Mesh is an exciting new technology that is cooking in the upstream community. As of Istio 1.18, it has been included as a “work in progress” Alpha feature. It brings a new dataplane to Istio, where sidecars are optional. With Ambient mesh, the functionality of a sidecar is divided between two layers:

• A per node lightweight “Z Tunnel” (“Z” for Zero Trust) proxy that manages L4 features, such as pod-level mTLS encryption, L4 observability and service-level policies.
• An optional per service-account Waypoint Envoy proxy that will provide L7 application-level policy, traffic management and observability.

This architecture aims to make service mesh easier and more incremental to adopt. By removing the need for a sidecar proxy, applications will no longer need to be modified or restarted to be added to a mesh. Users who only want features like pod-level encryption and simple policies can obtain this with the “Z Tunnel” layer, without the need to pay the cost of L7 mesh features. Users who want L7 features such as application-level traffic management, may deploy “Waypoint” proxies scoped to a particular service account. Finally, users who still want the features of an Envoy sidecar proxy will still be able to use one. Ambient mesh will be backward compatible with existing Istio sidecar based dataplanes - so it is not something to wait for before adopting Istio.

We are watching Ambient mesh’s development with excitement, and taking steps to make it work with OpenShift with the intent of making it available for “developer preview” in a future release of OpenShift Service Mesh. That said, it is still in rapid development, and we do not see it being supported as generally available this year. Watch future releases of OpenShift Service Mesh for more updates.

To learn more about OpenShift Service Mesh, learn more here.