Route Rules v1alpha3

Connection pool settings for an upstream host. The settings apply to each individual host in the upstream service. See Envoy’s circuit breaker for more details. Connection pool settings can be applied at the TCP level as well as at HTTP level.

For example, the following rule sets a limit of 100 connections to redis service called myredissrv with a connect timeout of 30ms

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-redis
spec:
  host: myredissrv.prod.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
        connectTimeout: 30ms

Settings applicable to HTTP1.1/HTTP2/GRPC connections.

Settings common to both HTTP and TCP upstream connections.

Describes the Cross-Origin Resource Sharing (CORS) policy, for a given service. Refer to https://developer.mozilla.org/en-US/docs/Web/HTTP/AccesscontrolCORS 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:
      allowOrigin:
      - example.com
      allowMethods:
      - POST
      - GET
      allowCredentials: false
      allowHeaders:
      - X-Foo-Bar
      maxAge: "1d"

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 hosts declared through the ExternalService 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

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

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

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 ExternalService rule. VirtualServices can then be defined to control traffic bound to these external services. For example, the following rules define an ExternalService for wikipedia.org and set a timeout of 5s for http requests.

apiVersion: networking.istio.io/v1alpha3
kind: ExternalService
metadata:
  name: external-svc-wikipedia
spec:
  hosts:
  - wikipedia.org
  ports:
  - number: 80
    name: example-http
    protocol: HTTP
  discovery: 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

# Overview

DestinationRule defines policies that apply to traffic intended for a service after routing has occurred. These rules specify configuration for load balancing, connection pool size from the sidecar, and outlier detection settings to detect and evict unhealthy hosts from the load balancing pool. For example, a simple load balancing policy for the ratings service would look as follows:

 apiVersion: networking.istio.io/v1alpha3
 kind: DestinationRule
 metadata:
   name: bookinfo-ratings
 spec:
   host: ratings.prod.svc.cluster.local
   trafficPolicy:
     loadBalancer:
       simple: LEAST_CONN

Version specific policies can be specified by defining a named subset and overriding the settings specified at the service level. The following rule uses a round robin load balancing policy for all traffic going to a subset named testversion that is composed of endpoints (e.g., pods) with labels (version:v3).

 apiVersion: networking.istio.io/v1alpha3
 kind: DestinationRule
 metadata:
   name: bookinfo-ratings
 spec:
   host: ratings.prod.svc.cluster.local
   trafficPolicy:
     loadBalancer:
       simple: LEAST_CONN
   subsets:
   - name: testversion
     labels:
       version: v3
     trafficPolicy:
       loadBalancer:
         simple: ROUND_ROBIN

Note: Policies specified for subsets will not take effect until a route rule explicitly sends traffic to this subset.

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

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

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

# Overview

ExternalService describes the endpoints, ports and protocols of a white-listed set of mesh-external domains and IP blocks that services in the mesh are allowed to access.

For example, the following ExternalService configuration describes the set of services at https://example.com to be accessed internally over plaintext http (i.e. http://example.com:443), with the sidecar originating TLS.

 apiVersion: networking.istio.io/v1alpha3
 kind: ExternalService
 metadata:
   name: external-svc-example
 spec:
   hosts:
   - example.com
   ports:
   - number: 443
     name: example-http
     protocol: HTTP # not HTTPS.
   discovery: DNS

and a DestinationRule to initiate TLS connections to the external service.

 apiVersion: networking.istio.io/v1alpha3
 kind: DestinationRule
 metadata:
   name: tls-example
 spec:
   name: example.com
   trafficPolicy:
     tls:
       mode: SIMPLE # initiates HTTPS when talking to example.com

The following specification specifies a static set of backend nodes for a MongoDB cluster behind a set of virtual IPs, and sets up a DestinationRule to initiate mTLS connections upstream.

 apiVersion: networking.istio.io/v1alpha3
 kind: ExternalService
 metadata:
   name: external-svc-mongocluster
 spec:
   hosts:
   - 192.192.192.192/24
   ports:
   - number: 27018
     name: mongodb
     protocol: MONGO
   discovery: STATIC
   endpoints:
   - address: 2.2.2.2
   - address: 3.3.3.3

and the associated DestinationRule

 apiVersion: networking.istio.io/v1alpha3
 kind: DestinationRule
 metadata:
   name: mtls-mongocluster
 spec:
   name: 192.192.192.192/24
   trafficPolicy:
     tls:
       mode: MUTUAL
       clientCertificate: /etc/certs/myclientcert.pem
       privateKey: /etc/certs/client_private_key.pem
       caCertificates: /etc/certs/rootcacerts.pem

The following example demonstrates the use of wildcards in the hosts. If the connection has to be routed to the IP address requested by the application (i.e. application resolves DNS and attempts to connect to a specific IP), the discovery mode must be set to NONE.

 apiVersion: networking.istio.io/v1alpha3
 kind: ExternalService
 metadata:
   name: external-svc-wildcard-example
 spec:
   hosts:
   - "*.bar.com"
   ports:
   - number: 80
     name: http
     protocol: HTTP
   discovery: NONE

For HTTP based services, it is possible to create a VirtualService backed by multiple DNS addressible endpoints. In such a scenario, the application can use the HTTP_PROXY environment variable to transparently reroute API calls for the VirtualService to a chosen backend. For example, the following configuration creates a non-existent service called foo.bar.com backed by three domains: us.foo.bar.com:8443, uk.foo.bar.com:9443, and in.foo.bar.com:7443

 apiVersion: networking.istio.io/v1alpha3
 kind: ExternalService
 metadata:
   name: external-svc-dns
 spec:
   hosts:
   - foo.bar.com
   ports:
   - number: 443
     name: https
     protocol: HTTP
   discovery: DNS
   endpoints:
   - address: us.foo.bar.com
     ports:
       https: 8443
   - address: uk.foo.bar.com
     ports:
       https: 9443
   - address: in.foo.bar.com
     ports:
       https: 7443

and a DestinationRule to initiate TLS connections to the ExternalService.

 apiVersion: networking.istio.io/v1alpha3
 kind: DestinationRule
 metadata:
   name: tls-foobar
 spec:
   name: foo.bar.com
   trafficPolicy:
     tls:
       mode: SIMPLE # initiates HTTPS

With HTTP_PROXY=http://localhost:443, calls from the application to http://foo.bar.com will be upgraded to HTTPS and load balanced across the three domains specified above. In other words, a call to http://foo.bar.com/baz would be translated to https://uk.foo.bar.com/baz.

Different ways of discovering the IP addresses associated with the service.

Endpoint defines a network address (IP or hostname) associated with the external service.

# Overview

Gateway describes a load balancer operating at the edge of the mesh receiving incoming or outgoing HTTP/TCP connections. The specification describes a set of ports that should be exposed, the type of protocol to use, SNI configuration for the load balancer, etc.

For example, the following Gateway configuration sets up a proxy to act as a load balancer exposing port 80 and 9080 (http), 443 (https), and port 2379 (TCP) for ingress. The gateway will be applied to the proxy running on a pod with labels app: my-gateway-controller. While Istio will configure the proxy to listen on these ports, it is the responsibility of the user to ensure that external traffic to these ports are allowed into the mesh.

 apiVersion: networking.istio.io/v1alpha3
 kind: Gateway
 metadata:
   name: my-gateway
 spec:
   selector:
     app: my-gatweway-controller
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:
     - uk.bookinfo.com
     - eu.bookinfo.com
     tls:
       httpsRedirect: true # sends 302 redirect for http requests
   - port:
       number: 443
       name: https
       protocol: HTTPS
     hosts:
     - uk.bookinfo.com
     - eu.bookinfo.com
     tls:
       mode: SIMPLE #enables HTTPS on this port
       serverCertificate: /etc/certs/servercert.pem
       privateKey: /etc/certs/privatekey.pem
   - port:
       number: 9080
       name: http-wildcard
       protocol: HTTP
     # no hosts implies wildcard match
   - port:
       number: 2379 #to expose internal service via external port 2379
       name: mongo
       protocol: MONGO

The Gateway specification above describes the L4-L6 properties of a load balancer. A VirtualService can then be bound to a gateway to control the forwarding of traffic arriving at a particular host or gateway port.

For example, the following VirtualService splits traffic for “https://uk.bookinfo.com/reviews”, “https://eu.bookinfo.com/reviews”, “http://uk.bookinfo.com:9080/reviews”, “http://eu.bookinfo.com:9080/reviews” into two versions (prod and qa) of an internal reviews service on port 9080. In addition, requests containing the cookie “user: dev-123” will be sent to special port 7777 in the qa version. The same rule is also applicable inside the mesh for requests to the r”eviews.prod.svc.cluster.local” service. This rule is applicable across ports 443, 9080. Note that “http://uk.bookinfo.com” gets redirected to “https://uk.bookinfo.com” (i.e. 80 redirects to 443).

 apiVersion: networking.istio.io/v1alpha3
 kind: VirtualService
 metadata:
   name: bookinfo-rule
 spec:
   hosts:
   - reviews.prod.svc.cluster.local
   - uk.bookinfo.com
   - eu.bookinfo.com
   gateways:
   - my-gateway
   - mesh # applies to all the sidecars in the mesh
   http:
   - match:
     - headers:
         cookie:
           user: dev-123
     route:
     - destination:
         port:
           number: 7777
         name: reviews.qa.svc.cluster.local
   - match:
       uri:
         prefix: /reviews/
     route:
     - destination:
         port:
           number: 9080 # can be omitted if its the only port for reviews
         name: reviews.prod.svc.cluster.local
       weight: 80
     - destination:
         name: reviews.qa.svc.cluster.local
       weight: 20

The following VirtualService forwards traffic arriving at (external) port 27017 from “172.17.16.0/24” subnet to internal Mongo server on port 5555. This rule is not applicable internally in the mesh as the gateway list omits the reserved name mesh.

 apiVersion: networking.istio.io/v1alpha3
 kind: VirtualService
 metadata:
   name: bookinfo-Mongo
 spec:
   hosts:
   - mongosvr.prod.svc.cluster.local #name of internal Mongo service
   gateways:
   - my-gateway
   tcp:
   - match:
     - port:
         number: 27017
       sourceSubnet: "172.17.16.0/24"
     route:
     - destination:
         name: mongo.prod.svc.cluster.local

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.

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 10% of the 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:
        percent: 10
        httpStatus: 400

The httpStatus field is used to indicate the HTTP status code to return to the caller. The optional percent field, a value between 0 and 100, is used to only abort a certain percentage of requests. If not specified, all requests are aborted.

Delay specification is used to inject latency into the request forwarding path. The following example will introduce a 5 second delay in 10% of the 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:
        percent: 10
        fixedDelay: 5s

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

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 cookie with value user=jason.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings-route
spec:
  hosts:
  - ratings.prod.svc.cluster.local
  http:
  - match:
    - headers:
        cookie:
          regex: "^(.*?;)?(user=jason)(;.*)?"
        uri:
          prefix: "/ratings/v2/"
    route: 
    - destination:
        host: ratings.prod.svc.cluster.local

HTTPMatchRequest CANNOT be empty.

HTTPRedirect can be used to send a 302 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
  ...

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.

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

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 the DestinationWeights. 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

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

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

Load balancing policies to apply for a specific destination. See Envoy’s load balancing documentation for more details.

For example, the following rule uses a round robin load balancing policy for all traffic going to the ratings service.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN

The following example uses the consistent hashing based load balancer for the same ratings service using the Cookie header as the hash key.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      consistentHash:
        http_header: Cookie

Consistent hashing (ketama hash) based load balancer for even load distribution/redistribution when the connection pool changes. This load balancing policy is applicable only for HTTP-based connections. A user specified HTTP header is used as the key with xxHash hashing.

Standard load balancing algorithms that require no tuning.

A Circuit breaker implementation that tracks the status of each individual host in the upstream service. While currently applicable to only HTTP services, future versions will support opaque TCP services as well. For HTTP services, hosts that continually return errors for API calls are ejected from the pool for a pre-defined period of time. See Envoy’s outlier detection for more details.

The following rule sets a connection pool size of 100 connections and 1000 concurrent HTTP2 requests, with no more than 10 req/connection to “reviews” service. In addition, it configures upstream hosts to be scanned every 5 mins, such that any host that fails 7 consecutive times with 5XX error code will be ejected for 15 minutes.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews-cb-policy
spec:
  host: reviews.prod.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http2MaxRequests: 1000
        maxRequestsPerConnection: 10
    outlierDetection:
      http:
        consecutiveErrors: 7
        interval: 5m
        baseEjectionTime: 15m

Outlier detection settings for HTTP1.1/HTTP2/GRPC connections.

Port describes the properties of a specific port of a service.

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

Server describes the properties of the proxy on a given load balancer port. For example,

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: my-ingress
spec:
  selector:
    app: my-ingress-gateway
  servers:
  - port:
      number: 80
      name: http2
      protocol: HTTP2

Another example

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: my-tcp-ingress
spec:
  selector:
    app: my-tcp-ingress-gateway
  servers:
  - port:
      number: 27018
      name: mongo
      protocol: MONGO

The following is an example of TLS configuration for port 443

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: my-tls-ingress
spec:
  selector:
    app: my-tls-ingress-gateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      serverCertificate: /etc/certs/server.pem
      privateKey: /etc/certs/privatekey.pem

TLS modes enforced by the proxy

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

A subset of endpoints of a service. Subsets can be used for scenarios like A/B testing, or routing to a specific version of a service. Refer to VirtualService documentation for examples of using subsets in these scenarios. In addition, traffic policies defined at the service-level can be overridden at a subset-level. The following rule uses a round robin load balancing policy for all traffic going to a subset named testversion that is composed of endpoints (e.g., pods) with labels (version:v3).

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_CONN
  subsets:
  - name: testversion
    labels:
      version: v3
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN

Note: Policies specified for subsets will not take effect until a route rule explicitly sends traffic to this subset.

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 from 172.17.16.* subnet 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
      sourceSubnet: "172.17.16.0/24"
    route:
    - destination:
        host: mongo.backup.svc.cluster.local
        port:
          number: 5555

SSL/TLS related settings for upstream connections. See Envoy’s TLS context for more details. These settings are common to both HTTP and TCP upstreams.

For example, the following rule configures a client to use mutual TLS for connections to upstream database cluster.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: db-mtls
spec:
  host: mydbserver.prod.svc.cluster.local
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/myclientcert.pem
      privateKey: /etc/certs/client_private_key.pem
      caCertificates: /etc/certs/rootcacerts.pem

The following rule configures a client to use TLS when talking to a foreign service whose domain matches *.foo.com.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: tls-foo
spec:
  host: "*.foo.com"
  trafficPolicy:
    tls:
      mode: SIMPLE

TLS connection mode

Traffic policies to apply for a specific destination. See DestinationRule for examples.

# Overview

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 containing /wpcatalog/, /consumercatalog/ url prefixes 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:
   - match:
     - uri:
         prefix: "/wpcatalog"
     - uri:
         prefix: "/consumercatalog"
     rewrite:
       uri: "/newcatalog"
     route:
     - destination:
         host: reviews.prod.svc.cluster.local
         subset: v2
   - 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