Introduction to Red Hat OpenShift Service Mesh 1.0.TechPreview

Red Hat OpenShift Service Mesh overview

This release of Red Hat OpenShift Service Mesh is a Technology Preview release only. Technology Preview releases are not supported with Red Hat production service-level agreements (SLAs) and might not be functionally complete, and Red Hat does NOT recommend using them for production. Using Red Hat OpenShift Service Mesh on a cluster renders the whole OpenShift cluster as a technology preview, that is, in an unsupported state. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information see Red Hat Technology Preview Features Support Scope.

Red Hat OpenShift Service Mesh is a platform that provides behavioral insights and operational control over the service mesh, providing a uniform way to connect, secure, and monitor microservice applications.

The term service mesh is often used to describe the network of microservices that make up applications based on a distributed microservice architecture and the interactions between those microservices. As a service mesh grows in size and complexity, it can become harder to understand and manage.

Based on the open source Istio project, Red Hat OpenShift Service Mesh layers transparently onto existing distributed applications, without requiring any changes in service code. You add Red Hat OpenShift Service Mesh support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices. You configure and manage the service mesh using the control plane features.

This provides an easy way to create a network of deployed services that provides discovery, load balancing, service-to-service authentication, failure recovery, metrics, and monitoring. A service mesh also provide more complex operational requirements, like A/B testing, canary releases, rate limiting, access control, and end-to-end authentication.

Getting support

If you experience difficulty with a procedure described in this documentation, visit the Red Hat Customer Portal at Through the customer portal, you can:

  • Search or browse through the Red Hat Knowledgebase of technical support articles about Red Hat products

  • Submit a support case to Red Hat Global Support Services (GSS)

  • Access other product documentation

If you have a suggestion for improving this guide or have found an error, please submit a Bugzilla report at against Product for the Documentation component. Please provide specific details, such as the section number, guide name, and {product-title_short} version so we can easily locate the content.

New and changed features

New features

Red Hat OpenShift Service Mesh provides a number of key capabilities uniformly across a network of services:

  • Traffic Management - Control the flow of traffic and API calls between services, make calls more reliable, and make the network more robust in the face of adverse conditions.

  • Service Identity and Security - Provide services in the mesh with a verifiable identity and provide the ability to protect service traffic as it flows over networks of varying degrees of trustability.

  • Policy Enforcement - Apply organizational policy to the interaction between services, ensure access policies are enforced and resources are fairly distributed among consumers. Policy changes are made by configuring the mesh, not by changing application code.

  • Telemetry - Gain understanding of the dependencies between services and the nature and flow of traffic between them, providing the ability to quickly identify issues.

Known issues

Known issues

These known issues or limitations exist in Red Hat OpenShift Service Mesh at this time:

  • Red Hat OpenShift Service Mesh does not support multi-tenancy.

  • Red Hat OpenShift Service Mesh does not support IPv6, as it it not supported by the upstream Istio project, nor fully supported by OpenShift.

  • The istio-init container requires a privileged security context or at least to run as root and to have the NET_ADMIN capability. The istio-init container needs to be privileged because it needs to properly configure the iptables rules in the pod in order to intercept network connections. The team is currently investigating ideas for ways to reduce the privileges required by Istio.

While Kafka publisher is included in the release as part of Jaeger, it is not supported.

MAISTRA-4 - The uninstall does not remove all the files, and as a result, when you re-install the istio-operator installation fails because "" already exists.

Workaround - In order to cleanly remove the operator execute the following command:

oc process -f istio_product_operator_template.yaml | oc delete -f -

MAISTRA-5 - openshift-ansible-istio-installer-job pod tries to start but with errors.

MAISTRA-21 - Increase elasticsearch memory requirement. The current default in the installer is 512Mi however this appears to be too low for tracing.

Workaround - Include the following in the custom resource definition file.

    elasticsearch_memory: 1Gi