Istio Virtual Service
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”.
1apiVersion: networking.istio.io/v1alpha32kind: VirtualService3metadata:4 name: reviews-route5spec:6 hosts:7 - reviews.prod.svc.cluster.local8 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: reviews.prod.svc.cluster.local20 subset: v221 - name: "reviews-v1-route"22 route:23 - destination:24 host: reviews.prod.svc.cluster.local25 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.
Hosts
- 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.
Gateways
- 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.
HTTP
- 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-HTTPSand service entry ports using HTTP/HTTP2/GRPC protocols. - The first rule is matching an incoming request which is used.
TCP
- 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.
ExportTo
- 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.
Destination
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.
1apiVersion: networking.istio.io/v1alpha32kind: DestinationRule3metadata:4 name: reviews-destination5spec:6 host: reviews.prod.svc.cluster.local7 subsets:8 - name: v19 labels:10 version: v111 - name: v212 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.
