Virtual Service

String patterns that match allowed origins. An origin is allowed if any of the string matchers match. If a match is found, then the outgoing Access-Control-Allow-Origin would be set to the origin as provided by the client.

List of HTTP methods allowed to access the resource. The content will be serialized into the Access-Control-Allow-Methods header.

List of HTTP headers that can be used when requesting the resource. Serialized to Access-Control-Allow-Headers header.

A white list of HTTP headers that the browsers are allowed to access. Serialized into Access-Control-Expose-Headers header.

Specifies how long the results of a preflight request can be cached. Translates to the Access-Control-Max-Age header.

Indicates whether the caller is allowed to send the actual request (not the preflight) using credentials. Translates to Access-Control-Allow-Credentials header.

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.

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

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.

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

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

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

Percentage of requests on which the delay will be injected.

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.

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.

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

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

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

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

Note: The keys uri, scheme, method, and authority will be ignored.

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.

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.

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.

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.

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.

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.

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

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

Number of retries for a given request. The interval between retries will be determined automatically (25ms+). Actual number of retries attempted depends on the request timeout of the HTTP route.

Timeout per retry attempt for a given request. format: 1h/1m/1s/1ms. MUST BE >=1ms.

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

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.

rewrite the Authority/Host header with this value.

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.

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.

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.

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.

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

Timeout for HTTP requests.

Retry policy for HTTP requests.

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.

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.

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.

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

Header manipulation rules

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

The proportion of traffic to be forwarded to the service version. (0-100). Sum of weights across destinations SHOULD BE == 100. If there is only one destination in a rule, the weight value is assumed to be 100.

Header manipulation rules

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

Header manipulation rules to apply before returning a response to the caller

Overwrite the headers specified by key with the given values

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

Remove a the specified headers

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

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.

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.

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.

Valid port number

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

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.

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.

The destination to which the connection should be forwarded to.

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.

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

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.

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.

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.

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.

The destination to which the connection should be forwarded to.

The destination hosts to which traffic is being sent. Could be a DNS name with wildcard prefix or an IP address. Depending on the platform, short-names can also be used instead of a FQDN (i.e. has no dots in the name). In such a scenario, the FQDN of the host would be derived based on the underlying platform.

A single VirtualService can be used to describe all the traffic properties of the corresponding hosts, including those for multiple HTTP and TCP ports. Alternatively, the traffic properties of a host can be defined using more than one VirtualService, with certain caveats. Refer to the Operations Guide for details.

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 hosts field applies to both HTTP and TCP services. Service inside the mesh, i.e., those found in the service registry, must always be referred to using their alphanumeric names. IP addresses are allowed only for services defined via the Gateway.

The names of gateways and sidecars that should apply 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. A single VirtualService is used for sidecars inside the mesh as well as for one or more gateways. The selection condition imposed by this field can be overridden using the source field in the match conditions of protocol-specific routes. The reserved word mesh is used to imply all the sidecars in the mesh. When this field is omitted, the default gateway (mesh) will be used, which would apply the rule to all sidecars in the mesh. If a list of gateway names is provided, the rules will apply only to the gateways. To apply the rules to both gateways and sidecars, specify mesh as one of the gateway names.

An ordered list of route rules for HTTP traffic. HTTP routes will be applied to platform service ports named ‘http-’/‘http2-’/‘grpc-*’, gateway ports with protocol HTTP/HTTP2/GRPC/ TLS-terminated-HTTPS and service entry ports using HTTP/HTTP2/GRPC protocols. The first rule matching an incoming request is used.

An ordered list of route rule for non-terminated TLS & HTTPS traffic. Routing is typically performed using the SNI value presented by the ClientHello message. TLS routes will be applied to platform service ports named ‘https-’, ‘tls-’, unterminated gateway ports using HTTPS/TLS protocols (i.e. with “passthrough” TLS mode) and service entry ports using HTTPS/TLS protocols. The first rule matching an incoming request is used. NOTE: Traffic ‘https-’ or ‘tls-’ ports without associated virtual service will be treated as opaque TCP traffic.

An ordered list of route rules for opaque TCP traffic. TCP routes will be applied to any port that is not a HTTP or TLS port. The first rule matching an incoming request is used.

A list of namespaces to which this virtual service is exported. Exporting a virtual service allows it to be used by sidecars and gateways defined in other namespaces. This feature provides a mechanism for service owners and mesh administrators to control the visibility of virtual services across namespace boundaries.

If no namespaces are specified then the virtual service is exported to all namespaces by default.

The value “.” is reserved and defines an export to the same namespace that the virtual service is declared in. Similarly the value “*” is reserved and defines 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).

The uint32 value.