OpenShift Platform Day2 - Service Mesh
As the number of services within an OpenShift environment grow the complexity of the communications between services or the service mesh for that environment also grows in complexity. To simplify management of this complexity an OpenShift Service Mesh based on ISTIO is provided.
Red Hat OpenShift Service Mesh is a platform that provides behavioral insight and operational control over the service mesh, providing a uniform way to connect, secure, and monitor microservice applications.
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 throughout your environment that intercepts all network communication between microservices.
The service mesh may have two distinct use cases one where the DevOps and/or SRE team utilizes the service mesh to discern issues. In other words the service mesh information is used for monitoring purposes a key aspect of Day 2 operations. The OpenShift Service Mesh itself must also be monitored and maintained. The other use case is where the service mesh is utilized to restrict traffic and enforce policy. Specific privilege is required to setup the service mesh for usage by DevOps / SREs.
The high level activities required to provide DevOps / SRE teams with a functioning service mesh, enumerated below, entail setting up several prerequisite services and establishing a control plane within which service communications are handled. Cluster administrator access is required to perform these steps. After setup the DevOps/SRE teams can implement the OpenShift Service Mesh functionality for their service(s).
Finally, the Red Hat OpenShift Service Mesh offers a horizontal view of several topics in this document utilizing its sidecar technology to tie the vertical topics together. For example Build and Deploy details Canary releases and A/B testing. The Security topic implements access control which can also be implemented in the service mesh. Another of many examples is how the sidecar technology can assist in monitoring as discussed in the Monitoring topic.
There are several tasks for Day 1 activities as follow.
- Required - account with cluster administrator access
- Install Service Mesh and Prerequisites:
- Install Elasticsearch operator
- Install Jaeger operator
- Install Kiali operator
- Install Service Mesh Operator
- Create Service Mesh Control Plane with the OperatorHub
- Create ServiceMeshMemberRoll to target an application for the service mesh
- Implement Service Mesh functionality (policy, tracing, security, canary test etc)
The day 2 platform setup considerations for the service mesh essentially discerns how configuration changes are handled. The ideal method is to manage via configuration files that control your service mesh configuration. Further if such files are control by gitHub for example different DevOps/SRE personnel can make pull requests against them to grow the application(new service added) and user(new developer added to update a service) setup. Thus application management can be achieved via configuration of the service mesh. In addition to the configuration management and similar steps to maintain the service mesh, monitoring tasks also need to be performed to assure that the mesh is operating as desired. Furthermore tools like Kiali described below can be used to visualize the real time traffic flow established within the service mesh and thereby serve as another means to monitor the operation of the service mesh.
As mentioned one purpose of the service mesh is to setup Developers and applications/services. One method that SREs or DevOps personnel can control such policy is via control planes. An example configuration provides one control plane for all application development teams and several data planes, one for each application or service that needs to be separated. Data planes are one way to instrument a service mesh to handle a multi cluster environment. Thus adding or re-using existing data and control planes as the application landscape grows is a normal day 2 application task.
An installation of Red Hat OpenShift Service Mesh differs from upstream Istio community installations in multiple ways:
- OpenShift Service Mesh installs a multi-tenant control plane by default
- OpenShift Service Mesh extends Role Based Access Control (RBAC) features
- OpenShift Service Mesh replaces BoringSSL with OpenSSL
- Kiali and Jaeger are enabled by default in OpenShift Service Mesh
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 Container Platform.
A service mesh provides traffic monitoring, access control, discovery, security, resiliency, and other useful things to a group of services. Istio does all that, but it doesn’t require any changes to the code of any of those services. To make the magic happen, Istio deploys a proxy (called a sidecar) next to each service. All of the traffic meant for a service goes to the proxy, which uses policies to decide how, when, or if that traffic should go on to the service. Istio also enables sophisticated DevOps techniques such as canary deployments, circuit breakers, fault injection, and more.
Istio’s functionality running outside of your source code introduces the concept of Service Mesh. That’s a coordinated group of one or more binaries that make up a mesh of networking functions.
Kiali provides observability into the Service Mesh running on OpenShift Container Platform. Kiali helps you define, validate, and observe your Istio service mesh. It helps you to understand the structure of your service mesh by inferring the topology, and also provides information about the health of your service mesh.
Kiali provides an interactive graph view of your namespace in real time that provides visibility into features like circuit breakers, request rates, latency, and even graphs of traffic flows. Kiali offers insights about components at different levels, from Applications to Services and Workloads, and can display the interactions with contextual information and charts on the selected graph node or edge. Kiali also provides the ability to validate your Istio configurations, such as gateways, destination rules, virtual services, mesh policies, and more. Kiali provides detailed metrics, and a basic Grafana integration is available for advanced queries. Distributed tracing is provided by integrating Jaeger into the Kiali console.
Kiali is installed by default as part of the Red Hat OpenShift Service Mesh.
Every time a user takes an action in an application, a request is executed by the architecture that may require dozens of different services to participate in order to produce a response. The path of this request is a distributed transaction. Jaeger lets you perform distributed tracing, which follows the path of a request through various microservices that make up an application.
Distributed tracing is a technique that is used to tie the information about different units of work together—usually executed in different processes or hosts—in order to understand a whole chain of events in a distributed transaction. Distributed tracing lets developers visualize call flows in large service oriented architectures. It can be invaluable in understanding serialization, parallelism, and sources of latency.
Jaeger lets service owners instrument their services to get insights into what their architecture is doing. Jaeger is an open source distributed tracing platform that you can use for monitoring, network profiling, and troubleshooting the interaction between components in modern, cloud-native, microservices-based applications. Jaeger is based on the vendor-neutral OpenTracing APIs and instrumentation.
Using Jaeger lets you perform the following functions:
- Monitor distributed transactions
- Optimize performance and latency
- Perform root cause analysis
Jaeger is installed by default as part of Red Hat OpenShift Service Mesh.