Istio Services
In this tutorial, we are going to discuss about Istio services i.e., virtual services, destination rules and gateway. In the earlier tutorial, We had a quick understanding on the overview of different components available as a part of Istio and how the data plane and control plane are organized.
As a part of this particular architecture there is one another component called mixer that’s going to be there as a part of istiod and ingress and egress controller.
Basically ingress controller going to control how the traffic and what traffic can get into the cluster. Egress controller what traffic can go out of the cluster and what external systems can be accessed.
And we are yet to discuss more in detail about these components. That is Pilot, Mixer, Citadel and Galley. As and then We are discussing about the internal functionality of various components. We will be having a detailed discussion.
So now, I’m going to give more additional information about virtual services, destination rules and gateways. Don’t worry about the ingress controller and egress controller how to configure and other functionalities of it. We will be having a detailed discussion.
Core Services
Now, let us understand about these important services. That is virtual services, destination rules and gateway.
Normally what happens I will be having a ingress controller. That will be having rules on what traffic can get in and what resources can be accessed by the user. And I will be having the resources that is microservices running within the cluster.
Now, once if I have the Istio established as a developer, I can apply the rules over the control plane. Here these configurations will be controlled by the pilot and the developers they will be applying the rule using the YAML file.
So what type of rule they will be applying? They will be applying the rules like virtual services and gateway configuration.
Gateway
So within the gateway configuration, I’ll be having the rules like what traffic should be allowed by the ingress controller. So here you can very well differentiate I don’t need to make any change to the existing components like ingress controller or the microservices.
As a developer, I am going to create a configuration details on what should be allowed and what protocol, like HTTP and host. All such details I will be configuring it within the gateway configuration, the same way I will be having another configuration that is called virtual service.
Virtual Service
Basically Virtual Service is a logical service on what request should be routed to what micro service. Let’s assume I do have multiple Micro services. The end user doesn’t need to know what are all the micro services running behind the scene and all they need to do is they need to call the single ingress controller or the gateway. The virtual services will be routing the request to the right microservices.
So I will be having the configuration details on the request path and route details. This is going to provide us lots of advantages in terms of I may have different versions of micro service. Let’s take couple of use cases.
Use case 1
In use case 1, Let’s assume I do have 2 versions of microservices that is version 1 and version 2. I want to route only 20% of the request to version 1 and the remaining 80% to version 2 to generate a Canary deployment.
Without interfering with the user activity or making code change to the existing applications. I can create a virtual service and make change to it automatically the percentage of change in request can be applied quickly over the virtual service and the destination rules.
So here’s where I’ll be having the destination rules in terms of what request should land in what micro service. So using the destination rules, I can do the canary deployment in terms of a percentage of the request should get routed to a version of micro service and the remaining percentage of the request should get routed to another version of the micro service.
Use case 2
Sometimes I may have multiple microservices running say for example, micro service A and micro service B. I do not want this particular details to be exposed to the End-user or the existing users, all they will be doing it. They will continue to access how they were accessing the earlier monolithic application.
So And I want to separate the request to the right microservices when the user is accessing different url’s. Based on the suffix this particular decision will be done and the same rules will be available within the destination rules.
I am going to explain few of the concepts or features available within the Istio using the same book details, sample application and I will be deploying this Virtual services, destination rules and gateway configurations. That’s the reason we are having a quick overview on these 3 concepts.
Let’s go ahead and do few of these scenarios available within Istio. That should give us more clarity about these services. And you may be wondering, what is the job being done by this control plane i.e., the pilot.
All the change that we are making in the virtual service or in the gateway configuration that will be applied into the data plane to all the proxy using this particular control plane pilot.
Summary
So in a quick summary, we saw the overview of the virtual services, destination rules and gateways.