Traffic Management in Istio - A detailed Guide

Hello, readers! This article talks about Traffic Management in Istio with its resources as a detailed explanation.

So, let us begin!!

Also read: Installation of Istio in a Kubernetes Cluster

What is traffic management all about?

Traffic management refers to the management of the traffic generated as a part of the data/browsing transfer or API calls.

When we have an application set up over the on-premise server or cloud, the traffic is generated when that application tries certain API calls or calls to the services of other 3rd party entities or data transfer over the internet.

The data is a crucial and vulnerable aspect of any application and the infrastructure is the root of the setup. It is necessary to monitor the traffic over the internet over the secured infrastructure. This leads to better security and management of the services over the same platform/infrastructure.

Moving ahead, we will be having a look at Istio as the tool for traffic management in the upcoming section.

Istio as a Traffic management tool

Istio introduces us to traffic management through traffic routing rules offered by it. The application becomes more resilient to failure. Because all the monitoring of traffic that goes and comes to the application over the internet.

Istio configures an Envoy proxy as a sidecar to the application container. It monitors all the traffic that routes to and from the application pod for API calls/service engagement, etc.

By this, the underlying application service stays unaffected and the entire traffic monitoring is proxied through the Envoy sidecar for resilience and traffic management.

1. Istio needs to understand the endpoints of an application to monitor the traffic. Thus, it gets connected to the service discovery system internally for recognizing the services as well as the endpoints of an application.
2. So, when a network call hits the application, it gets routed through the Envoy proxy and then finally to the end service of the application. Thus, the sidecar completely renders and monitors the traffic of the application.
3. Istio makes use of a round-robin model to transfer the traffic or distribute the traffic across the load balancers set up within the infrastructure.

Istio traffic management resources

Having understood the working of Istio as a traffic management tool, let us know to explore the resources set by Istio.

1. Virtual Service

With a Virtual Service, we can define the traffic routing rules that can help during the application hitting the load balancer. We define rules and the equivalent matching protocols for the end service. If the rule matches the criteria, the traffic diverts to the end service.

Virtual service enables us to manage the traffic load easily by decoupling the service requests through the traffic routing rules. We can specify and maintain the behavior of traffic for multiple hostnames within the same Virtual Service configuration.

Let us now understand the below example of a Virtual Service configuration.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: demo-vs
spec:
  hosts:
  - demo.vs.com
  http:
  - match:
    - headers:
        end-user:
          exact: /api
    route:
    - destination:
        host: /

Explanation-

• The hosts entry includes the domain or CNAME of the application.
• We then cascade down through the http routing and configure the matching backend service to a particular host/destination.
• Under the match section comes the backend service configuration that will be invoked as soon as the host entry matches.
• The http section includes the routing rules that are redirected to the destination.
• As soon as the web traffic/request hits the Istio gateway, it looks for the entry of it’s CNAME/FQDN. Upon successful match, it then moves the traffic to the virtual service which routes it to the particular destination k8 service.

2. Gateway

With Gateway comes the flexibility to control and monitor the inbound as well as outbound traffic at a global (envoy) level. We can specify the kind of traffic (protocol/rules) we wish to let enter the Istio service mesh for further routing to the destination.

So, as soon as the application URL hits the load balancer, it searches for an equivalent gateway. As soon as it finds the entry, it allows the application host to enter the mesh.

Let us try to understand the working of a Gateway through the below example-

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: demo-gtwy
spec:
  selector:
    app: demo
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - demo.vs.com
    tls:
      mode: SIMPLE
      credentialName: demo-tls-cert

Explanation:

• As soon as the web traffic hits the load balancer, it gets routed to the Istio gateway. The gateway enables the traffic to enter the service mesh over the mention port (443 in this case).
• But, no traffic routing to the backend service happens in this stage.
• The gateway looks for the credibility of the CNAME through the TLS secret (credential).
• Once the gateway confirms and allows the traffic from the host in, the virtual service takes the lead and does the routing to the destination service.

3. Sidecars

With Sidecars, we can limit and manage the traffic reaching the Envoy proxies. In a generic manner, Istio configures an Envoy Proxy that accepts traffic on the ports associated with the Workload of the application. Placing a sidecar has the below advantages:

• We can filter and manage the protocols and ports that the Envoy should accept.
• We can also filter and restrict the Envoy proxy from reaching or forwarding traffic to certain set of services.
• It can allow/restrict traffic to the services within different namespaces.

Let us now try to understand the concept of Sidecars using the below example-

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
  namespace: default
spec:
  egress:
  - hosts:
    - "./*"
    - "bookinfo/*"

Explanation:

• With the above configuration, it applies a sidecar configuration to the default namespace.
• This configuration allows the external/egress traffic to reach to the backend services of default and bookinfo namespaces only.
• With this, it restricts the traffic routing/accessibility to other namespaces.

Conclusion

By this, we have approached the end of this topic. Feel free to comment below, in case you come across any questions.

For more such posts related to Kubernetes, Stay tuned with us.

Till then, Happy Learning! :)