Deploying an application into OpenShift Service Mesh

Overview

Red Hat OpenShift Service Mesh (OSM) 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. OSM is based on the open source Istio project.

This article explains how to deploy a cloud-native sample application into OSM and highlights some key differences with using OSM compared to Istio.

Intended audience

This article is intended for teams familiar with OpenShift, microservices and the service mesh concept who are preparing to deploy microservices into OpenShift Service Mesh.

Prerequisites

  • Familiarity with the concepts involved in a Service Mesh.

  • The OpenShift Service Mesh (OSM) Operator is installed into your OpenShift cluster. See the OpenShift documentation for an installation guide.

  • The istio-system project exists and the target project for the sample application deployment has been added to the OSM ServiceMeshMemberRole configuration.

Preparing services for deployment

Sidecar injection

The OSM uses the same Envoy proxy sidecar container as Istio does to manage traffic within the service mesh. OSM requires deployments to specify the annotation sidecar.istio.io/inject: "true" to opt-in to the sidecar injection.

Traffic ingress

Incoming traffic must enter the Service Mesh via a route that the Service Mesh has created. A route will be automatically created for every instance of a gateway. Replace any explicit route creation with gateways.

When using the istio-system as a multi-tenant control plane, each ingress needs a VirtualService instance, which defines the traffic routing at the point of ingress. As a minimum, the traffic must be routed to the correct VirtualService based on the traffic's incoming DNS name.

Services

Kiali can access the Service Mesh components configuration and will report on configuration errors. While not required for functionality, all services should be labelled and ports should have a name and protocol defined to avoid Kiali reporting configuration errors.

Internal traffic routing

Destination rules for each service must exist for traffic to be routed to the pods. In the most basic example, all traffic is routed to all pods in a service. The destination rules typically use the version label on pods to route traffic accordingly.

Pods

Pods must have specific labels for Pilot to manage traffic routing and for Kiali to display the service mesh correctly. Pods must have metadata labels called app and version, which identify the microservice application and the version of the application code running in the pod.

Example application

Weaveworks has a sample microservice-based application called the Sock Shop that UKCloud has modified to run inside OSM v1. See the sample code on GitHub at https://github.com/UKCloud/sock-shop-service-mesh.

With the release of OSM v2, Red Hat has documented how to install a sample application into OSM v2. You can find more details in the Red Hat Service Mesh documentation.

References

Feedback

If you find a problem with this article, click Improve this Doc to make the change yourself or raise an issue in GitHub. If you have an idea for how we could improve any of our services, send an email to feedback@ukcloud.com.