Virtual Service

    a unit of application behavior bound to a unique name in a service registry. Services consist of multiple network endpoints implemented by workload instances running on pods, containers, VMs etc.

    Service versions (a.k.a. subsets) - In a continuous deployment scenario, for a given service, there can be distinct subsets of instances running different variants of the application binary. These variants are not necessarily different API versions. They could be iterative changes to the same service, deployed in different environments (prod, staging, dev, etc.). Common scenarios where this occurs include A/B testing, canary rollouts, etc. The choice of a particular version can be decided based on various criterion (headers, url, etc.) and/or by weights assigned to each version. Each service has a default version consisting of all its instances.

    Source - A downstream client calling a service.

    Host - The address used by a client when attempting to connect to a service.

    Access model - Applications address only the destination service (Host) without knowledge of individual service versions (subsets). The actual choice of the version is determined by the proxy/sidecar, enabling the application code to decouple itself from the evolution of dependent services.

    A VirtualService defines a set of traffic routing rules to apply when a host is addressed. Each routing rule defines matching criteria for traffic of a specific protocol. If the traffic is matched, then it is sent to a named destination service (or subset/version of it) defined in the registry.

    The source of traffic can also be matched in a routing rule. This allows routing to be customized for specific client contexts.

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

    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: reviews-route
    5. spec:
    6. hosts:
    7. - reviews.prod.svc.cluster.local
    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: reviews.prod.svc.cluster.local
    20. subset: v2
    21. - name: "reviews-v1-route"
    22. route:
    23. - destination:
    24. host: reviews.prod.svc.cluster.local
    25. subset: v1

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

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: DestinationRule
    3. metadata:
    4. name: reviews-destination
    5. spec:
    6. host: reviews.prod.svc.cluster.local
    7. subsets:
    8. - name: v1
    9. labels:
    10. version: v1
    11. - name: v2
    12. labels:
    13. version: v2
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: DestinationRule
    3. metadata:
    4. name: reviews-destination
    5. spec:
    6. host: reviews.prod.svc.cluster.local
    7. subsets:
    8. - name: v1
    9. labels:
    10. version: v1
    11. - name: v2
    12. labels:
    13. version: v2

    Configuration affecting traffic routing.

    Destination

    Destination indicates the network addressable service to which the request/connection will be sent after processing a routing rule. The destination.host should unambiguously refer to a service in the service registry. Istio’s service registry is composed of all the services found in the platform’s service registry (e.g., Kubernetes services, Consul services), as well as services declared through the resource.

    Note for Kubernetes users: When short names are used (e.g. “reviews” instead of “reviews.default.svc.cluster.local”), Istio will interpret the short name based on the namespace of the rule, not the service. A rule in the “default” namespace containing a host “reviews will be interpreted as “reviews.default.svc.cluster.local”, irrespective of the actual namespace associated with the reviews service. To avoid potential misconfigurations, it is recommended to always use fully qualified domain names over short names.

    The following Kubernetes example routes all traffic by default to pods of the reviews service with label “version: v1” (i.e., subset v1), and some to subset v2, in a Kubernetes environment.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: reviews-route
    5. namespace: foo
    6. spec:
    7. hosts:
    8. - reviews # interpreted as reviews.foo.svc.cluster.local
    9. http:
    10. - match:
    11. - uri:
    12. prefix: "/wpcatalog"
    13. - uri:
    14. prefix: "/consumercatalog"
    15. rewrite:
    16. uri: "/newcatalog"
    17. route:
    18. - destination:
    19. host: reviews # interpreted as reviews.foo.svc.cluster.local
    20. subset: v2
    21. - route:
    22. - destination:
    23. host: reviews # interpreted as reviews.foo.svc.cluster.local
    24. subset: v1
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: reviews-route
    5. namespace: foo
    6. spec:
    7. hosts:
    8. - reviews # interpreted as reviews.foo.svc.cluster.local
    9. http:
    10. - match:
    11. - uri:
    12. prefix: "/wpcatalog"
    13. - uri:
    14. prefix: "/consumercatalog"
    15. rewrite:
    16. uri: "/newcatalog"
    17. route:
    18. - destination:
    19. host: reviews # interpreted as reviews.foo.svc.cluster.local
    20. subset: v2
    21. - route:
    22. - destination:
    23. host: reviews # interpreted as reviews.foo.svc.cluster.local
    24. subset: v1

    And the associated DestinationRule

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: DestinationRule
    3. metadata:
    4. name: reviews-destination
    5. namespace: foo
    6. spec:
    7. host: reviews # interpreted as reviews.foo.svc.cluster.local
    8. subsets:
    9. - name: v1
    10. labels:
    11. version: v1
    12. - name: v2
    13. labels:
    14. version: v2
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: DestinationRule
    3. metadata:
    4. name: reviews-destination
    5. namespace: foo
    6. spec:
    7. host: reviews # interpreted as reviews.foo.svc.cluster.local
    8. subsets:
    9. - name: v1
    10. labels:
    11. version: v1
    12. - name: v2
    13. labels:
    14. version: v2

    The following VirtualService sets a timeout of 5s for all calls to productpage.prod.svc.cluster.local service in Kubernetes. Notice that there are no subsets defined in this rule. Istio will fetch all instances of productpage.prod.svc.cluster.local service from the service registry and populate the sidecar’s load balancing pool. Also, notice that this rule is set in the istio-system namespace but uses the fully qualified domain name of the productpage service, productpage.prod.svc.cluster.local. Therefore the rule’s namespace does not have an impact in resolving the name of the productpage service.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: my-productpage-rule
    5. namespace: istio-system
    6. spec:
    7. hosts:
    8. - productpage.prod.svc.cluster.local # ignores rule namespace
    9. http:
    10. - timeout: 5s
    11. route:
    12. - destination:
    13. host: productpage.prod.svc.cluster.local
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: my-productpage-rule
    5. namespace: istio-system
    6. spec:
    7. hosts:
    8. - productpage.prod.svc.cluster.local # ignores rule namespace
    9. http:
    10. - timeout: 5s
    11. route:
    12. - destination:
    13. host: productpage.prod.svc.cluster.local

    To control routing for traffic bound to services outside the mesh, external services must first be added to Istio’s internal service registry using the ServiceEntry resource. VirtualServices can then be defined to control traffic bound to these external services. For example, the following rules define a Service for wikipedia.org and set a timeout of 5s for HTTP requests.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: ServiceEntry
    3. metadata:
    4. name: external-svc-wikipedia
    5. spec:
    6. hosts:
    7. - wikipedia.org
    8. location: MESH_EXTERNAL
    9. ports:
    10. - number: 80
    11. name: example-http
    12. protocol: HTTP
    13. resolution: DNS
    14. ---
    15. apiVersion: networking.istio.io/v1alpha3
    16. kind: VirtualService
    17. metadata:
    18. name: my-wiki-rule
    19. spec:
    20. hosts:
    21. - wikipedia.org
    22. http:
    23. - timeout: 5s
    24. route:
    25. - destination:
    26. host: wikipedia.org
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: ServiceEntry
    3. metadata:
    4. name: external-svc-wikipedia
    5. spec:
    6. hosts:
    7. - wikipedia.org
    8. location: MESH_EXTERNAL
    9. ports:
    10. - number: 80
    11. name: example-http
    12. protocol: HTTP
    13. resolution: DNS
    14. ---
    15. apiVersion: networking.istio.io/v1alpha3
    16. kind: VirtualService
    17. metadata:
    18. name: my-wiki-rule
    19. spec:
    20. hosts:
    21. - wikipedia.org
    22. http:
    23. - timeout: 5s
    24. route:
    25. - destination:
    26. host: wikipedia.org
    FieldTypeDescriptionRequired
    hoststring

    The name of a service from the service registry. Service names are looked up from the platform’s service registry (e.g., Kubernetes services, Consul services, etc.) and from the hosts declared by ServiceEntry. Traffic forwarded to destinations that are not found in either of the two, will be dropped.

    Note for Kubernetes users: When short names are used (e.g. “reviews” instead of “reviews.default.svc.cluster.local”), Istio will interpret the short name based on the namespace of the rule, not the service. A rule in the “default” namespace containing a host “reviews will be interpreted as “reviews.default.svc.cluster.local”, irrespective of the actual namespace associated with the reviews service. To avoid potential misconfiguration, it is recommended to always use fully qualified domain names over short names.

    Yes
    subsetstring

    The name of a subset within the service. Applicable only to services within the mesh. The subset must be defined in a corresponding DestinationRule.

    No
    port

    Specifies the port on the host that is being addressed. If a service exposes only a single port it is not required to explicitly select the port.

    No

    HTTPRoute

    Describes match conditions and actions for routing HTTP/1.1, HTTP2, and gRPC traffic. See VirtualService for usage examples.

    FieldTypeDescriptionRequired
    namestring

    The name assigned to the route for debugging purposes. The route’s name will be concatenated with the match’s name and will be logged in the access logs for requests matching this route/match.

    No
    matchHTTPMatchRequest[]

    Match conditions to be satisfied for the rule to be activated. All conditions inside a single match block have AND semantics, while the list of match blocks have OR semantics. The rule is matched if any one of the match blocks succeed.

    No
    route

    A HTTP rule can either redirect or forward (default) traffic. The forwarding target can be one of several versions of a service (see glossary in beginning of document). Weights associated with the service version determine the proportion of traffic it receives.

    No
    redirectHTTPRedirect

    A HTTP rule can either redirect or forward (default) traffic. If traffic passthrough option is specified in the rule, route/redirect will be ignored. The redirect primitive can be used to send a HTTP 301 redirect to a different URI or Authority.

    No
    delegate

    Delegate is used to specify the particular VirtualService which can be used to define delegate HTTPRoute.

    It can be set only when Route and Redirect are empty, and the route rules of the delegate VirtualService will be merged with that in the current one.

    NOTE:

    1. Only one level delegation is supported.
    2. The delegate’s HTTPMatchRequest must be a strict subset of the root’s, otherwise there is a conflict and the HTTPRoute will not take effect.
    No
    rewriteHTTPRewrite

    Rewrite HTTP URIs and Authority headers. Rewrite cannot be used with Redirect primitive. Rewrite will be performed before forwarding.

    No
    timeout

    Timeout for HTTP requests, default is disabled.

    No
    retriesHTTPRetry

    Retry policy for HTTP requests.

    No
    fault

    Fault injection policy to apply on HTTP traffic at the client side. Note that timeouts or retries will not be enabled when faults are enabled on the client side.

    No
    mirrorDestination

    Mirror HTTP traffic to a another destination in addition to forwarding the requests to the intended destination. Mirrored traffic is on a best effort basis where the sidecar/gateway will not wait for the mirrored cluster to respond before returning the response from the original destination. Statistics will be generated for the mirrored destination.

    No
    mirrorPercentage

    Percentage of the traffic to be mirrored by the mirror field. If this field is absent, all the traffic (100%) will be mirrored. Max value is 100.

    No
    corsPolicyCorsPolicy

    Cross-Origin Resource Sharing policy (CORS). Refer to for further details about cross origin resource sharing.

    No
    headersHeaders

    Header manipulation rules

    No
    mirrorPercent

    Percentage of the traffic to be mirrored by the mirror field. Use of integer mirror_percent value is deprecated. Use the double mirror_percentage field instead

    No

    Delegate

    Describes the delegate VirtualService. The following routing rules forward the traffic to /productpage by a delegate VirtualService named productpage, forward the traffic to /reviews by a delegate VirtualService named reviews.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: bookinfo
    5. spec:
    6. hosts:
    7. - "bookinfo.com"
    8. gateways:
    9. http:
    10. - match:
    11. - uri:
    12. prefix: "/productpage"
    13. delegate:
    14. name: productpage
    15. namespace: nsA
    16. - match:
    17. - uri:
    18. prefix: "/reviews"
    19. delegate:
    20. name: reviews
    21. namespace: nsB
    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: reviews
    5. namespace: nsB
    6. spec:
    7. http:
    8. - route:
    9. - destination:
    10. host: reviews.nsB.svc.cluster.local
    FieldTypeDescriptionRequired
    namestring

    Name specifies the name of the delegate VirtualService.

    No
    namespacestring

    Namespace specifies the namespace where the delegate VirtualService resides. By default, it is same to the root’s.

    No

    Headers

    Message headers can be manipulated when Envoy forwards requests to, or responses from, a destination service. Header manipulation rules can be specified for a specific route destination or for all destinations. The following VirtualService adds a test header with the value true to requests that are routed to any reviews service destination. It also removes the foo response header, but only from responses coming from the subset (version) of the reviews service.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: reviews-route
    5. spec:
    6. hosts:
    7. - reviews.prod.svc.cluster.local
    8. http:
    9. - headers:
    10. request:
    11. set:
    12. test: "true"
    13. route:
    14. - destination:
    15. host: reviews.prod.svc.cluster.local
    16. subset: v2
    17. weight: 25
    18. - destination:
    19. host: reviews.prod.svc.cluster.local
    20. subset: v1
    21. headers:
    22. response:
    23. remove:
    24. - foo
    25. weight: 75
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: reviews-route
    5. spec:
    6. hosts:
    7. - reviews.prod.svc.cluster.local
    8. http:
    9. - headers:
    10. request:
    11. set:
    12. test: "true"
    13. route:
    14. - destination:
    15. host: reviews.prod.svc.cluster.local
    16. subset: v2
    17. weight: 25
    18. - destination:
    19. host: reviews.prod.svc.cluster.local
    20. subset: v1
    21. headers:
    22. response:
    23. remove:
    24. - foo
    25. weight: 75
    FieldTypeDescriptionRequired
    requestHeaderOperations

    Header manipulation rules to apply before forwarding a request to the destination service

    No
    responseNo

    TLSRoute

    Describes match conditions and actions for routing unterminated TLS traffic (TLS/HTTPS) The following routing rule forwards unterminated TLS traffic arriving at port 443 of gateway called “mygateway” to internal services in the mesh based on the SNI value.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: bookinfo-sni
    5. spec:
    6. hosts:
    7. - "*.bookinfo.com"
    8. gateways:
    9. - mygateway
    10. tls:
    11. - match:
    12. - port: 443
    13. sniHosts:
    14. - login.bookinfo.com
    15. route:
    16. - destination:
    17. host: login.prod.svc.cluster.local
    18. - match:
    19. - port: 443
    20. sniHosts:
    21. - reviews.bookinfo.com
    22. route:
    23. - destination:
    24. host: reviews.prod.svc.cluster.local
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: bookinfo-sni
    5. spec:
    6. hosts:
    7. - "*.bookinfo.com"
    8. gateways:
    9. - mygateway
    10. tls:
    11. - match:
    12. - port: 443
    13. sniHosts:
    14. - login.bookinfo.com
    15. route:
    16. - destination:
    17. host: login.prod.svc.cluster.local
    18. - match:
    19. - port: 443
    20. sniHosts:
    21. - reviews.bookinfo.com
    22. route:
    23. - destination:
    24. host: reviews.prod.svc.cluster.local
    FieldTypeDescriptionRequired
    matchTLSMatchAttributes[]

    Match conditions to be satisfied for the rule to be activated. All conditions inside a single match block have AND semantics, while the list of match blocks have OR semantics. The rule is matched if any one of the match blocks succeed.

    Yes
    route

    The destination to which the connection should be forwarded to.

    No

    TCPRoute

    Describes match conditions and actions for routing TCP traffic. The following routing rule forwards traffic arriving at port 27017 for mongo.prod.svc.cluster.local to another Mongo server on port 5555.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: bookinfo-mongo
    5. spec:
    6. hosts:
    7. - mongo.prod.svc.cluster.local
    8. tcp:
    9. - match:
    10. - port: 27017
    11. route:
    12. - destination:
    13. host: mongo.backup.svc.cluster.local
    14. port:
    15. number: 5555
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: bookinfo-mongo
    5. spec:
    6. hosts:
    7. - mongo.prod.svc.cluster.local
    8. tcp:
    9. - match:
    10. - port: 27017
    11. route:
    12. - destination:
    13. host: mongo.backup.svc.cluster.local
    14. port:
    15. number: 5555
    FieldTypeDescriptionRequired
    matchL4MatchAttributes[]

    Match conditions to be satisfied for the rule to be activated. All conditions inside a single match block have AND semantics, while the list of match blocks have OR semantics. The rule is matched if any one of the match blocks succeed.

    No
    route

    The destination to which the connection should be forwarded to.

    No

    HTTPMatchRequest

    HttpMatchRequest specifies a set of criterion to be met in order for the rule to be applied to the HTTP request. For example, the following restricts the rule to match only requests where the URL path starts with /ratings/v2/ and the request contains a custom end-user header with value jason.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: ratings-route
    5. spec:
    6. hosts:
    7. - ratings.prod.svc.cluster.local
    8. http:
    9. - match:
    10. - headers:
    11. end-user:
    12. exact: jason
    13. uri:
    14. prefix: "/ratings/v2/"
    15. ignoreUriCase: true
    16. route:
    17. - destination:
    18. host: ratings.prod.svc.cluster.local
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: ratings-route
    5. spec:
    6. hosts:
    7. - ratings.prod.svc.cluster.local
    8. http:
    9. - match:
    10. - headers:
    11. end-user:
    12. exact: jason
    13. uri:
    14. prefix: "/ratings/v2/"
    15. ignoreUriCase: true
    16. route:
    17. - destination:
    18. host: ratings.prod.svc.cluster.local

    HTTPMatchRequest CANNOT be empty. Note: No regex string match can be set when delegate VirtualService is specified.

    FieldTypeDescriptionRequired
    namestring

    The name assigned to a match. The match’s name will be concatenated with the parent route’s name and will be logged in the access logs for requests matching this route.

    No
    uriStringMatch

    URI to match values are case-sensitive and formatted as follows:

    • exact: “value” for exact string match

    • prefix: “value” for prefix-based match

    • regex: “value” for ECMAscript style regex-based match

    Note: Case-insensitive matching could be enabled via the ignore_uri_case flag.

    No
    scheme

    URI Scheme values are case-sensitive and formatted as follows:

    • exact: “value” for exact string match

    • prefix: “value” for prefix-based match

    • regex: “value” for ECMAscript style regex-based match

    No
    methodStringMatch

    HTTP Method values are case-sensitive and formatted as follows:

    • exact: “value” for exact string match

    • prefix: “value” for prefix-based match

    • regex: “value” for ECMAscript style regex-based match

    No
    authority

    HTTP Authority values are case-sensitive and formatted as follows:

    • exact: “value” for exact string match

    • prefix: “value” for prefix-based match

    • regex: “value” for ECMAscript style regex-based match

    No
    headersmap<string, StringMatch>

    The header keys must be lowercase and use hyphen as the separator, e.g. x-request-id.

    Header values are case-sensitive and formatted as follows:

    • exact: “value” for exact string match

    • prefix: “value” for prefix-based match

    • regex: “value” for ECMAscript style regex-based match

    If the value is empty and only the name of header is specfied, presence of the header is checked. Note: The keys uri, scheme, method, and authority will be ignored.

    No
    portuint32

    Specifies the ports on the host that is being addressed. Many services only expose a single port or label ports with the protocols they support, in these cases it is not required to explicitly select the port.

    No
    sourceLabelsmap<string, string>

    One or more labels that constrain the applicability of a rule to workloads with the given labels. If the VirtualService has a list of gateways specified in the top-level gateways field, it must include the reserved gateway mesh for this field to be applicable.

    No
    gatewaysstring[]

    Names of gateways where the rule should be applied. Gateway names in the top-level gateways field of the VirtualService (if any) are overridden. The gateway match is independent of sourceLabels.

    No
    queryParamsmap<string, >

    Query parameters for matching.

    Ex:

    • For a query parameter like “?key=true”, the map key would be “key” and the string match could be defined as exact: “true”.

    • For a query parameter like “?key”, the map key would be “key” and the string match could be defined as exact: “”.

    • For a query parameter like “?key=123”, the map key would be “key” and the string match could be defined as regex: “\d+$”. Note that this configuration will only match values like “123” but not “a123” or “123a”.

    Note: prefix matching is currently not supported.

    No
    ignoreUriCasebool

    Flag to specify whether the URI matching should be case-insensitive.

    Note: The case will be ignored only in the case of exact and prefix URI matches.

    No
    withoutHeadersmap<string, StringMatch>

    withoutHeader has the same syntax with the header, but has opposite meaning. If a header is matched with a matching rule among withoutHeader, the traffic becomes not matched one.

    No
    sourceNamespacestring

    Source namespace constraining the applicability of a rule to workloads in that namespace. If the VirtualService has a list of gateways specified in the top-level gateways field, it must include the reserved gateway mesh for this field to be applicable.

    No

    Each routing rule is associated with one or more service versions (see glossary in beginning of document). Weights associated with the version determine the proportion of traffic it receives. For example, the following rule will route 25% of traffic for the “reviews” service to instances with the “v2” tag and the remaining traffic (i.e., 75%) to “v1”.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: reviews-route
    5. spec:
    6. hosts:
    7. - reviews.prod.svc.cluster.local
    8. http:
    9. - route:
    10. - destination:
    11. host: reviews.prod.svc.cluster.local
    12. subset: v2
    13. weight: 25
    14. - destination:
    15. host: reviews.prod.svc.cluster.local
    16. subset: v1
    17. weight: 75
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: reviews-route
    5. spec:
    6. hosts:
    7. - reviews.prod.svc.cluster.local
    8. http:
    9. - route:
    10. - destination:
    11. host: reviews.prod.svc.cluster.local
    12. subset: v2
    13. weight: 25
    14. - destination:
    15. host: reviews.prod.svc.cluster.local
    16. subset: v1
    17. weight: 75

    And the associated DestinationRule

    1. kind: DestinationRule
    2. metadata:
    3. name: reviews-destination
    4. spec:
    5. host: reviews.prod.svc.cluster.local
    6. subsets:
    7. - name: v1
    8. labels:
    9. version: v1
    10. - name: v2
    11. labels:
    12. version: v2

    Traffic can also be split across two entirely different services without having to define new subsets. For example, the following rule forwards 25% of traffic to reviews.com to dev.reviews.com

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: reviews-route-two-domains
    5. spec:
    6. hosts:
    7. - reviews.com
    8. http:
    9. - route:
    10. - destination:
    11. host: dev.reviews.com
    12. weight: 25
    13. - destination:
    14. host: reviews.com
    15. weight: 75
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: reviews-route-two-domains
    5. spec:
    6. hosts:
    7. - reviews.com
    8. http:
    9. - route:
    10. - destination:
    11. host: dev.reviews.com
    12. weight: 25
    13. - destination:
    14. host: reviews.com

    RouteDestination

    L4 routing rule weighted destination.

    FieldTypeDescriptionRequired
    destination

    Destination uniquely identifies the instances of a service to which the request/connection should be forwarded to.

    Yes
    weightint32

    The proportion of traffic to be forwarded to the service version. If there is only one destination in a rule, all traffic will be routed to it irrespective of the weight.

    No

    L4MatchAttributes

    L4 connection match attributes. Note that L4 connection matching support is incomplete.

    FieldTypeDescriptionRequired
    destinationSubnetsstring[]No
    portuint32

    Specifies the port on the host that is being addressed. Many services only expose a single port or label ports with the protocols they support, in these cases it is not required to explicitly select the port.

    No
    sourceLabelsmap<string, string>

    One or more labels that constrain the applicability of a rule to workloads with the given labels. If the VirtualService has a list of gateways specified in the top-level gateways field, it should include the reserved gateway mesh in order for this field to be applicable.

    No
    gatewaysstring[]

    Names of gateways where the rule should be applied. Gateway names in the top-level gateways field of the VirtualService (if any) are overridden. The gateway match is independent of sourceLabels.

    No
    sourceNamespacestring

    Source namespace constraining the applicability of a rule to workloads in that namespace. If the VirtualService has a list of gateways specified in the top-level gateways field, it must include the reserved gateway mesh for this field to be applicable.

    No

    TLSMatchAttributes

    TLS connection match attributes.

    FieldTypeDescriptionRequired
    sniHostsstring[]

    SNI (server name indicator) to match on. Wildcard prefixes can be used in the SNI value, e.g., *.com will match foo.example.com as well as example.com. An SNI value must be a subset (i.e., fall within the domain) of the corresponding virtual serivce’s hosts.

    Yes
    destinationSubnetsstring[]

    IPv4 or IPv6 ip addresses of destination with optional subnet. E.g., a.b.c.d/xx form or just a.b.c.d.

    No
    portuint32

    Specifies the port on the host that is being addressed. Many services only expose a single port or label ports with the protocols they support, in these cases it is not required to explicitly select the port.

    No
    sourceLabelsmap<string, string>

    One or more labels that constrain the applicability of a rule to workloads with the given labels. If the VirtualService has a list of gateways specified in the top-level gateways field, it should include the reserved gateway mesh in order for this field to be applicable.

    No
    gatewaysstring[]

    Names of gateways where the rule should be applied. Gateway names in the top-level gateways field of the VirtualService (if any) are overridden. The gateway match is independent of sourceLabels.

    No
    sourceNamespacestring

    Source namespace constraining the applicability of a rule to workloads in that namespace. If the VirtualService has a list of gateways specified in the top-level gateways field, it must include the reserved gateway mesh for this field to be applicable.

    No

    HTTPRedirect

    HTTPRedirect can be used to send a 301 redirect response to the caller, where the Authority/Host and the URI in the response can be swapped with the specified values. For example, the following rule redirects requests for /v1/getProductRatings API on the ratings service to /v1/bookRatings provided by the bookratings service.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: ratings-route
    5. spec:
    6. hosts:
    7. - ratings.prod.svc.cluster.local
    8. http:
    9. - match:
    10. - uri:
    11. exact: /v1/getProductRatings
    12. redirect:
    13. uri: /v1/bookRatings
    14. authority: newratings.default.svc.cluster.local
    15. ...
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: ratings-route
    5. spec:
    6. hosts:
    7. - ratings.prod.svc.cluster.local
    8. http:
    9. - match:
    10. - uri:
    11. exact: /v1/getProductRatings
    12. redirect:
    13. uri: /v1/bookRatings
    14. authority: newratings.default.svc.cluster.local
    15. ...
    FieldTypeDescriptionRequired
    uristring

    On a redirect, overwrite the Path portion of the URL with this value. Note that the entire path will be replaced, irrespective of the request URI being matched as an exact path or prefix.

    No
    authoritystring

    On a redirect, overwrite the Authority/Host portion of the URL with this value.

    No
    redirectCodeuint32

    On a redirect, Specifies the HTTP status code to use in the redirect response. The default response code is MOVED_PERMANENTLY (301).

    No

    HTTPRewrite

    HTTPRewrite can be used to rewrite specific parts of a HTTP request before forwarding the request to the destination. Rewrite primitive can be used only with HTTPRouteDestination. The following example demonstrates how to rewrite the URL prefix for api call (/ratings) to ratings service before making the actual API call.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: ratings-route
    5. spec:
    6. hosts:
    7. - ratings.prod.svc.cluster.local
    8. http:
    9. - match:
    10. - uri:
    11. prefix: /ratings
    12. rewrite:
    13. uri: /v1/bookRatings
    14. route:
    15. - destination:
    16. host: ratings.prod.svc.cluster.local
    17. subset: v1
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: ratings-route
    5. spec:
    6. hosts:
    7. - ratings.prod.svc.cluster.local
    8. http:
    9. - match:
    10. - uri:
    11. prefix: /ratings
    12. rewrite:
    13. uri: /v1/bookRatings
    14. route:
    15. - destination:
    16. host: ratings.prod.svc.cluster.local
    17. subset: v1
    FieldTypeDescriptionRequired
    uristring

    rewrite the path (or the prefix) portion of the URI with this value. If the original URI was matched based on prefix, the value provided in this field will replace the corresponding matched prefix.

    No
    authoritystring

    rewrite the Authority/Host header with this value.

    No

    StringMatch

    Describes how to match a given string in HTTP headers. Match is case-sensitive.

    FieldTypeDescriptionRequired
    exactstring (oneof)

    exact string match

    No
    prefixstring (oneof)

    prefix-based match

    No
    regexstring (oneof)

    RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).

    No

    HTTPRetry

    Describes the retry policy to use when a HTTP request fails. For example, the following rule sets the maximum number of retries to 3 when calling ratings:v1 service, with a 2s timeout per retry attempt.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: ratings-route
    5. spec:
    6. hosts:
    7. - ratings.prod.svc.cluster.local
    8. http:
    9. - route:
    10. - destination:
    11. host: ratings.prod.svc.cluster.local
    12. subset: v1
    13. retries:
    14. attempts: 3
    15. perTryTimeout: 2s
    16. retryOn: gateway-error,connect-failure,refused-stream
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: ratings-route
    5. spec:
    6. hosts:
    7. - ratings.prod.svc.cluster.local
    8. http:
    9. - route:
    10. - destination:
    11. host: ratings.prod.svc.cluster.local
    12. subset: v1
    13. retries:
    14. attempts: 3
    15. perTryTimeout: 2s
    16. retryOn: gateway-error,connect-failure,refused-stream
    FieldTypeDescriptionRequired
    attemptsint32

    Number of retries to be allowed for a given request. The interval between retries will be determined automatically (25ms+). When request timeout of the or per_try_timeout is configured, the actual number of retries attempted also depends on the specified request timeout and per_try_timeout values.

    Yes
    perTryTimeoutDuration

    Timeout per attempt for a given request, including the initial call and any retries. Format: 1h/1m/1s/1ms. MUST BE >=1ms. Default is same value as request timeout of the , which means no timeout.

    No
    retryOnstring

    Specifies the conditions under which retry takes place. One or more policies can be specified using a ‘,’ delimited list. See the retry policies and for more details.

    No
    retryRemoteLocalitiesBoolValue

    Flag to specify whether the retries should retry to other localities. See the for more details.

    No

    Describes the Cross-Origin Resource Sharing (CORS) policy, for a given service. Refer to CORS for further details about cross origin resource sharing. For example, the following rule restricts cross origin requests to those originating from example.com domain using HTTP POST/GET, and sets the Access-Control-Allow-Credentials header to false. In addition, it only exposes X-Foo-bar header and sets an expiry period of 1 day.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: ratings-route
    5. spec:
    6. hosts:
    7. - ratings.prod.svc.cluster.local
    8. http:
    9. - route:
    10. - destination:
    11. host: ratings.prod.svc.cluster.local
    12. subset: v1
    13. corsPolicy:
    14. allowOrigins:
    15. - exact: https://example.com
    16. allowMethods:
    17. - POST
    18. - GET
    19. allowCredentials: false
    20. allowHeaders:
    21. - X-Foo-Bar
    22. maxAge: "24h"
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: ratings-route
    5. spec:
    6. hosts:
    7. - ratings.prod.svc.cluster.local
    8. http:
    9. - route:
    10. - destination:
    11. host: ratings.prod.svc.cluster.local
    12. subset: v1
    13. corsPolicy:
    14. allowOrigins:
    15. - exact: https://example.com
    16. allowMethods:
    17. - POST
    18. - GET
    19. allowCredentials: false
    20. allowHeaders:
    21. - X-Foo-Bar
    22. maxAge: "24h"

    HTTPFaultInjection

    HTTPFaultInjection can be used to specify one or more faults to inject while forwarding HTTP requests to the destination specified in a route. Fault specification is part of a VirtualService rule. Faults include aborting the Http request from downstream service, and/or delaying proxying of requests. A fault rule MUST HAVE delay or abort or both.

    Note: Delay and abort faults are independent of one another, even if both are specified simultaneously.

    FieldTypeDescriptionRequired
    delay

    Delay requests before forwarding, emulating various failures such as network issues, overloaded upstream service, etc.

    No
    abortAbort

    Abort Http request attempts and return error codes back to downstream service, giving the impression that the upstream service is faulty.

    No

    PortSelector

    PortSelector specifies the number of a port to be used for matching or selection for final routing.

    FieldTypeDescriptionRequired
    numberuint32

    Valid port number

    No

    Percent

    Percent specifies a percentage in the range of [0.0, 100.0].

    FieldTypeDescriptionRequired
    valuedoubleNo

    Headers.HeaderOperations

    HeaderOperations Describes the header manipulations to apply

    FieldTypeDescriptionRequired
    setmap<string, string>

    Overwrite the headers specified by key with the given values

    No
    addmap<string, string>

    Append the given values to the headers specified by keys (will create a comma-separated list of values)

    No
    removestring[]

    Remove a the specified headers

    No

    HTTPFaultInjection.Delay

    Delay specification is used to inject latency into the request forwarding path. The following example will introduce a 5 second delay in 1 out of every 1000 requests to the “v1” version of the “reviews” service from all pods with label env: prod

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: reviews-route
    5. spec:
    6. hosts:
    7. - reviews.prod.svc.cluster.local
    8. http:
    9. - match:
    10. - sourceLabels:
    11. env: prod
    12. route:
    13. - destination:
    14. host: reviews.prod.svc.cluster.local
    15. subset: v1
    16. fault:
    17. delay:
    18. percentage:
    19. value: 0.1
    20. fixedDelay: 5s
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: reviews-route
    5. spec:
    6. hosts:
    7. - reviews.prod.svc.cluster.local
    8. http:
    9. - match:
    10. - sourceLabels:
    11. env: prod
    12. route:
    13. - destination:
    14. host: reviews.prod.svc.cluster.local
    15. subset: v1
    16. fault:
    17. delay:
    18. percentage:
    19. value: 0.1
    20. fixedDelay: 5s

    The fixedDelay field is used to indicate the amount of delay in seconds. The optional percentage field can be used to only delay a certain percentage of requests. If left unspecified, all request will be delayed.

    FieldTypeDescriptionRequired
    fixedDelay

    Add a fixed delay before forwarding the request. Format: 1h/1m/1s/1ms. MUST be >=1ms.

    Yes
    percentagePercent

    Percentage of requests on which the delay will be injected.

    No
    percentint32

    Percentage of requests on which the delay will be injected (0-100). Use of integer percent value is deprecated. Use the double percentage field instead.

    No

    HTTPFaultInjection.Abort

    Abort specification is used to prematurely abort a request with a pre-specified error code. The following example will return an HTTP 400 error code for 1 out of every 1000 requests to the “ratings” service “v1”.

    1. apiVersion: networking.istio.io/v1beta1
    2. kind: VirtualService
    3. metadata:
    4. name: ratings-route
    5. spec:
    6. hosts:
    7. - ratings.prod.svc.cluster.local
    8. http:
    9. - route:
    10. - destination:
    11. host: ratings.prod.svc.cluster.local
    12. subset: v1
    13. fault:
    14. abort:
    15. percentage:
    16. value: 0.1
    17. httpStatus: 400

    The httpStatus field is used to indicate the HTTP status code to return to the caller. The optional percentage field can be used to only abort a certain percentage of requests. If not specified, all requests are aborted.

    FieldTypeDescriptionRequired
    httpStatusint32 (oneof)

    HTTP status code to use to abort the Http request.

    Yes
    percentage

    Percentage of requests to be aborted with the error code provided.

    No

    google.protobuf.UInt32Value

    Wrapper message for uint32.

    FieldTypeDescriptionRequired
    uint32

    The uint32 value.

    No