Istio Virtual Service defines a set of traffic routing rules to apply when host is addressed. Each routing rule defines standards for the traffic of a specific protocol. If the traffic is matched, then it is sent to a named destination service defined in the registry.

The source of traffic can also be matched within a routing rule that allows routing to be customized for every specific client context.

The below example on Kubernetes routes all HTTP traffic by default to pods of the reviews service with the label “version: v1”. Additionally, HTTP requests with path starting with /wpcatalog/ or /consumercatalog/ will be rewritten to /newcatalog and sent to the pods with label “version: v2”.

2kind: VirtualService
4 name: reviews-route
6 hosts:
7 -
8 http:
9 - name: "reviews-v2-routes"
10 match:
11 - uri:
12 prefix: "/wpcatalog"
13 - uri:
14 prefix: "/consumercatalog"
15 rewrite:
16 uri: "/newcatalog"
17 route:
18 - destination:
19 host:
20 subset: v2
21 - name: "reviews-v1-route"
22 route:
23 - destination:
24 host:
25 subset: v1

Virtual Service Configuration Affecting Traffic Routing

A single Virtual Service can be used to describe all the traffic properties of the hosts, including those for multiple HTTP and TCP ports.


  • The application traffic created by hosts, clients, servers, and applications that use the network as a transport is contained in the physical network data plane (also known as the forwarding plane). As a result, data plane traffic should never have source or destination IP addresses that are assigned to network elements like routers and switches; instead, it should be originated from and delivered to end devices like PCs and servers. To forward data plane traffic as swiftly as possible, routers and switches use hardware chips called application-specific integrated circuits (ASICs). A forwarding information base is referenced by the physical networking data plane (FIB).
  • The destination hosts to which traffic is being sent it could be a DNS name with wildcard prefix or an IP address depending on the platform.


  • The names of gateways and sidecars that should apply all these routes. Gateways in other namespaces may be referred to by gateway namespace>/gateway name ; specifying a gateway with no namespace qualifier is the same as specifying the VirtualService’s namespace.


  • An ordered list of route rules for HTTP traffic. The HTTP routes will be applied to the platform service ports named ‘http-’/‘http2-’/‘grpc-*’, gateway ports with protocol HTTP/HTTP2/GRPC/ TLS-terminated-HTTPS and service entry ports using HTTP/HTTP2/GRPC protocols.
  • The first rule is matching an incoming request which is used.


  • An ordered list of all the routing rules for opaque TCP traffic. TCP routes will be applied to any of the port which is not a HTTP or TLS port.


  • Exporting a virtual service allows it to be used by the sidecars and the gateways defined in other namespaces.
  • If no namespaces are specified then the virtual service is exported to all namespaces by default.


A destination indicates that the network addressable service to which the request/connection will be sent. A DestinationRule defines policies that apply to traffic intended for a service after routing has occurred.

2kind: DestinationRule
4 name: reviews-destination
6 host:
7 subsets:
8 - name: v1
9 labels:
10 version: v1
11 - name: v2
12 labels:
13 version: v2

A version of the route destination is identified with a reference to a named service subset which should be declared in a corresponding DestinationRule.

Get started with MeshMap!

Explore and understand your infrastructure at a glance with our powerful visualizer tool. Gain insights, track dependencies, and optimize performance effortlessly.


Related Resources

Layer5, the cloud native management company

An empowerer of engineers, Layer5 helps you extract more value from your infrastructure. Creator and maintainer of cloud native standards. Maker of Meshery, the cloud native manager.