- Virtual Service
- VirtualService
- Destination
- HTTPRoute
- Delegate
- Headers
- TLSRoute
- TCPRoute
- HTTPMatchRequest
- HTTPRouteDestination
- RouteDestination
- L4MatchAttributes
- TLSMatchAttributes
- HTTPRedirect
- HTTPDirectResponse
- HTTPBody
- HTTPRewrite
- StringMatch
- HTTPRetry
- CorsPolicy
- HTTPFaultInjection
- PortSelector
- Percent
- Headers.HeaderOperations
- HTTPFaultInjection.Delay
- HTTPFaultInjection.Abort
- google.protobuf.UInt32Value
- HTTPRedirect.RedirectPortSelection
Virtual Service
Configuration affecting traffic routing. Here are a few terms useful to define in the context of traffic routing.
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”.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews.prod.svc.cluster.local
http:
- name: "reviews-v2-routes"
match:
- uri:
prefix: "/wpcatalog"
- uri:
prefix: "/consumercatalog"
rewrite:
uri: "/newcatalog"
route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v2
- name: "reviews-v1-route"
route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v1
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews.prod.svc.cluster.local
http:
- name: "reviews-v2-routes"
match:
- uri:
prefix: "/wpcatalog"
- uri:
prefix: "/consumercatalog"
rewrite:
uri: "/newcatalog"
route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v2
- name: "reviews-v1-route"
route:
- destination:
host: reviews.prod.svc.cluster.local
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
.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews-destination
spec:
host: reviews.prod.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: reviews-destination
spec:
host: reviews.prod.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
VirtualService
Configuration affecting traffic routing.
Field | Type | Description | Required |
---|---|---|---|
hosts | string[] | 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. Note: It must be empty for a delegate VirtualService. | No |
gateways | string[] | The names of gateways and sidecars that should apply these routes. Gateways in other namespaces may be referred to by | No |
http | HTTPRoute[] | An ordered list of route rules for HTTP traffic. HTTP routes will be applied to platform service ports using HTTP/HTTP2/GRPC protocols, 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. | No |
tls | TLSRoute[] | 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. | No |
tcp | TCPRoute[] | 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. | No |
exportTo | string[] | 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. | No |
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 ServiceEntry 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.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-route
namespace: foo
spec:
hosts:
- reviews # interpreted as reviews.foo.svc.cluster.local
http:
- match:
- uri:
prefix: "/wpcatalog"
- uri:
prefix: "/consumercatalog"
rewrite:
uri: "/newcatalog"
route:
- destination:
host: reviews # interpreted as reviews.foo.svc.cluster.local
subset: v2
- route:
- destination:
host: reviews # interpreted as reviews.foo.svc.cluster.local
subset: v1
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews-route
namespace: foo
spec:
hosts:
- reviews # interpreted as reviews.foo.svc.cluster.local
http:
- match:
- uri:
prefix: "/wpcatalog"
- uri:
prefix: "/consumercatalog"
rewrite:
uri: "/newcatalog"
route:
- destination:
host: reviews # interpreted as reviews.foo.svc.cluster.local
subset: v2
- route:
- destination:
host: reviews # interpreted as reviews.foo.svc.cluster.local
subset: v1
And the associated DestinationRule
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews-destination
namespace: foo
spec:
host: reviews # interpreted as reviews.foo.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: reviews-destination
namespace: foo
spec:
host: reviews # interpreted as reviews.foo.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
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.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-productpage-rule
namespace: istio-system
spec:
hosts:
- productpage.prod.svc.cluster.local # ignores rule namespace
http:
- timeout: 5s
route:
- destination:
host: productpage.prod.svc.cluster.local
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: my-productpage-rule
namespace: istio-system
spec:
hosts:
- productpage.prod.svc.cluster.local # ignores rule namespace
http:
- timeout: 5s
route:
- destination:
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.
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-wikipedia
spec:
hosts:
- wikipedia.org
location: MESH_EXTERNAL
ports:
- number: 80
name: example-http
protocol: HTTP
resolution: DNS
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-wiki-rule
spec:
hosts:
- wikipedia.org
http:
- timeout: 5s
route:
- destination:
host: wikipedia.org
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: external-svc-wikipedia
spec:
hosts:
- wikipedia.org
location: MESH_EXTERNAL
ports:
- number: 80
name: example-http
protocol: HTTP
resolution: DNS
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: my-wiki-rule
spec:
hosts:
- wikipedia.org
http:
- timeout: 5s
route:
- destination:
host: wikipedia.org
Field | Type | Description | Required |
---|---|---|---|
host | string | 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 |
subset | string | 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 | PortSelector | 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.
Field | Type | Description | Required |
---|---|---|---|
name | string | 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 |
match | HTTPMatchRequest[] | 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 | HTTPRouteDestination[] | A HTTP rule can either return a direct_response, 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 |
redirect | HTTPRedirect | A HTTP rule can either return a direct_response, 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 |
directResponse | HTTPDirectResponse | A HTTP rule can either return a direct_response, redirect or forward (default) traffic. Direct Response is used to specify a fixed response that should be sent to clients. It can be set only when | No |
delegate | Delegate | Delegate is used to specify the particular VirtualService which can be used to define delegate HTTPRoute. It can be set only when NOTE:
| No |
rewrite | HTTPRewrite | Rewrite HTTP URIs and Authority headers. Rewrite cannot be used with Redirect primitive. Rewrite will be performed before forwarding. | No |
timeout | Duration | Timeout for HTTP requests, default is disabled. | No |
retries | HTTPRetry | Retry policy for HTTP requests. | No |
fault | HTTPFaultInjection | 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 |
mirror | Destination | 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 | Percent | Percentage of the traffic to be mirrored by the | No |
corsPolicy | CorsPolicy | Cross-Origin Resource Sharing policy (CORS). Refer to CORS for further details about cross origin resource sharing. | No |
headers | Headers | Header manipulation rules | 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
.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo
spec:
hosts:
- "bookinfo.com"
gateways:
- mygateway
http:
- match:
- uri:
prefix: "/productpage"
delegate:
name: productpage
namespace: nsA
- match:
- uri:
prefix: "/reviews"
delegate:
name: reviews
namespace: nsB
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: productpage
namespace: nsA
spec:
http:
- match:
- uri:
prefix: "/productpage/v1/"
route:
- destination:
host: productpage-v1.nsA.svc.cluster.local
- route:
- destination:
host: productpage.nsA.svc.cluster.local
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
namespace: nsB
spec:
http:
- route:
- destination:
host: reviews.nsB.svc.cluster.local
Field | Type | Description | Required |
---|---|---|---|
name | string | Name specifies the name of the delegate VirtualService. | No |
namespace | string | 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 v1
subset (version) of the reviews
service.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews.prod.svc.cluster.local
http:
- headers:
request:
set:
test: "true"
route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v2
weight: 25
- destination:
host: reviews.prod.svc.cluster.local
subset: v1
headers:
response:
remove:
- foo
weight: 75
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews.prod.svc.cluster.local
http:
- headers:
request:
set:
test: "true"
route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v2
weight: 25
- destination:
host: reviews.prod.svc.cluster.local
subset: v1
headers:
response:
remove:
- foo
weight: 75
Field | Type | Description | Required |
---|---|---|---|
request | HeaderOperations | Header manipulation rules to apply before forwarding a request to the destination service | No |
response | HeaderOperations | Header manipulation rules to apply before returning a response to the caller | No |
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.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo-sni
spec:
hosts:
- "*.bookinfo.com"
gateways:
- mygateway
tls:
- match:
- port: 443
sniHosts:
- login.bookinfo.com
route:
- destination:
host: login.prod.svc.cluster.local
- match:
- port: 443
sniHosts:
- reviews.bookinfo.com
route:
- destination:
host: reviews.prod.svc.cluster.local
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: bookinfo-sni
spec:
hosts:
- "*.bookinfo.com"
gateways:
- mygateway
tls:
- match:
- port: 443
sniHosts:
- login.bookinfo.com
route:
- destination:
host: login.prod.svc.cluster.local
- match:
- port: 443
sniHosts:
- reviews.bookinfo.com
route:
- destination:
host: reviews.prod.svc.cluster.local
Field | Type | Description | Required |
---|---|---|---|
match | TLSMatchAttributes[] | 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 | RouteDestination[] | 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.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo-mongo
spec:
hosts:
- mongo.prod.svc.cluster.local
tcp:
- match:
- port: 27017
route:
- destination:
host: mongo.backup.svc.cluster.local
port:
number: 5555
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: bookinfo-mongo
spec:
hosts:
- mongo.prod.svc.cluster.local
tcp:
- match:
- port: 27017
route:
- destination:
host: mongo.backup.svc.cluster.local
port:
number: 5555
Field | Type | Description | Required |
---|---|---|---|
match | L4MatchAttributes[] | 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 | RouteDestination[] | 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
.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- headers:
end-user:
exact: jason
uri:
prefix: "/ratings/v2/"
ignoreUriCase: true
route:
- destination:
host: ratings.prod.svc.cluster.local
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- headers:
end-user:
exact: jason
uri:
prefix: "/ratings/v2/"
ignoreUriCase: true
route:
- destination:
host: ratings.prod.svc.cluster.local
HTTPMatchRequest CANNOT be empty. Note:
- If a root VirtualService have matched any property (path, header etc.) by regex, delegate VirtualServices should not have any other matches on the same property.
- If a delegate VirtualService have matched any property (path, header etc.) by regex, root VirtualServices should not have any other matches on the same property.
Field | Type | Description | Required |
---|---|---|---|
name | string | 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 |
uri | StringMatch | URI to match values are case-sensitive and formatted as follows:
Note: Case-insensitive matching could be enabled via the | No |
scheme | StringMatch | URI Scheme values are case-sensitive and formatted as follows:
| No |
method | StringMatch | HTTP Method values are case-sensitive and formatted as follows:
| No |
authority | StringMatch | HTTP Authority values are case-sensitive and formatted as follows:
| No |
headers | map<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:
If the value is empty and only the name of header is specified, presence of the header is checked. Note: The keys | No |
port | uint32 | 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 |
sourceLabels | map<string, string> | One or more labels that constrain the applicability of a rule to source (client) workloads with the given labels. If the VirtualService has a list of gateways specified in the top-level | No |
gateways | string[] | Names of gateways where the rule should be applied. Gateway names in the top-level | No |
queryParams | map<string, StringMatch> | Query parameters for matching. Ex:
| No |
ignoreUriCase | bool | Flag to specify whether the URI matching should be case-insensitive. Note: The case will be ignored only in the case of | No |
withoutHeaders | map<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 |
sourceNamespace | string | 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 | No |
statPrefix | string | The human readable prefix to use when emitting statistics for this route. The statistics are generated with prefix route.<stat_prefix>. This should be set for highly critical routes that one wishes to get “per-route” statistics on. This prefix is only for proxy-level statistics (envoy) and not service-level (istio_) statistics. Refer to https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-field-config-route-v3-route-stat-prefix for statistics that are generated when this is configured. | No |
HTTPRouteDestination
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”.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews.prod.svc.cluster.local
http:
- route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v2
weight: 25
- destination:
host: reviews.prod.svc.cluster.local
subset: v1
weight: 75
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews.prod.svc.cluster.local
http:
- route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v2
weight: 25
- destination:
host: reviews.prod.svc.cluster.local
subset: v1
weight: 75
And the associated DestinationRule
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews-destination
spec:
host: reviews.prod.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: reviews-destination
spec:
host: reviews.prod.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
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
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-route-two-domains
spec:
hosts:
- reviews.com
http:
- route:
- destination:
host: dev.reviews.com
weight: 25
- destination:
host: reviews.com
weight: 75
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews-route-two-domains
spec:
hosts:
- reviews.com
http:
- route:
- destination:
host: dev.reviews.com
weight: 25
- destination:
host: reviews.com
weight: 75
Field | Type | Description | Required |
---|---|---|---|
destination | Destination | Destination uniquely identifies the instances of a service to which the request/connection should be forwarded to. | Yes |
weight | int32 | Weight specifies the relative proportion of traffic to be forwarded to the destination. A destination will receive | No |
headers | Headers | Header manipulation rules | No |
RouteDestination
L4 routing rule weighted destination.
Field | Type | Description | Required |
---|---|---|---|
destination | Destination | Destination uniquely identifies the instances of a service to which the request/connection should be forwarded to. | Yes |
weight | int32 | Weight specifies the relative proportion of traffic to be forwarded to the destination. A destination will receive | No |
L4MatchAttributes
L4 connection match attributes. Note that L4 connection matching support is incomplete.
Field | Type | Description | Required |
---|---|---|---|
destinationSubnets | string[] | 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 |
port | uint32 | 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 |
sourceLabels | map<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 | No |
gateways | string[] | Names of gateways where the rule should be applied. Gateway names in the top-level | No |
sourceNamespace | string | 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 | No |
TLSMatchAttributes
TLS connection match attributes.
Field | Type | Description | Required |
---|---|---|---|
sniHosts | string[] | 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 |
destinationSubnets | string[] | 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 |
port | uint32 | 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 |
sourceLabels | map<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 | No |
gateways | string[] | Names of gateways where the rule should be applied. Gateway names in the top-level | No |
sourceNamespace | string | 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 | 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.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- uri:
exact: /v1/getProductRatings
redirect:
uri: /v1/bookRatings
authority: newratings.default.svc.cluster.local
...
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- uri:
exact: /v1/getProductRatings
redirect:
uri: /v1/bookRatings
authority: newratings.default.svc.cluster.local
...
Field | Type | Description | Required |
---|---|---|---|
uri | string | 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 |
authority | string | On a redirect, overwrite the Authority/Host portion of the URL with this value. | No |
port | uint32 (oneof) | On a redirect, overwrite the port portion of the URL with this value. | No |
derivePort | RedirectPortSelection (oneof) | On a redirect, dynamically set the port:
| No |
scheme | string | On a redirect, overwrite the scheme portion of the URL with this value. For example, | No |
redirectCode | uint32 | On a redirect, Specifies the HTTP status code to use in the redirect response. The default response code is MOVED_PERMANENTLY (301). | No |
HTTPDirectResponse
HTTPDirectResponse can be used to send a fixed response to clients. For example, the following rule returns a fixed 503 status with a body to requests for /v1/getProductRatings API.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- uri:
exact: /v1/getProductRatings
directResponse:
status: 503
body:
string: "unknown error"
...
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- uri:
exact: /v1/getProductRatings
directResponse:
status: 503
body:
string: "unknown error"
...
It is also possible to specify a binary response body. This is mostly useful for non text-based protocols such as gRPC.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- uri:
exact: /v1/getProductRatings
directResponse:
status: 503
body:
bytes: "dW5rbm93biBlcnJvcg==" # "unknown error" in base64
...
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- uri:
exact: /v1/getProductRatings
directResponse:
status: 503
body:
bytes: "dW5rbm93biBlcnJvcg==" # "unknown error" in base64
...
It is good practice to add headers in the HTTPRoute as well as the direct_response, for example to specify the returned Content-Type.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- uri:
exact: /v1/getProductRatings
directResponse:
status: 503
body:
string: "{\"error\": \"unknown error\"}"
headers:
response:
set:
content-type: "appliation/json"
...
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- uri:
exact: /v1/getProductRatings
directResponse:
status: 503
body:
string: "{\"error\": \"unknown error\"}"
headers:
response:
set:
content-type: "text/plain"
...
Field | Type | Description | Required |
---|---|---|---|
status | uint32 | Specifies the HTTP response status to be returned. | Yes |
body | HTTPBody | Specifies the content of the response body. If this setting is omitted, no body is included in the generated response. | No |
HTTPBody
Field | Type | Description | Required |
---|---|---|---|
string | string (oneof) | response body as a string | No |
bytes | bytes (oneof) | response body as base64 encoded bytes. | 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.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- uri:
prefix: /ratings
rewrite:
uri: /v1/bookRatings
route:
- destination:
host: ratings.prod.svc.cluster.local
subset: v1
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- uri:
prefix: /ratings
rewrite:
uri: /v1/bookRatings
route:
- destination:
host: ratings.prod.svc.cluster.local
subset: v1
Field | Type | Description | Required |
---|---|---|---|
uri | string | 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 |
authority | string | rewrite the Authority/Host header with this value. | No |
StringMatch
Describes how to match a given string in HTTP headers. Match is case-sensitive.
Field | Type | Description | Required |
---|---|---|---|
exact | string (oneof) | exact string match | No |
prefix | string (oneof) | prefix-based match | No |
regex | string (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. A retry will be attempted if there is a connect-failure, refused_stream or when the upstream server responds with Service Unavailable(503).
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- route:
- destination:
host: ratings.prod.svc.cluster.local
subset: v1
retries:
attempts: 3
perTryTimeout: 2s
retryOn: connect-failure,refused-stream,503
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- route:
- destination:
host: ratings.prod.svc.cluster.local
subset: v1
retries:
attempts: 3
perTryTimeout: 2s
retryOn: gateway-error,connect-failure,refused-stream
Field | Type | Description | Required |
---|---|---|---|
attempts | int32 | Number of retries to be allowed for a given request. The interval between retries will be determined automatically (25ms+). When request | Yes |
perTryTimeout | Duration | 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 | No |
retryOn | string | Specifies the conditions under which retry takes place. One or more policies can be specified using a ‘,’ delimited list. If | No |
retryRemoteLocalities | BoolValue | Flag to specify whether the retries should retry to other localities. See the retry plugin configuration for more details. | No |
CorsPolicy
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.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- route:
- destination:
host: ratings.prod.svc.cluster.local
subset: v1
corsPolicy:
allowOrigins:
- exact: https://example.com
allowMethods:
- POST
- GET
allowCredentials: false
allowHeaders:
- X-Foo-Bar
maxAge: "24h"
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- route:
- destination:
host: ratings.prod.svc.cluster.local
subset: v1
corsPolicy:
allowOrigins:
- exact: https://example.com
allowMethods:
- POST
- GET
allowCredentials: false
allowHeaders:
- X-Foo-Bar
maxAge: "24h"
Field | Type | Description | Required |
---|---|---|---|
allowOrigins | StringMatch[] | 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. | No |
allowMethods | string[] | List of HTTP methods allowed to access the resource. The content will be serialized into the Access-Control-Allow-Methods header. | No |
allowHeaders | string[] | List of HTTP headers that can be used when requesting the resource. Serialized to Access-Control-Allow-Headers header. | No |
exposeHeaders | string[] | A list of HTTP headers that the browsers are allowed to access. Serialized into Access-Control-Expose-Headers header. | No |
maxAge | Duration | Specifies how long the results of a preflight request can be cached. Translates to the | No |
allowCredentials | BoolValue | Indicates whether the caller is allowed to send the actual request (not the preflight) using credentials. Translates to | No |
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.
Field | Type | Description | Required |
---|---|---|---|
delay | Delay | Delay requests before forwarding, emulating various failures such as network issues, overloaded upstream service, etc. | No |
abort | Abort | 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.
Field | Type | Description | Required |
---|---|---|---|
number | uint32 | Valid port number | No |
Percent
Percent specifies a percentage in the range of [0.0, 100.0].
Field | Type | Description | Required |
---|---|---|---|
value | double | No |
Headers.HeaderOperations
HeaderOperations Describes the header manipulations to apply
Field | Type | Description | Required |
---|---|---|---|
set | map<string, string> | Overwrite the headers specified by key with the given values | No |
add | map<string, string> | Append the given values to the headers specified by keys (will create a comma-separated list of values) | No |
remove | string[] | Remove 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
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews.prod.svc.cluster.local
http:
- match:
- sourceLabels:
env: prod
route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v1
fault:
delay:
percentage:
value: 0.1
fixedDelay: 5s
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews.prod.svc.cluster.local
http:
- match:
- sourceLabels:
env: prod
route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v1
fault:
delay:
percentage:
value: 0.1
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, no request will be delayed.
Field | Type | Description | Required |
---|---|---|---|
fixedDelay | Duration (oneof) | Add a fixed delay before forwarding the request. Format: 1h/1m/1s/1ms. MUST be >=1ms. | Yes |
percentage | Percent | Percentage of requests on which the delay will be injected. If left unspecified, no request will be delayed. | No |
percent | int32 | Percentage of requests on which the delay will be injected (0-100). Use of integer | 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”.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- route:
- destination:
host: ratings.prod.svc.cluster.local
subset: v1
fault:
abort:
percentage:
value: 0.1
httpStatus: 400
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- route:
- destination:
host: ratings.prod.svc.cluster.local
subset: v1
fault:
abort:
percentage:
value: 0.1
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, no request will be aborted.
Field | Type | Description | Required |
---|---|---|---|
httpStatus | int32 (oneof) | HTTP status code to use to abort the Http request. | Yes |
grpcStatus | string (oneof) | GRPC status code to use to abort the request. The supported codes are documented in https://github.com/grpc/grpc/blob/master/doc/statuscodes.md Note: If you want to return the status “Unavailable”, then you should specify the code as | No |
percentage | Percent | Percentage of requests to be aborted with the error code provided. If not specified, no request will be aborted. | No |
google.protobuf.UInt32Value
Wrapper message for uint32
.
The JSON representation for UInt32Value
is JSON number.
Field | Type | Description | Required |
---|---|---|---|
value | uint32 | The uint32 value. | No |
HTTPRedirect.RedirectPortSelection
Name | Description |
---|---|
FROM_PROTOCOL_DEFAULT | |
FROM_REQUEST_PORT |