Red Hat OpenShift Service Mesh is a platform that provides behavioral insight and operational control over the service mesh. It gives you a uniform way to connect, secure, and monitor microservices in your OpenShift Container Platform environment.

Red Hat OpenShift Service Mesh is a Technology Preview Release

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.

Related information

Understanding service mesh

A service mesh is the network of microservices that make up applications in a distributed microservice architecture and the interactions between those microservices. When 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 adds a transparent layer on existing distributed applications without requiring any changes to the service code. You add Red Hat OpenShift Service Mesh support to services by deploying a special sidecar proxy to relevant services in the mesh that intercepts all network communication between microservices. You configure and manage the service mesh using the control plane features.

Red Hat OpenShift Service Mesh gives you an easy way to create a network of deployed services that provide:

  • Discovery

  • Load balancing

  • Service-to-service authentication

  • Failure recovery

  • Metrics

  • Monitoring

Service Mesh also provides more complex operational functions including:

  • A/B testing

  • Canary releases

  • Rate limiting

  • Access control

  • End-to-end authentication

Red Hat OpenShift Service Mesh Architecture

Red Hat OpenShift Service Mesh is logically split into a data plane and a control plane:

The data plane is a set of intelligent proxies deployed as sidecars. These proxies intercept and control all inbound and outbound network communication between microservices in the service mesh. Sidecar proxies also communicate with Mixer, the general-purpose policy and telemetry hub.

  • Envoy proxy intercepts all inbound and outbound traffic for all services in the service mesh. Envoy is deployed as a sidecar to the relevant service in the same pod.

The control plane manages and configures proxies to route traffic, and configures Mixers to enforce policies and collect telemetry.

  • Mixer enforces access control and usage policies (such as authorization, rate limits, quotas, authentication, request tracing) and collects telemetry data from the Envoy proxy and other services.

  • Pilot configures the proxies at runtime. Pilot provides service discovery for the Envoy sidecars, traffic management capabilities for intelligent routing (for example, A/B tests or canary deployments), and resiliency (timeouts, retries, and circuit breakers).

  • Citadel issues and rotates certificates. Citadel provides strong service-to-service and end-user authentication with built-in identity and credential management. You can use Citadel to upgrade unencrypted traffic in the service mesh. Operators can enforce policies based on service identity rather than on network controls using Citadel.

  • Galley ingests the service mesh configuration, then validates, processes, and distributes the configuration. Galley protects the other service mesh components from obtaining user configuration details from OpenShift Container Platform.

Red Hat OpenShift Service Mesh also uses the istio-operator to manage the installation of the control plane. An Operator is a piece of software that enables you to implement and automate common activities in your OpenShift cluster. It acts as a controller, allowing you to set or change the desired state of objects in your cluster.

Comparing Red Hat OpenShift Service Mesh and upstream Istio community installations

An installation of Red Hat OpenShift Service Mesh differs from upstream Istio community installations in multiple ways. The modifications to Red Hat OpenShift Service Mesh are sometimes necessary to resolve issues, provide additional features, or to handle differences when deploying on OpenShift.

The current release of Red Hat OpenShift Service Mesh differs from the current upstream Istio community release in the following ways:

Multi-tenant installations

Single-tenant control plane installations are known to cause issues with OpenShift Container Platform restarts and upgrades. Multi-tenant control plane installations are the default configuration starting with Red Hat OpenShift Service Mesh 0.12.TechPreview.

Red Hat OpenShift Service Mesh allows you to configure multi-tenant control plane installations, specify the namespaces that can access its Service Mesh, and isolate the Service Mesh from other control plane instances.

Automatic injection

The upstream Istio community installation automatically injects the sidecar to namespaces you have labeled.

Red Hat OpenShift Service Mesh does not automatically inject the sidecar to any namespaces, but requires you to specify the sidecar.istio.io/inject annotation as illustrated in the Automatic sidecar injection section.

Role Based Access Control features

Role Based Access Control (RBAC) provides a mechanism you can use to control access to a service. You can identify subjects by username or by specifying a set of properties and apply access controls accordingly.

The upstream Istio community installation includes options to perform exact header matches, match wildcards in headers, or check for a header containing a specific prefix or suffix.

Upstream Istio community matching request headers example
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: httpbin-client-binding
  namespace: httpbin
spec:
  subjects:
  - user: "cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    properties:
      request.headers[<header>]: "value"

Red Hat OpenShift Service Mesh extends the ability to match request headers by using a regular expression. Specify a property key of request.regex.headers with a regular expression.

Red Hat OpenShift Service Mesh matching request headers by using regular expressions
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: httpbin-client-binding
  namespace: httpbin
spec:
  subjects:
  - user: "cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    properties:
      request.regex.headers[<header>]: "<regular expression>"

Automatic route creation

Automatic route creation is currently incompatible with multi-tenant Service Mesh installations. Ensure that it is disabled in your ServiceMeshControlPlane if you plan to attempt a multi-tenant installation.

Red Hat OpenShift Service Mesh automatically manages OpenShift routes for Istio gateways. When an Istio gateway is created, updated, or deleted in the Service Mesh, a matching OpenShift route is created, updated, or deleted.

If the following gateway is created:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: gateway1
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - www.bookinfo.com
    - bookinfo.example.com

The following OpenShift routes are automatically created:

$ oc -n istio-system get routes
NAME              HOST/PORT                                            PATH      SERVICES               PORT      TERMINATION   WILDCARD
gateway1-lvlfn    bookinfo.example.com                                           istio-ingressgateway   <all>                   None
gateway1-scqhv    www.bookinfo.com                                               istio-ingressgateway   <all>                   None

If this gateway is deleted, Red Hat OpenShift Service Mesh will delete the routes.

Manually created routes are not managed by the Service Mesh.

Catch-all domains

Red Hat OpenShift Service Mesh does not support catch-all or wildcard domains. If Service Mesh finds a catch-all domain in the gateway definition, Red Hat OpenShift Service Mesh will create the route but relies on OpenShift to create a default hostname. The route that Service Mesh creates will not be a catch-all route and will have a hostname with a <route-name>[-<namespace>].<suffix> structure.

Subdomains

Subdomains are supported, but they are not enabled by default in OpenShift. Red Hat OpenShift Service Mesh will create the route with the subdomain, but it will only work after you enable subdomains in OpenShift. See the OpenShift documentation on Wildcard Routes for more information.

TLS

OpenShift routes are configured to support TLS.

All OpenShift routes created by Red Hat OpenShift Service Mesh are in the istio-system namespace.

OpenSSL

Red Hat OpenShift Service Mesh replaces BoringSSL with OpenSSL. OpenSSL is a software library that contains an open source implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. The Red Hat OpenShift Service Mesh Proxy binary dynamically links the OpenSSL libraries (libssl and libcrypto) from the underlying Red Hat Enterprise Linux operating system.

Container Network Interface (CNI)

Red Hat OpenShift Service Mesh includes CNI which provides you with an alternate way to configure application pod networking. When you enable CNI, it replaces the init-container network configuration eliminating the need to grant service accounts and namespaces additional privileges by modifying their Security Context Constraints (SCCs).

Next steps
  • Prepare to install Red Hat OpenShift Service Mesh in your OpenShift Container Platform environment.