Virtual service is an Istio configuration primitive that's created through a custom resource definition in Kubernetes. It dynamically defines how traffic destined for an internet domain name flows to a set of services inside the Kubernetes cluster, and this is all dynamic. This means that the traffic can stream to any service within the mesh based on certain rules.

The following virtual service forwards all traffic coming from the Ingress gateway to the productpage service in an istio-lab namespace. The virtual service binds to a specific gateway. Remember that the virtual service can be changed dynamically—this is the loose coupling between a gateway and a microservice:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
  - "*"
  gateways:
  - mygateway
  http:
  - match:
    - uri:
        prefix: /api/v1/products
    route:
    - destination:
        host: productpage.istio-lab.svc.cluster.local
        port:
          number: 9080

As per the preceding definition, the bookinfo virtual service routes the external HTTP traffic of port 80 (which is implicit for the HTTP protocol) to the internal productpage microservice at port 9080.

The virtual service is a way to create a hierarchy (top-down virtual services) to define the traffic to different services using a routing path. This allows each team to manage their own virtual service definitions instead of having one virtual service. For example, the top-level virtual service splits the traffic based upon a path to a logical set of services, and then each logical set can define a set of nested virtual services that are managed by separate teams to provide a decoupled architecture of defining virtual services.  

Traffic management capabilities such as routing rules, fault injection, and abort rules are all defined through virtual services. We'll look at these in the following subsections.