Book Image

Bootstrapping Service Mesh Implementations with Istio

By : Anand Rai
4 (1)
Book Image

Bootstrapping Service Mesh Implementations with Istio

4 (1)
By: Anand Rai

Overview of this book

Istio is a game-changer in managing connectivity and operational efficiency of microservices, but implementing and using it in applications can be challenging. This book will help you overcome these challenges and gain insights into Istio's features and functionality layer by layer with the help of easy-to-follow examples. It will let you focus on implementing and deploying Istio on the cloud and in production environments instead of dealing with the complexity of demo apps.  You'll learn the installation, architecture, and components of Istio Service Mesh, perform multi-cluster installation, and integrate legacy workloads deployed on virtual machines. As you advance, you'll understand how to secure microservices from threats, perform multi-cluster deployments on Kubernetes, use load balancing, monitor application traffic, implement service discovery and management, and much more. You’ll also explore other Service Mesh technologies such as Linkerd, Consul, Kuma, and Gloo Mesh. In addition to observing and operating Istio using Kiali, Prometheus, Grafana and Jaeger, you'll perform zero-trust security and reliable communication between distributed applications. After reading this book, you'll be equipped with the practical knowledge and skills needed to use and operate Istio effectively.
Table of Contents (19 chapters)
1
Part 1: The Fundamentals
5
Part 2: Istio in Practice
10
Part 3: Scaling, Extending,and Optimizing

Traffic routing and canary release

In the previous section, we went through some of the functionality of virtual services; in this section, let’s go through how you can distribute traffic to multiple destinations.

I’m assuming you have the envoy-dummy config map configured and the envoy Pod and service running as per the 01-envoy-proxy.yaml file. If not, follow the instructions in the previous section to get these configured.

In the following exercise, we will be creating another version of the envoydummy Pod called v2, which returns a different response than v1. We will deploy v2 alongside v1 and then configure traffic splitting between the two versions of the envoydummy Pods:

  1. Create another version of the envoy mock service but with a different message:
    direct_response:
                      status: 200
               ...