Hello, readers. This article talks about the Understanding of Virtual Services and Gateways in Istio Service Mesh.
So, let us begin! 😊
Importance of traffic management through Istio
Traffic management has always been a point of concern for various applications. Be it hosted across on-prem servers or over the cloud.
It is all about monitoring the behavior of traffic that enters the application right from the load balancer to the end service hosted on a VM or on a cloud infrastructure.
For the same, we did come across Istio as a Service Mesh product. With Istio, we can manage and control the entire flow of traffic to the end application in terms of API calls, or even some 3rd party services easily.
It not only manages the traffic and monitors it, but also makes the entire channel secure with various routing rules.
During this topic, we will be having a look at the below important Istio resources for traffic monitoring as well as traffic routing.
- Virtual Service
1. Virtual Service
With Virtual services, we can set up routing rules for the application to be routed to the external service or the end service accordingly.
These routing rules can be added for the prefix or exact child pages of the host URL to which the equivalent service can be reached at.
Thus, it enables us to decide the routing of the services to the end requirement within the service mesh.
These routing rules have a rule defined which corresponds to a specific destination/backend service based on the criteria (condition).
We can make use of these virtual service routing rules to partially deviate the traffic to different end services as per the request.
Have a look at the below Virtual Service-
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: demo-vs spec: hosts: - demo.example.com http: - match: - headers: end-user: exact: "/" route: - destination: host: demo.example.com subset: v2 - route: - destination: host: demo.example.com subset: v3
- The host represents the client accessible destination or the application URL to which we can apply the routing rules to deviate the traffic across various backend services. The hostname can be an IP address, DNS name, CNAME, or a FQDN (fully qualified domain name). We can also make use of ‘*’ wildcard entries to have a single routing rule defined for multiple services.
- We define the routing rules of the virtual service in the http section of the file. Here, we describe the matching condition to the present within the host applicant for it to be forwarded to the destination service.
- The match section can be used to define the end condition sufficing which the appropriate request prompts to.
- The route section defines the route to the proper or exact destination as the backend service. It also includes the destination section wherein we can specify the backend service to which the routing rules should point to.
Gateway comes before a virtual service as a section which basically decides what kind of traffic should enter the service mesh pointing to the end destination.
The data plane thus gets managed at this specific resource easily.
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: ext-host-gwy spec: servers: - port: number: 443 name: https protocol: HTTPS hosts: - demo.example.com tls: mode: SIMPLE credentialName: demo-tls-cert
- The Server section enables us to specify the section of the ports to which port it applies like HTTP, HTTPS, etc.
- We can also include re-directing a HTTP request to a HTTPS request through the gateway file.
- Every port type needs an equivalent host to which the request will be bound.
- Under the tls section, we can specify the TLS credentials
By this, we have reached the end of this topic. Feel free to comment below, in case you come across any questions.
For more such posts related to Kubernetes and Networking around it, Stay tuned with us.
Till then, Happy Learning!! 🙂