Service Mesh & Openshift

Spread the love

Spread the loveService mesh just provides a better way to track & manage the communication between services ( pod )

Spread the love

Service mesh just provides a better way to track & manage the communication between services ( pod ) already running into your open shift environment, it will basically inject another container inside the running pod, which is keeping track all the inbound and outbound traffic inside your application container bundled within same pod.

Note: Openshift Service Mesh is still tech preview that means if you install it on your production cluster, it will be out of support.

Service Mesh : Just a name, which represents mesh or interconnection between services ( microservices running as containers inside pod )
Openshift Service mesh is a platform which shows realtime insite of communications and control between the microservices, it will provide a controled way to connect, secure and monitor microservices based applications.

specifically, the term service mesh describes the network of microservices that displays how they interconnected, by the time these complex communications increased it become harder to understand and manage.

openshift service mesh is based on open source project called “ISTIO” project, which adds a transparent layer on existing distributed services without requireing any change to the service code.

Service Mesh provides an easy way to create a network of deployed services that provides:

Discovery of other services running under other nodes
Perform load balancing between two applications services
Service to Service authentication for controlled access of secure service
Failure recovery, metrics and monitoring

Basically, openshift service mesh devided between two parts

  1. Data plane : includes a set of intelligent proxies deployed and called sidecars along with the other containers inside the pod. These proxies intercept and control all in-bound and out-bound network communications between microservices ( pod ) in service mesh.
  2. Control Plane : is responsibe for managing and configuring proxies to route traffice ( towards external or internal destination )

A. Envoy Proxy : is a data plane component that intercepts ( traces ) all inbound and outbound traffic for all services in the service mesh. Envoy is deployed as a separate container tag with services in the same pod.

B. Mixer : is a control plane component responsible for enforcing access control and usage policies such as authorization, rate limits, quotas, authentication, request tracing and collect all communication related data
from the envoy proxy and other services.

C. Pilot : is the control plane component responsible for configuring & altering the proxies at runtime, it also provides discovery for envoy sidecars.

D. Citadel : is the control plane component responsible for certificates issueance and rotation of certificates, it provides strong service to service and end user authentication.

Leave a Reply

Your email address will not be published. Required fields are marked *


Share !

Social menu is not set. You need to create menu and assign it to Social Menu on Menu Settings.