Traffic Management of Istio inside a Kubernetes cluster

Istio, the famed service mesh for Kubernetes, offers a whole suite of capabilities for controlling and directing traffic within your microservice architectures. Traffic management in Istio is not just about routing API calls; it’s also a powerful tool for canary deployments, A/B testing, blue-green deployments, and more. In this guide, we dive deep into the various traffic management components that Istio provides, along with practical code snippet examples to help you leverage Istio’s full potential in your Kubernetes clusters.

Virtual Services

Virtual Services in Istio define a set of routing rules to control the traffic behavior to a particular destination. These rules can include routing traffic based on HTTP headers, request methods, or even source IP addresses.
When a request enters the service mesh, Istio’s Envoy sidecar proxies intercept it. Virtual Services come into play by instructing the Envoy on how to route the request based on the defined rules.

Let’s understand it with an example.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-vs
spec:
  gateways:
  - istio-system/istio-gateway
  hosts:
  - '*'
  http: 
  - match:
    - uri:
        prefix: /apps/frontend/
    rewrite:
      uri: /
    route:
    - destination:
        host: frontend-service
        port:
          number: 80
  - match:
    - uri:
        prefix: /apps/backend/
    rewrite:
      uri: /
    route:
    - destination:
        host: backend-service
        port:
          number: 9080

Let’s breakdown the above example –

gateways

This field specifies the gateways to which this VirtualService is applied. This example is associated with the istio-gateway in the istio-system namespace.
We will discuss more about it later on this page.

hosts field

The hosts section restricts the application of the routing rules to specific hostnames or domain names. In this case, the wildcard ‘*’ is used, indicating that it applies to all hosts. If you specify example.com as hosts, in that case this virtual service configuration will only apply to the traffic coming from example.com domain.
Suppose you have a service called my-service in the namespace my-namespace and you want to configure this VirtualService only for requests coming to the my-service services, then in the hosts field to ‘my-service.my-namespace.svc.cluster.local’.

Routing rules

http section contains the routing rules of the Virtual service for the specified hosts. A routing rule consists of the destination where you want the traffic to go after matching zero or more conditions. Conditions are typically based on URI paths, headers, or other attributes of the HTTP request.

In match section, we write the condition which will be applied to all the coming requests. In the above example, we wrote a condition based on the URI path under uri. prefix specifies URI path prefixes to match. In this example, /apps/frontend/ and /apps/backend/ are two prefixes for two different conditions.
rewrite specifies URI rewriting. In this case, it rewrites the URI to /. This can be useful for adjusting the path before routing the request.

Route Section

This defines the routes for the incoming request after matching the above requests. destination field specifies the destination service to which the traffic should be routed, this destination service is the actual Kubernetes service. host will be The destination service’s hostname (frontend-service or backend-service) and port will be the service’s port (port 80) to which traffic will go.
So, according to the above example, If a request comes in with the URI path /apps/frontend/some/resource, it matches the first uri condition (prefix: /apps/frontend/). The rewrite field then rewrites the URI to /, and the request is routed to the frontend-service service on port 80.

You can also distribute traffic by specifying how much percentage of traffic should go to one service and how much to others.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-vs
spec:
  hosts:
	- my-service
  http:
	- route:
    	- destination:
        	host: frontend-service
        	subset: v1
      	weight: 90
    	- destination:
        	host: frontend-service
        	subset: v2
      	weight: 10

Destination Rules

Destination Rules in Istio are a critical aspect of traffic management. These rules let you configure what happens to traffic after it has been routed to a service. When a service has multiple versions or subsets, Destination Rules allow for the application of specific traffic policies to each version or subset.
Destination Rules are applied to Envoy proxies, guiding them on how to manage traffic to and from a specific service. They can be used to set properties such as load-balancing policies, subsets, and connection pool settings.

Let’s create Destination rules that can work with our above virtual service. This example assumes you have two subsets (v1 and v2) for the frontend-service and backend-service:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: frontend-destination
spec:
  host: frontend-service
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

---

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: backend-destination
spec:
  host: backend-service
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

The first DestinationRule named frontend-destination is associated with the frontend-service. It defines subsets v1 and v2 for potential versioning or categorization.
The second DestinationRule named backend-destination is associated with the backend service. It also defines subsets v1 and v2.

These DestinationRule resources help define subsets for each service, and they can be useful when you want to implement traffic splitting or apply specific policies to different versions or categories of your services.

If your services have actual version labels (e.g., version: v1, version: v2), make sure that the labels specified in the DestinationRule match the labels applied to the pods of each version of the respective services.

Now you might get doubt that if I can do load balancing in Virtual Service itself then why do we need Destination rule?

Importance of DestinationRule Despite Load Balancing in VirtualService:

While it’s true that the VirtualService can handle simple load balancing with traffic splitting, the DestinationRule becomes crucial for more granular and specific traffic control at the subset level:

1. Fine-Grained Control: DestinationRule allows for fine-grained control over subsets of a service. This is valuable when you need specific traffic policies for distinct versions or segments of a service.
2. Subset-Based Policies: It enables you to define traffic management policies, circuit breakers, and outlier detection for each subset individually, which is especially important in microservices-based architectures with varying service versions.
3. Service Versioning: When dealing with multiple versions of a service, the DestinationRule allows you to define load balancing, reliability, and security settings tailored to each version without impacting the overall routing logic defined in the VirtualService.

Gateways

In an Istio service mesh within a Kubernetes cluster, Gateways are used to manage the traffic entering and exiting the mesh. They act as a point of ingress for HTTP, HTTPS, and TCP traffic into the mesh, and they provide a way to configure traffic routing rules, set up TLS termination, and define virtual hosts.

In practical terms, Gateways are the components that enable external traffic to interact with services within the mesh. They receive incoming external requests and route them to the appropriate destination service based on the defined configuration. Additionally, Gateways support traffic encryption and termination of TLS connections, adding a layer of security to the communication between external clients and services within the mesh.

Key features and use cases of Gateways include:

• Ingress Traffic Management: Gateways provide the means to define routing rules for incoming HTTP and HTTPS traffic, allowing for fine-grained control over how external requests are directed to services within the mesh.
• TLS Termination and Encryption: Gateways support TLS termination, enabling the decryption of incoming TLS-encrypted traffic at the edge of the mesh before routing it to the services. This allows for the internal communication within the mesh to be unencrypted while ensuring secure external communication.
• Virtual Host Configuration: Gateways allow for the configuration of virtual hosts, which enables routing based on the Host header in the incoming HTTP requests. This functionality is particularly useful when multiple domain names need to be routed to different services within the mesh.
• Gateways are primarily used to manage ingress traffic, but you can also configure egress gateways. An egress gateway lets you configure a dedicated exit node for the traffic leaving the mesh, letting you limit which services can or should access external networks,

Let’s see an example – 

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: my-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "example.com"

This gateway configuration lets HTTP traffic from example.com into the mesh on port 80 but doesn’t specify any routing for the traffic.

To specify routing and for the gateway to work as intended, you must also bind the gateway to a virtual service. You do this using the virtual service’s gateways field, as shown in the following example:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-vs
spec:
  gateways:
  - my-gateway
    hosts:
  - "example.com"

Istio’s traffic management capabilities provide fine-grained control over how traffic is routed, mirrored, and shifted within a Kubernetes environment. By leveraging Virtual Services, Destination Rules, traffic mirroring, and traffic shifting, Istio empowers users to implement sophisticated traffic management strategies with ease.

By understanding and utilizing these traffic management components, users can effectively manage, observe, and control traffic flows within their Kubernetes clusters, ensuring optimal performance, reliability, and security for their microservices architecture.

That’s all for now.
Thank you for reading!!

Stay tuned for more articles on Cloud and DevOps. Don’t forget to follow me for regular updates and insights.

Let’s Connect: LinkedIn