Over the past year, the service mesh has emerged as a critical component of the cloud-native stack. Companies such as Paypal, Ticketmaster and Monzo all function fully on cloud-native solutions and they all also added a service mesh to their production applications.
This January, Linkerd (an open source service mesh for cloud native applications) became an official project of the Cloud Native Computing Foundation. But what exactly is a service mesh, and why is it suddenly relevant?
What is a service mesh?
tl;dr: A service mesh is a dedicated infrastructure layer for making service-to-service communication secure, fast and reliable. If you’re building a cloud native application, you need a service mesh.
Service mesh addresses the challenges developers and operators face as monolithic applications transition towards a distributed microservices architecture.
The term “service mesh” is used to describe the network of microservices that make up such applications and the interactions between them. With the growing complexity of the architecture of microservices its management becomes harder to handle too. It may require discovery, load balancing, failure recovery and monitoring. You may also need a more complex operational functionalities such as like A/B testing, canary releases, rate limiting, access control and end-to-end authentication.
Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring and more, without making any changes to the service code itself. You can do it simply by adding special Istio sidecar proxys to particular applications. It will catch all the network communication between your microservices and you can then configure your Istio for:
It is easy to add other functionalities to Istio, however, in its basic configuration it already supports a wide range of advanced deployment strategies.
A/B testing allows to run multiple versions of application functionality in parallell, so that through analytics of user behaviour, the best variant can be determined. New features can be made available to selected groups of users in order to test features in production environments before these features are released to the masses.
These traffic flow management capabilities are one of the advantages of Kubernetes and Istio.
Suppose we have istio on our k8s cluster already up and running. The application running on our cluster is called Bookifno and displays information about a book, similar to a single catalog entry of an online book store. Displayed on the page is a description of the book, book details (ISBN, number of pages and so on) and a few reviews.
The Bookinfo application is divided into four separate microservices:
There are 3 versions of the reviews microservice:
The end-to-end architecture of the application is shown below.
This application is a polyglot, i.e. the microservices are written in different languages. It’s worth noting that these services have no dependencies on Istio, but make an interesting service mesh example, particularly because of the multitude of services, languages and versions for the reviews service.
If I want 90% of the users to use reviews-v1 and 10% use the new reviews-v3, I can simply kubectl apply this yaml, which creates the VirtualService object
Paste in code block hereapiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
...
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v3
weight: 10Refresh the /productpage in your browser and you now see red coloured star ratings approximately 10% of the time. This is because the v3 version of reviews accesses the star ratings service, but the v1 version does not.
In order to expose the v2 only to user jason, create the following rule:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
...
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1
It is obviously a HTTP header end-user: jason that might be added on the product page service.
You can search for the user: jason in cookies too:
- headers:
cookie:
user: jason
Using VirtualService you can do much more fun stuff for Traffic Management. Next time, we might delve into Istio’s Security or Observability core features.
Things such as A/B testing or canary releases are very easy to achieve with a service mesh like Istio. GCP’s ongoing support and propagation of Istio sounds promising, especially the Managed Istio. I’m definitely going to play more with Istio multicluster setup which allows you to have one central Istio control plane managing multiple k8s clusters! It seems to be a better replacement for Kubernetes federation.
Source:
https://dzone.com/articles/ab-testing-with-kubernetes-and-istio
https://istio.io/docs/examples/bookinfo/
https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/