Traffic Management in Istio - A detailed Guide

Published on August 3, 2022

Safa Mulani

Traffic Management in Istio - A detailed Guide

While we believe that this content benefits our community, we have not yet thoroughly reviewed it. If you have any suggestions for improvements, please let us know by clicking the “report an issue“ button at the bottom of the tutorial.

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
  name: demo-vs
  - demo.vs.com
  - match:
    - headers:
          exact: /api
    - destination:
        host: /


  • 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
  name: demo-gtwy
    app: demo
  - port:
      number: 443
      name: https
      protocol: HTTPS
    - demo.vs.com
      mode: SIMPLE
      credentialName: demo-tls-cert


  • 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
  name: default
  namespace: default
  - hosts:
    - "./*"
    - "bookinfo/*"


  • 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.


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! :)

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.

Learn more about us

About the authors
Default avatar
Safa Mulani


Still looking for an answer?

Ask a questionSearch for more help

Was this helpful?

Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up

Join the Tech Talk
Success! Thank you! Please check your email for further details.

Please complete your information!

Featured on Community

Get our biweekly newsletter

Sign up for Infrastructure as a Newsletter.

Hollie's Hub for Good

Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.

Become a contributor

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

Welcome to the developer cloud

DigitalOcean makes it simple to launch in the cloud and scale up as you grow — whether you're running one virtual machine or ten thousand.

Learn more
DigitalOcean Cloud Control Panel