Istio service mesh on Kubernetes

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.

Why use Istio?

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: 

• Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic.
• Fine-grained control of traffic behaviour with rich routing rules, retries, fail-overs and fault injection.
• A pluggable policy layer and configuration API supporting access controls, rate limits and quotas.
• Automatic metrics, logs and traces for all traffic within a cluster, including cluster ingress and egress.
• Secure service-to-service communication in a cluster with strong identity-based authentication and authorisation.

It is easy to add other functionalities to Istio, however, in its basic configuration it already supports a wide range of advanced deployment strategies. 

Demo time - A/B testing

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:

• productpage. The productpage microservice calls the details and reviews microservices to populate the page.
• details. The details microservice contains book information.
• reviews. The reviews microservice contains book reviews. It also calls the ratings microservice.
• ratings. The ratings microservice contains book ranking information that accompanies a book review.

There are 3 versions of the reviews microservice:

• Version v1 doesn’t call the ratings service.
• Version v2 calls the ratings service and displays each rating as 1 to 5 black stars.
• Version v3 calls the ratings service and displays each rating as 1 to 5 red stars.

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: 10

Refresh 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.

Conclusion

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/