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
A single Virtual Service can be used to describe all the traffic properties of the hosts, including those for multiple HTTP and TCP ports.
gateway namespace>/gateway name; specifying a gateway with no namespace qualifier is the same as specifying the VirtualService’s namespace.
‘http-’/‘http2-’/‘grpc-*’, gateway ports with protocol HTTP/HTTP2/GRPC/ TLS-terminated-HTTPSand service entry ports using HTTP/HTTP2/GRPC protocols.
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.
Design your deployments the way you want. Drag-and-drop your cloud native infrastructure using a pallete of thousands of versioned Kubernetes components. Say goodbye to YAML configurations. Have your cloud native deployments automatically diagrammed. Deployments configured and modeled in Designer mode, can be deployed into your environment and managed using Visualizer. Discover a catalog of best practice cloud native patterns