Dhanush Gowda Vidyaranya\n\nHi, everyone. Welcome to the Istio with Bookinfo Application session at DevOps Enterprise Summit. This is the technical overview session about Istio.\n\nJust a brief introduction about me. I'm part of the Cisco DevNet SRE team, with focus around cloud infrastructure management and automation for Cisco DevNet applications. I'm passionate about different tools and technologies like Terraform, Kubernetes, Git, Ansible, Docker, and Jenkins. I'm certified in AWS, Kubernetes, and Terraform.\n\nLet's get started and look into the agenda for today: what are microservices, an example microservice architecture, challenges of microservice architecture, Istio architecture, core features of Istio, traffic management, and demo.\n\n## What Are Microservices?\n\nMicroservices are an architectural approach to building applications: a single application composed of many loosely coupled and independently deployable smaller components or services. These services typically have their own technology stack, inclusive of database and data-management model, and communicate with one another over a combination of REST APIs, event streaming, and message brokers.\n\nLet's look into an example microservice architecture: the Bookinfo application. The application displays information about a book, similar to a single catalog entry of an online bookstore. The webpage displays information about the book, like book description, book details, book reviews, and book ratings as well.\n\nThis Bookinfo application is broken into four separate microservices. Product page calls the reviews and details microservices to bring up the page. The details microservice contains book information. The reviews microservice contains book reviews and also calls the ratings microservice. The ratings microservice contains book-ranking information and always accompanies book reviews.\n\nThere are three different versions of the reviews microservice. Version one doesn't call the ratings microservice. Version two calls the ratings microservice and prints each rating in one-to-five black stars. Version three calls the ratings microservice and prints each rating in one-to-five red stars.\n\nThis is a polyglot application. That means each microservice is written in different languages, like Python, Java, Ruby, and Node.js. This is a very good example to demonstrate Istio because of its multitude of services, languages, and different versions of the reviews microservice.\n\n## Challenges of Microservice Architecture\n\nLet's look into the challenges of microservice architecture. Each microservice has its own business logic. Product page handles the request, details handles the details, and reviews and ratings handle the reviews and ratings for the book.\n\nServices need to talk to each other. How do services know how to talk to each other? What are the endpoints of each microservice? All the service endpoints the product page talks to must be configured for the product page. If you add a new microservice, then you need to add the endpoint of that new microservice into all the microservices that need to talk to it. We have that as part of the application code.\n\nWhat about security? Usually, in a common environment, we'll have a firewall rule set up for the Kubernetes cluster, or some kind of proxy that receives the request first, so the cluster cannot be accessed directly. There is security around the cluster, but once the request gets inside the cluster, microservices talk to each other with an insecure protocol and can talk freely with any other microservice without any restrictions. From the security perspective, if an attacker gets inside the cluster, he can do anything with it.\n\nAdditional configuration is required for each application to secure the communication between the services.\n\nWhat about retry logic? In order to build a robust application, retry logic needs to be included in each microservice. If the microservices are not reachable, or if you lose connectivity for a while, it has to retry the connection. Developers need to include the retry logic in each service.\n\nWhat about metrics and tracing? We need to monitor how services are performing, what HTTP errors we're getting, how many requests we're sending or receiving, and how long the request is taking in order to identify the bottlenecks in the application. Developers need to include monitoring logic for Prometheus, and they need to include tracing libraries in order to collect tracing data, like Zipkin.\n\nThe team of developers for each microservice needs to include all this non-business logic in each application. Rather than working on the actual service or application logic, they'll be busy configuring the network logic. This adds complexity to the services rather than making them simple and lightweight.\n\nWouldn't it make sense to extract all this non-business logic out of the microservice into a small sidecar application, which handles the network logic and acts as a proxy? This small sidecar application is a third-party application, so cluster operators can configure it easily through an API. There is no need to include the sidecar proxy configuration in each application deployment YAML file, as the control plane in Istio injects the sidecar proxy in each microservice pod so the microservices can talk to each other.\n\nA network layer for service-to-service communication, consisting of a control plane and proxy, is nothing but a service mesh. Service mesh is a pattern, whereas Istio is an implementation. It overcomes all the challenges we have discussed without any changes to the application code of each microservice.\n\n## Istio Architecture\n\nLet's understand more about Istio. Imagine an empty Kubernetes cluster. We have an application deployed inside the cluster, so we have an app container running inside the pod. For the sake of discussion, let's imagine another app container running inside the pod as well.\n\nThe first thing we need to understand is something about Envoy. Envoy can be deployed into an existing application pod as a sidecar container. Envoy is a C++-based proxy which can be deployed as a sidecar container along with an application so that Istio can talk to it. We don't have to interact with Istio directly; instead, Envoy will do it for us. This kind of pattern, where we have an app running along with the sidecar container, is the sidecar pattern.\n\nThe next major component is Pilot. Pilot is the orchestrator, which instructs Envoy what needs to be done based on the configuration received from Galley.\n\nGalley is a configuration manager. Whatever configuration we apply into the Kubernetes cluster, Galley translates into a language that Istio can understand. Pilot picks it up and converts it into Envoy-based executions.\n\nCitadel helps with identifying and certificate-based authentication and authorization between the processes and their interactions. If two applications need to interact with each other, Citadel helps identify who has access to what and how applications need to interact with each other.\n\nThese three server-side components, Pilot, Galley, and Citadel, mark the control-plane components of Istio. The data-plane component consists of a sidecar container, which is running along with an application, and the data plane acts as a proxy between the application and the control plane.\n\nHow does the traffic come into the cluster? The traffic hits the Envoy proxies using ingress. If you have a load balancer set up, then it leverages the ingress controller. The ingress controllers allow the traffic to the service. From the service, it hits the pod. When the request comes to the pod, Envoy will proxy the request before it's transferred to the application so it can manage and control the request, and then redirect to the application once it has verified everything.\n\nIf the application needs to talk to another application or another pod within the same cluster, then Envoy talks to the next Envoy of the destination application. From there, it gets routed to the application. If the request needs to go to the external world, then it goes to the egress route.\n\n## Istio Core Features and Configuration\n\nCore features of Istio include secure service-to-service communication using TLS encryption, strong identity-based authentication and authorization, automatic metrics, logs, and traces for all traffic within the cluster including ingress and egress, fine-grained control of traffic behavior with rich routing rules, retries, failover, and fault injection, and automatic load balancing for HTTP and TCP traffic.\n\nWe can configure Istio using Kubernetes YAML files and custom resource definitions. A custom resource is an object that extends your Kubernetes API, or allows you to introduce your own API into the cluster so you can define your own kind, just like pod, deployment, and replica sets. Here, there is no need to learn an Istio-specific language.\n\nThese are the installation profiles available. We'll be using the demo configuration profile in our demo session.\n\nTraffic management API resources include Istio gateway, virtual service, and destination rules. Istio gateways are primarily used to manage ingress traffic, but we can also configure egress gateways. Istio provides preconfigured gateway proxy deployments: Istio ingress gateway and Istio egress gateway. These gateway configurations allow traffic from outside into the mesh, but they don't specify any routing from the gateway. For that, we need to define the Istio virtual service.\n\nAn Istio virtual service is one level higher than the Kubernetes service. A virtual service defines a set of routing rules to apply when the host is addressed. Each routing rule defines traffic of a specific protocol. If the traffic is matched, then it will be sent to the named destination service.\n\nDestination rule defines policies that apply to traffic intended for a service after routing has occurred. While virtual service matches a rule and evaluates a destination to route the traffic, destination rule defines the available subsets of each microservice to send the traffic.\n\nTraffic management lets us route traffic to a specific version. In order to route to one version only, we need to apply the virtual service that sets the default version of the microservice. Here we are routing traffic to just version one of each microservice.\n\nTraffic can be shifted from one version to another version. A common use case is to migrate traffic gradually from an older version to the new one. Here we are routing 50% of the traffic to version two and 50% of the traffic to version three of the reviews microservice.\n\nTraffic from a specific user can be routed to a specific microservice version. One use case is to route traffic for users from different browser agents like Mozilla, IE, and Safari to different versions of microservices. Here we are routing the traffic for user Jason to version two of the reviews microservice and the rest of all the traffic to version one.\n\nWe'll be visualizing our mesh using Kiali. Let's discuss more on Kiali in our demo session. Let's jump into the demo to install Istio, look at Bookinfo application deployment, visualize the mesh using Kiali, and traffic management.\n\n## Demo\n\nLet's start the demo session. I have Minikube set up. Minikube is a tool to run Kubernetes locally. Let's check the Minikube status. Minikube runs a single-node Kubernetes cluster. I'm on the latest version of Kubernetes. Let's download Istio. This downloads and extracts Istio automatically.\n\nLet's add the istioctl client to the path. Let's do some pre-installation check using this command. Istio is safe to install or upgrade here. Let's navigate to the directory that Istio has downloaded. We'll be using the sample files to deploy different manifests to demonstrate various Istio features.\n\nLet's install Istio. As I explained earlier, we'll be using the demo configuration profile. This demo configuration profile deploys Istio components like Istiod, Istio Ingress Gateway, and Istio Egress Gateway.\n\nLet's verify the installation. It checks 13 custom resource definitions and three Istio deployments. Istio is installed and verified successfully.\n\nNow we need to label the default namespace to instruct Istio to inject the Envoy sidecar proxies when we deploy the application. I can see the label istio-injection is enabled on the default namespace. Let's deploy the application. This deploys product page, reviews, ratings, and details microservices. Let's verify. This confirms that Istio is injecting Envoy sidecar proxies into each of the application pods.\n\nNow the application is deployed, but it's not accessible from outside. In order to make it accessible, we need to define the gateway. This gateway listens at port 80, and the selector here is Istio Ingress Gateway. We need to define the virtual service to route the request from the gateway. This virtual service has been bound to the gateway. Let's apply. Let's verify. Everything looks good so far.\n\nBefore we can use Istio to perform version routing, we need to define the available subsets of each microservice using destination rules. Now let's get the IP and the port to access the application. I can access the webpage. The webpage displays information about the book, like book description, book details, book reviews, and book ratings as well.\n\nIf I refresh, I can experience three different versions of the reviews microservice. Ratings with red stars is version three of the reviews microservice. Without any ratings is version one of the reviews microservice. Rating with black stars is version two of the reviews microservice.\n\nLet's visualize our mesh using Kiali. Let's install some add-ons for that. This deploys Prometheus, Kiali, Zipkin, tracing, and Grafana. Let's concentrate on Kiali for this session. Let's check the rollout status of Kiali. We're just waiting for deployment to finish. It has been successfully rolled out.\n\nIn order to access the Kiali dashboard, we need to convert this cluster-type service to the NodePort type so it opens up a specific port on the node. The service has been patched. Before accessing Kiali, let's generate some traffic to the product page using curl. Here, `-sS` is for silent; we're not bothered about the output here.\n\nLet's access the Kiali dashboard. I can access Kiali here. I can see the traffic in the last one minute. The refresh interval is 15 seconds. We can see different types like graph, applications, workloads, services, and Istio config. Let's jump into the graph section here.\n\nWe can select the default namespace and the versioned graph to see different versions of microservices. In the display, let's enable the traffic distribution and traffic animation to see how much percentage of traffic is distributing between each microservice.\n\nThis represents the traffic source, this represents the Istio Ingress Gateway, this represents the service, this represents the application, and the green edges indicate healthy connections. The curl command is visiting the Istio Ingress Gateway, which is sending the request to the product page. From the product page, the request is going to the details and reviews microservices. The product page is sending the request to all three different versions of the reviews microservice. That's the reason we experienced three different versions earlier.\n\nNow let's route all the traffic to version one. Here, we are routing the traffic to version one of each microservice: version one of product page, version one of reviews, version one of ratings, and version one of details microservices. Let's check the Kiali dashboard. It started increasing the traffic sent to version one and reducing the traffic sent to version two and version three. In a while, we'll see almost all the traffic going to version one, and it won't be sending any traffic to version two and version three.\n\nLet's access the web page. We are being served only from version one of the reviews microservice. We are not being served from version two or version three anymore. Now almost all the traffic is going to version one. It's not sending any traffic to version two or version three anymore.\n\nNow let's do some traffic shifting. Here we are routing 50% of the traffic to version two and 50% of the traffic to version three. Let's check the Kiali dashboard. It started sending the traffic to version two and version three. It reduces the traffic sent to version one. In a while, we'll be seeing almost 50% of the traffic between version two and version three.\n\nLet's access the web page. Rating with red stars is version three of reviews microservice, and rating with black stars is version two of reviews microservice. We are not being served from version one anymore. We're just being served from version two and version three. As we can see, it is equally distributing the traffic between version two and version three.\n\nNow let's do some user identity-based routing. Here we are routing the traffic for user Jason to version two, and the rest of all the traffic we are routing to version one. Now let's access the web application. Let's sign in as user Jason. Here, the HTTP header contains Jason. I can put some random password. User Jason is being served from version two of reviews microservice, rating with black stars. He is not being served from any other versions at all.\n\nLet's sign out and sign in as a different user. Users other than Jason are being served from version one of reviews microservice. Unless user Jason logs in, all other users are being served from version one. You can see on Kiali as well: the traffic from user Jason is going to version two, and the rest of all the traffic is going to version one.\n\nThat's it. That's all the demo I had for today. I hope you got a better understanding of how to get started with Istio. I really appreciate your time, and thank you so much.