This Lab, logically follows previous steps required to provision and curate a Kubernetes cluster. Please review them before proceeding. If you are in doubt, feel free to contact me directly via https://www.linkedin.com/in/citurria/
Introducing Service Mesh
Service Mesh is a networking model that sits as a layer of abstraction to manage backend service-to-service communication in a microservice-based topology. Service Mesh is implemented as an array of lightweight network proxies (also known as sidecar) that are deployed alongside the application code (microservice). In Kubernetes, these proxies are deployed as lightweight containers inside the same Pods where the application containers reside. That way, they can intercept all inbound and outbound traffic going into the Application Container(s) and so have the capability to apply policy enforcement, manageability, monitoring, etc.
Istio is an open, platform-independent service mesh designed to manage communications between micro services and applications. Without requiring changes to the underlying services, Istio provides automated baseline traffic resilience, service metrics collection, distributed tracing, traffic encryption, protocol upgrades, and advanced routing functionality for all service-to-service communication.
Developer’s Patterns (also known as software design pattern) are general, reusable solutions to commonly occurring problems within given context in software design. They are descriptions or templates for how to solve problems that can be used in many different development scenarios in the form of best practices.
In this lab, we will look into one the most popular pattern – The Circuit Breaker, which are widely applied in microservices, container-based development, as well as integration projects. It helps protect microservices from failing/rapid recovery due to external factors associated to the interaction with other microservices, e.g. dependent microservices long delays in response. We will discover the circuit breaker mechanism as implemented with Istio.
We’ll also take the opportunity to explore the concept of the service mesh more generally and make a hands-on exploration of some of the additional capabilities provided by the Istio service mesh – including request routing, fault injection, telemetry, and request tracing.
Book Info Hands-on lab
In this this laboratory, we are going to use a “BookInfo” Microservices-based application, where each microservice runs on different technology and are completely unaware of the existence of each other.
The BookInfo application consists of the following microservices:
- Product Page (Python): It is a landing page with information about details of books, reviews and ratings (i.e. each of the other microservices)
-
Reviews (Java): Book Reviews. As part of the example, 3 different versions of this microservice are available
- Version 1: No concept of book ratings.
- Version 2: Book ratings come in black stars.
- Version 3: Book ratings come in red stars.
Each of these versions are configured as Round-Robin rules in the Ingress controller. This means that by refreshing the page, the 3 different review page versions will be invoked and shown in the website at a time.
This results in:
Version 1 |
Version 2 |
Version 3 |
|
|
|
- Ratings (NodeJS): Provides information of books ratings.
- Details (Ruby): Provides details of books.
When requests come from the public Internet, they will first hit a Load Balancer, that in this case is implemented as an Istio-based
Ingress-Controller (via the use of Envoy as the network proxy) inside the kubernetes cluster.
I hope you found this blog useful. If you have any question or comment, feel free to contact me directly at https://www.linkedin.com/in/citurria/
Thanks for your time.
2 thoughts on “Service Mesh 101 – Getting familiar with Istio and Envoy”