OpenShift Service Mesh

Guide to OpenShift Tutorial
Chapter 3 OpenShift Service Mesh

Many DevOps teams use a service mesh to improve visibility and streamline management within complex microservices-based systems. A service mesh is a design pattern for a transparent infrastructure layer that can extend the functionality of a network and improve observability.

In practice, a service mesh usually includes a control plane that dictates how the services communicate and a data plane that directs the traffic and enforces policies. One of the most popular enterprise-grade service mesh implementations is Red Hat OpenShift’s Service Mesh.

To help you better understand the topic, this article will review Red Hat OpenShift use cases and how OpenShift implements a service mesh using the open-source projects Istio, Kiali, and Jaeger.

Red Hat OpenShift Service Mesh Use Cases

There are several use cases for service meshes, and the particulars vary by use case. Here are some of the most common use cases which we’ll explore in this article.

Red Hat OpenShift Service Mesh Use Cases

Use Case Description
A/B Testing Test multiple versions of a feature to see which one users respond to more favorably.
Canary Deployments Systematically phase out an older version of an application by gradually adjusting the ratio of traffic being sent from an old version to a new version.
Rate Limitations Control the rate at which an application receives requests, ensuring any individual instance is not overloaded.
Access Control Control who and when your application can be accessed.

Understanding Red Hat OpenShift Service Mesh

Red Hat's service mesh implementation is a combination of the following open-source projects:

  • Istio - Traffic control
  • Kiali - Traffic visualization
  • Jaeger - Request tracing

This section will review each component and explain how they fit into the service mesh.

As a reminder, OpenShift Operators are the preferred way to install and manage applications. Operators help manage the deployment and updating of application pods. These components can be installed via operators in the OperatorHub.

Istio

Istio provides features such as:

  • Security
  • Traffic management
  • Traffic flow visualizations

Isito enables all of this functionality without developing and maintaining all of the functions within the application itself. This makes development simpler because teams have standard libraries and functions to implement instead of designing solutions from scratch.

Istio consists of a control and data plane. The control plane takes the desired configuration and lays out the environment creating virtual services and destination rules. It also programs and deploys proxy sidecars alongside application pods. The data plane, which is made up of the sidecars, handles the communication between these services. Without a service mesh, this functionality would need to be built into every application.

As part of the Istio configuration, Istio deploys an Envoy proxy sidecar alongside each pod and configures all non-local communication to go through the proxy. The sidecars make up the Isito data plane, representing the communication between the microservices.

An overview of communications in an Istio Mesh.
An overview of communications in an Istio Mesh.

Kiali

Kiali provides a visual management console for the Istio service mesh. It makes it easier to visualize the topology, see how traffic flows from service to service, and modify the Isitio config.

The table below details Kiali’s key features

Kiali Features

Feature Description
Topology visualizations Once traffic is flowing, Kiali can visually represent all of the microservices reporting to it.
Tracing visualizations As traffic flows, Kiali shows an animated path as a request makes its way through the environment.
Health visualizations By looking at the visual representation of the environment,
Kiali traffic flow visualizations for multiple services.
Kiali traffic flow visualizations for multiple services.
Kiali can verify Istio configuration, here giving a visual representation of how traffic balancing is configured in a Virtual Service
Kiali can verify Istio configuration, here giving a visual representation of how traffic balancing is configured in a Virtual Service

Jaeger

As part of the OpenShift Service Mesh, Jaeger — which was created by Uber — provides distributed request tracing within an application. It is OpenTracing compliant and inspired by projects like Dapper and OpenZipkin.

Jaeger allows tracing of a request through an application using traces and spans to track the beginning and the end of a request.

With this information, it is easier for a developer to understand traffic flows, identify bottlenecks, and determine the root cause of issues within an application.

Jaeger’s user interface can drill down into potential bottlenecks and areas for improvement.
Jaeger’s user interface can drill down into potential bottlenecks and areas for improvement.
Jaeger’s user interface displays stats on the durations of requests.
Jaeger’s user interface displays stats on the durations of requests.

OpenShift Service Mesh Functions

Understanding the main components or the “how” of Red Hat OpenShift Service Mesh enables the discussion of the “why”. Now that we know how OpenShift Service Mesh works, we can explore the use cases it enables.

A/B Testing

A/B testing compares two distinct versions of an application to see which version produces more of the desired outcome. Depending on the metrics, the outcome could be which version performs faster or which version leads to more sales conversions.

Istio’s traffic management capabilities allow a developer to configure routes to one or more versions of an application and give a weighted value to each. Below is a sample of a routing rule.

apiVersion: config.istio.io/v1alpha2
                      kind: RouteRule
                      metadata:
                        name: reviews-default
                      spec:
                        destination:
                          name: reviews
                        precedence: 1
                        route:
                        - labels:
                            version: v1
                          weight: 50
                        - labels:
                            version: v3
                          weight: 50                                                      
                  
Get Your Free Trial

Quickly and easily run a Densify trial alongside any other solution and we will prove why Densify is the gold standard for optimization. See results in less than 48 hours.

Start Now

Automated, Intelligent Container Sizing

Kubernetes Autoscaling doesn’t recommend pod limit values or consider I/O. Densify identifies mis-provisioned containers at a glance and prescribes the optimal configuration.

Densify has partnered with Intel to offer one year of free resource optimization software licensing to qualified companies.

Automated, Intelligent Container Sizing
  • Amazon Web Services
  • Microsoft Azure
  • Google Cloud Platform

Canary Deployments

Automic-scaling is built into OpenShift and Kubernetes, but traffic and scaling are closely tied together.

In standard OpenShift, if a developer wanted to test a new version of an application, they could update a deployment with a new image and allow the system to tear down the old version and roll out new versions. This works great for a well-tested and vetted version of an application

What about the testing before that stage?

With Istio canary deployments, teams can have two different versions of an application deployed simultaneously. In this configuration, a virtual service load balances the traffic between deployments based on predefined weights.

For example, a v1 deployment of an application can be deployed with 80% of the traffic going to it. The remaining 20% can be routed to v2 for testing.

Couple this routing with a horizontal pod autoscaler, and the deployment can scale based on traffic. As confidence in v2 grows, traffic to it can be increased. Eventually, v2 will reach 100% and phase out v1.

Rate Limitations

Rate limitations enable DevOps teams to control the amount of traffic to each instance of the application, protecting underlying infrastructure against possible overloads.

For example, If there are ten application instances, each rate limits the amount of traffic, and teams gain a better understanding of overall utilization. In turn, this information enables better decisions about infrastructure growth.

apiVersion: v1
                      kind: ConfigMap
                      metadata:
                        name: ratelimit-config
                      data:
                        config.yaml: |
                          domain: productpage-ratelimit
                          descriptors:
                            - key: PATH
                              value: "/productpage"
                              rate_limit:
                                unit: minute
                                requests_per_unit: 1
                            - key: PATH
                              rate_limit:
                                unit: minute
                                requests_per_unit: 100                                                       
                  
Code from Istio’ (Source)

Access Control

In OpenShift / Kubernetes there are NetworkPolicies which outline how pods communicate with each other. In Istio there are AuthorizationPolicies.

The configurations in Istio’s control plane are turned into Envoy proxy configurations and operate as a layer 7 proxy. This can be a very flexible method of controlling traffic to applications.

Two key benefits of AuthorizationPolicies are that they:

  • Allow both ALLOW and DENY rules
  • Allow for distinction between HTTP GET and POST requests.
apiVersion: security.istio.io/v1beta1
                  kind: AuthorizationPolicy
                  metadata:
                    name: httpbin
                    namespace: foo
                  spec:
                    action: DENY
                    rules:
                    - from:
                      - source:
                          namespaces: ["dev"]
                      to:
                      - operation:
                          methods: ["POST"]                                                   
              
Code from Istio (Source)

Conclusion

It's often said that "what is measured, improves". A service mesh is an important aspect of measuring your cloud-native application’s performance

In this article, we reviewed how Red Hat OpenShift Service Mesh uses Istio, Kiali, and Jaeger to implement a service mesh with built-in traffic controls, observability, and tracing. With OpenShift Service Mesh, developers gain a more complete view of their applications. As a result, they can optimize performance and proactively address minor issues before they become major problems.

Like this article?

Subscribe to our LinkedIn Newsletter to receive more educational content

Subscribe now

Automated, Intelligent Container Sizing

Kubernetes Autoscaling doesn’t recommend pod limit values or consider I/O. Densify identifies mis-provisioned containers at a glance and prescribes the optimal configuration.

Densify has partnered with Intel to offer one year of free resource optimization software licensing to qualified companies.

Automated, Intelligent Container Sizing
  • Amazon Web Services
  • Microsoft Azure
  • Google Cloud Platform

Continue Reading this Series