Virtual Service

Configuration affecting traffic routing. Here are a few terms useful to definein the context of traffic routing.

Service a unit of application behavior bound to a unique name in aservice 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 deploymentscenario, for a given service, there can be distinct subsets ofinstances running different variants of the application binary. Thesevariants are not necessarily different API versions. They could beiterative changes to the same service, deployed in differentenvironments (prod, staging, dev, etc.). Common scenarios where thisoccurs include A/B testing, canary rollouts, etc. The choice of aparticular version can be decided based on various criterion (headers,url, etc.) and/or by weights assigned to each version. Each service hasa 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 aservice.

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

A VirtualService defines a set of traffic routing rules to apply when a host isaddressed. Each routing rule defines matching criteria for traffic of a specificprotocol. 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 routingto be customized for specific client contexts.

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

  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. - 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 referenceto a named service subset which must be declared in a correspondingDestinationRule.

  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

CorsPolicy

Describes the Cross-Origin Resource Sharing (CORS) policy, for a givenservice. Refer to CORSfor further details about cross origin resource sharing. For example,the following rule restricts cross origin requests to those originatingfrom example.com domain using HTTP POST/GET, and sets theAccess-Control-Allow-Credentials header to false. In addition, it onlyexposes 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. allowOrigin:
  15. - example.com
  16. allowMethods:
  17. - POST
  18. - GET
  19. allowCredentials: false
  20. allowHeaders:
  21. - X-Foo-Bar
  22. maxAge: "24h"
FieldTypeDescriptionRequired
allowOriginstring[]The list of origins that are allowed to perform CORS requests. Thecontent will be serialized into the Access-Control-Allow-Originheader. Wildcard * will allow all origins.No
allowMethodsstring[]List of HTTP methods allowed to access the resource. The content willbe serialized into the Access-Control-Allow-Methods header.No
allowHeadersstring[]List of HTTP headers that can be used when requesting theresource. Serialized to Access-Control-Allow-Headers header.No
exposeHeadersstring[]A white list of HTTP headers that the browsers are allowed toaccess. Serialized into Access-Control-Expose-Headers header.No
maxAgeDurationSpecifies how long the results of a preflight request can becached. Translates to the Access-Control-Max-Age header.No
allowCredentialsBoolValueIndicates whether the caller is allowed to send the actual request(not the preflight) using credentials. Translates toAccess-Control-Allow-Credentials header.No

Destination

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

Note for Kubernetes users: When short names are used (e.g. “reviews”instead of “reviews.default.svc.cluster.local”), Istio will interpretthe short name based on the namespace of the rule, not the service. Arule in the “default” namespace containing a host “reviews will beinterpreted as “reviews.default.svc.cluster.local”, irrespective of theactual namespace associated with the reviews service. To avoid potentialmisconfigurations, it is recommended to always use fully qualifieddomain names over short names.

The following Kubernetes example routes all traffic by default to podsof the reviews service with label “version: v1” (i.e., subset v1), andsome 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

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

The following VirtualService sets a timeout of 5s for all calls toproductpage.prod.svc.cluster.local service in Kubernetes. Notice thatthere are no subsets defined in this rule. Istio will fetch allinstances of productpage.prod.svc.cluster.local service from the serviceregistry and populate the sidecar’s load balancing pool. Also, noticethat this rule is set in the istio-system namespace but uses the fullyqualified domain name of the productpage service,productpage.prod.svc.cluster.local. Therefore the rule’s namespace doesnot 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

To control routing for traffic bound to services outside the mesh, externalservices must first be added to Istio’s internal service registry using theServiceEntry resource. VirtualServices can then be defined to control trafficbound to these external services. For example, the following rules define aService 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. apiVersion: networking.istio.io/v1alpha3
  15. kind: VirtualService
  16. metadata:
  17. name: my-wiki-rule
  18. spec:
  19. hosts:
  20. - wikipedia.org
  21. http:
  22. - timeout: 5s
  23. route:
  24. - destination:
  25. host: wikipedia.org
FieldTypeDescriptionRequired
hoststringThe name of a service from the service registry. Servicenames are looked up from the platform’s service registry (e.g.,Kubernetes services, Consul services, etc.) and from the hostsdeclared by ServiceEntry. Traffic forwarded todestinations 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 interpretthe short name based on the namespace of the rule, not the service. Arule in the “default” namespace containing a host “reviews will beinterpreted as “reviews.default.svc.cluster.local”, irrespective ofthe actual namespace associated with the reviews service. To avoidpotential misconfigurations, it is recommended to always use fullyqualified domain names over short names.Yes
subsetstringThe name of a subset within the service. Applicable only to serviceswithin the mesh. The subset must be defined in a correspondingDestinationRule.No
portPortSelectorSpecifies the port on the host that is being addressed. If a serviceexposes only a single port it is not required to explicitly select theport.No

HTTPFaultInjection

HTTPFaultInjection can be used to specify one or more faults to injectwhile forwarding http requests to the destination specified in a route.Fault specification is part of a VirtualService rule. Faults includeaborting the Http request from downstream service, and/or delayingproxying of requests. A fault rule MUST HAVE delay or abort or both.

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

FieldTypeDescriptionRequired
delayDelayDelay requests before forwarding, emulating various failures such asnetwork issues, overloaded upstream service, etc.No
abortAbortAbort Http request attempts and return error codes back to downstreamservice, giving the impression that the upstream service is faulty.No

HTTPFaultInjection.Abort

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

  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. fault:
  14. abort:
  15. percentage:
  16. value: 0.1
  17. httpStatus: 400

The httpStatus field is used to indicate the HTTP status code toreturn to the caller. The optional percentage field can be used to onlyabort a certain percentage of requests. If not specified, all requests areaborted.

FieldTypeDescriptionRequired
httpStatusint32 (oneof)HTTP status code to use to abort the Http request.Yes
percentagePercentPercentage of requests to be aborted with the error code provided.No
percentint32Percentage of requests to be aborted with the error code provided (0-100).Use of integer percent value is deprecated. Use the double percentagefield instead.No

HTTPFaultInjection.Delay

Delay specification is used to inject latency into the requestforwarding path. The following example will introduce a 5 second delayin 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

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

FieldTypeDescriptionRequired
fixedDelayDuration (oneof)Add a fixed delay before forwarding the request. Format:1h/1m/1s/1ms. MUST be >=1ms.Yes
percentagePercentPercentage of requests on which the delay will be injected.No
percentint32Percentage of requests on which the delay will be injected (0-100).Use of integer percent value is deprecated. Use the double percentagefield instead.No

HTTPMatchRequest

HttpMatchRequest specifies a set of criterion to be met in order for therule to be applied to the HTTP request. For example, the followingrestricts the rule to match only requests where the URL pathstarts with /ratings/v2/ and the request contains a custom end-user headerwith 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

HTTPMatchRequest CANNOT be empty.

FieldTypeDescriptionRequired
namestringThe name assigned to a match. The match’s name will beconcatenated with the parent route’s name and will be logged inthe access logs for requests matching this route.No
uriStringMatchURI to matchvalues 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 matchNote: Case-insensitive matching could be enabled via theignoreuri_case flag.No
schemeStringMatchURI Schemevalues 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 matchNo
methodStringMatchHTTP Methodvalues 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 matchNo
authorityStringMatchHTTP Authorityvalues 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 matchNo
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 matchNote: The keys uri, scheme, method, and authority will be ignored.No
portuint32Specifies the ports on the host that is being addressed. Many servicesonly 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 toworkloads with the given labels. If the VirtualService has a list ofgateways specified at the top, it must include the reserved gatewaymesh for this field to be applicable.No
queryParamsmap<string, StringMatch>Query parameters for matching.Ex:- For a query parameter like “?key=true”, the map key would be “key” andthe string match could be defined as exact: "true".- For a query parameter like “?key”, the map key would be “key” and thestring match could be defined as exact: "".- For a query parameter like “?key=123”, the map key would be “key” and thestring match could be defined as regex: "\d+$". Note that thisconfiguration will only match values like “123” but not “a123” or “123a”.Note: prefix matching is currently not supported.No
ignoreUriCaseboolFlag to specify whether the URI matching should be case-insensitive.Note: The case will be ignored only in the case of exact and prefixURI matches.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 withthe specified values. For example, the following rule redirectsrequests 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. ...
FieldTypeDescriptionRequired
uristringOn a redirect, overwrite the Path portion of the URL with thisvalue. Note that the entire path will be replaced, irrespective of therequest URI being matched as an exact path or prefix.No
authoritystringOn a redirect, overwrite the Authority/Host portion of the URL withthis value.No
redirectCodeuint32On a redirect, Specifies the HTTP status code to use in the redirectresponse. The default response code is MOVED_PERMANENTLY (301).No

HTTPRetry

Describes the retry policy to use when a HTTP request fails. Forexample, the following rule sets the maximum number of retries to 3 whencalling 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
FieldTypeDescriptionRequired
attemptsint32Number of retries for a given request. The intervalbetween retries will be determined automatically (25ms+). Actualnumber of retries attempted depends on the httpReqTimeout.Yes
perTryTimeoutDurationTimeout per retry attempt for a given request. format: 1h/1m/1s/1ms. MUST BE >=1ms.No
retryOnstringSpecifies the conditions under which retry takes place.One or more policies can be specified using a ‘,’ delimited list.See the retry policiesand gRPC retry policies for more details.No

HTTPRewrite

HTTPRewrite can be used to rewrite specific parts of a HTTP requestbefore forwarding the request to the destination. Rewrite primitive canbe used only with HTTPRouteDestination. The following exampledemonstrates how to rewrite the URL prefix for api call (/ratings) toratings 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
FieldTypeDescriptionRequired
uristringrewrite the path (or the prefix) portion of the URI with thisvalue. If the original URI was matched based on prefix, the valueprovided in this field will replace the corresponding matched prefix.No
authoritystringrewrite the Authority/Host header with this value.No

HTTPRoute

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

FieldTypeDescriptionRequired
namestringThe name assigned to the route for debugging purposes. Theroute’s name will be concatenated with the match’s name and willbe logged in the access logs for requests matching thisroute/match.No
matchHTTPMatchRequest[]Match conditions to be satisfied for the rule to beactivated. All conditions inside a single match block have ANDsemantics, while the list of match blocks have OR semantics. The ruleis matched if any one of the match blocks succeed.No
routeHTTPRouteDestination[]A http rule can either redirect or forward (default) traffic. Theforwarding target can be one of several versions of a service (seeglossary in beginning of document). Weights associated with theservice version determine the proportion of traffic it receives.No
redirectHTTPRedirectA http rule can either redirect or forward (default) traffic. Iftraffic passthrough option is specified in the rule,route/redirect will be ignored. The redirect primitive can be used tosend a HTTP 301 redirect to a different URI or Authority.No
rewriteHTTPRewriteRewrite HTTP URIs and Authority headers. Rewrite cannot be used withRedirect primitive. Rewrite will be performed before forwarding.No
timeoutDurationTimeout for HTTP requests.No
retriesHTTPRetryRetry policy for HTTP requests.No
faultHTTPFaultInjectionFault injection policy to apply on HTTP traffic at the client side.Note that timeouts or retries will not be enabled when faults areenabled on the client side.No
mirrorDestinationMirror HTTP traffic to a another destination in addition to forwardingthe requests to the intended destination. Mirrored traffic is on abest effort basis where the sidecar/gateway will not wait for themirrored cluster to respond before returning the response from theoriginal destination. Statistics will be generated for the mirroreddestination.No
mirrorPercentUInt32ValuePercentage 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
corsPolicyCorsPolicyCross-Origin Resource Sharing policy (CORS). Refer toCORSfor further details about cross origin resource sharing.No
headersHeadersHeader manipulation rulesNo

HTTPRouteDestination

Each routing rule is associated with one or more service versions (seeglossary in beginning of document). Weights associated with the versiondetermine the proportion of traffic it receives. For example, thefollowing rule will route 25% of traffic for the “reviews” service toinstances 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

And the associated 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

Traffic can also be split across two entirely different services withouthaving to define new subsets. For example, the following rule forwards 25% oftraffic 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
FieldTypeDescriptionRequired
destinationDestinationDestination uniquely identifies the instances of a serviceto which the request/connection should be forwarded to.Yes
weightint32The proportion of traffic to be forwarded to the serviceversion. (0-100). Sum of weights across destinations SHOULD BE == 100.If there is only one destination in a rule, the weight value is assumed tobe 100.No
headersHeadersHeader manipulation rulesNo
removeResponseHeadersstring[]Use of remove_response_header is deprecated. Use the headersfield instead.No
appendResponseHeadersmap<string, string>Use of append_response_headers is deprecated. Use the headersfield instead.No
removeRequestHeadersstring[]Use of remove_request_headers is deprecated. Use the headersfield instead.No
appendRequestHeadersmap<string, string>Use of append_request_headers is deprecated. Use the headersfield instead.No

Headers

Message headers can be manipulated when Envoy forwards requests to,or responses from, a destination service. Header manipulation rules canbe specified for a specific route destination or for all destinations.The following VirtualService adds a test header with the value trueto requests that are routed to any reviews service destination.It also romoves the foo response header, but only from responsescoming from the v1 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
FieldTypeDescriptionRequired
requestHeaderOperationsHeader manipulation rules to apply before forwarding a requestto the destination serviceNo
responseHeaderOperationsHeader manipulation rules to apply before returning a responseto the callerNo

Headers.HeaderOperations

HeaderOperations Describes the header manipulations to apply

FieldTypeDescriptionRequired
setmap<string, string>Overwrite the headers specified by key with the given valuesNo
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 headersNo

L4MatchAttributes

L4 connection match attributes. Note that L4 connection matching supportis incomplete.

FieldTypeDescriptionRequired
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
portuint32Specifies the port on the host that is being addressed. Many servicesonly 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 toworkloads with the given labels. If the VirtualService has a list ofgateways specified at the top, it should include the reserved gatewaymesh in order for this field to be applicable.No
gatewaysstring[]Names of gateways where the rule should be applied to. Gateway namesat the top of the VirtualService (if any) are overridden. The gatewaymatch is independent of sourceLabels.No

Percent

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

FieldTypeDescriptionRequired
valuedoubleNo

PortSelector

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

FieldTypeDescriptionRequired
numberuint32Valid port numberNo

RouteDestination

L4 routing rule weighted destination.

FieldTypeDescriptionRequired
destinationDestinationDestination uniquely identifies the instances of a serviceto which the request/connection should be forwarded to.Yes
weightint32The proportion of traffic to be forwarded to the serviceversion. If there is only one destination in a rule, all traffic will berouted to it irrespective of the weight.No

StringMatch

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

FieldTypeDescriptionRequired
exactstring (oneof)exact string matchYes
prefixstring (oneof)prefix-based matchYes
regexstring (oneof)ECMAscript style regex-based matchYes

TCPRoute

Describes match conditions and actions for routing TCP traffic. Thefollowing routing rule forwards traffic arriving at port 27017 formongo.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
FieldTypeDescriptionRequired
matchL4MatchAttributes[]Match conditions to be satisfied for the rule to beactivated. All conditions inside a single match block have ANDsemantics, while the list of match blocks have OR semantics. The ruleis matched if any one of the match blocks succeed.No
routeRouteDestination[]The destination to which the connection should be forwarded to.No

TLSMatchAttributes

TLS connection match attributes.

FieldTypeDescriptionRequired
sniHostsstring[]SNI (server name indicator) to match on. Wildcard prefixescan be used in the SNI value, e.g., *.com will match foo.example.comas well as example.com. An SNI value must be a subset (i.e., fallwithin 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
portuint32Specifies the port on the host that is being addressed. Many servicesonly expose a single port or label ports with the protocols theysupport, in these cases it is not required to explicitly select theport.No
sourceLabelsmap<string, string>One or more labels that constrain the applicability of a rule toworkloads with the given labels. If the VirtualService has a list ofgateways specified at the top, it should include the reserved gatewaymesh in order for this field to be applicable.No
gatewaysstring[]Names of gateways where the rule should be applied to. Gateway namesat the top of the VirtualService (if any) are overridden. The gatewaymatch is independent of sourceLabels.No

TLSRoute

Describes match conditions and actions for routing unterminated TLStraffic (TLS/HTTPS) The following routing rule forwards unterminated TLStraffic arriving at port 443 of gateway called “mygateway” to internalservices 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
FieldTypeDescriptionRequired
matchTLSMatchAttributes[]Match conditions to be satisfied for the rule to beactivated. All conditions inside a single match block have ANDsemantics, while the list of match blocks have OR semantics. The ruleis matched if any one of the match blocks succeed.Yes
routeRouteDestination[]The destination to which the connection should be forwarded to.No

VirtualService

Configuration affecting traffic routing.

FieldTypeDescriptionRequired
hostsstring[]The destination hosts to which traffic is being sent. Couldbe a DNS name with wildcard prefix or an IP address. Depending on theplatform, short-names can also be used instead of a FQDN (i.e. has nodots in the name). In such a scenario, the FQDN of the host would bederived based on the underlying platform.A single VirtualService can be used to describe all the trafficproperties of the corresponding hosts, including those for multipleHTTP and TCP ports. Alternatively, the traffic properties of a hostcan be defined using more than one VirtualService, with certaincaveats. Refer to theOperations Guidefor details.Note for Kubernetes users: When short names are used (e.g. “reviews”instead of “reviews.default.svc.cluster.local”), Istio will interpretthe short name based on the namespace of the rule, not the service. Arule in the “default” namespace containing a host “reviews” will beinterpreted as “reviews.default.svc.cluster.local”, irrespective ofthe actual namespace associated with the reviews service. To avoidpotential misconfigurations, it is recommended to always use fullyqualified domain names over short names.The hosts field applies to both HTTP and TCP services. Service insidethe mesh, i.e., those found in the service registry, must always bereferred to using their alphanumeric names. IP addresses are allowedonly for services defined via the Gateway.Yes
gatewaysstring[]The names of gateways and sidecars that should apply these routes. Asingle VirtualService is used for sidecars inside the mesh as well asfor one or more gateways. The selection condition imposed by thisfield can be overridden using the source field in the match conditionsof protocol-specific routes. The reserved word mesh is used to implyall the sidecars in the mesh. When this field is omitted, the defaultgateway (mesh) will be used, which would apply the rule to allsidecars in the mesh. If a list of gateway names is provided, therules will apply only to the gateways. To apply the rules to bothgateways and sidecars, specify mesh as one of the gateway names.No
httpHTTPRoute[]An ordered list of route rules for HTTP traffic. HTTP routes will beapplied to platform service ports named ‘http-’/‘http2-’/‘grpc-’, gatewayports with protocol HTTP/HTTP2/GRPC/ TLS-terminated-HTTPS and serviceentry ports using HTTP/HTTP2/GRPC protocols. The first rule matchingan incoming request is used.No
tlsTLSRoute[]An ordered list of route rule for non-terminated TLS & HTTPStraffic. Routing is typically performed using the SNI value presentedby the ClientHello message. TLS routes will be applied to platformservice ports named ‘https-’, ‘tls-’, unterminated gateway ports usingHTTPS/TLS protocols (i.e. with “passthrough” TLS mode) and serviceentry ports using HTTPS/TLS protocols. The first rule matching anincoming request is used. NOTE: Traffic ‘https-’ or ‘tls-’ portswithout associated virtual service will be treated as opaque TCPtraffic.No
tcpTCPRoute[]An ordered list of route rules for opaque TCP traffic. TCP routes willbe applied to any port that is not a HTTP or TLS port. The first rulematching an incoming request is used.No
exportTostring[]A list of namespaces to which this virtual service is exported. Exporting avirtual service allows it to be used by sidecars and gateways defined inother namespaces. This feature provides a mechanism for service ownersand mesh administrators to control the visibility of virtual servicesacross namespace boundaries.If no namespaces are specified then the virtual service is exported to allnamespaces by default.The value “.” is reserved and defines an export to the same namespace thatthe virtual service is declared in. Similarly the value “” is reserved anddefines an export to all namespaces.NOTE: in the current release, the exportTo value is restricted to“.” or “*” (i.e., the current namespace or all namespaces).No

google.protobuf.UInt32Value

Wrapper message for uint32.

The JSON representation for UInt32Value is JSON number.

FieldTypeDescriptionRequired
valueuint32The uint32 value.No