istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
istio.io/content/docs/reference/config/istio.networking.v1alpha3.html

3045 lines
87 KiB
HTML
Raw Blame History

---
title: Route Rules v1alpha3
description: Configuration affecting traffic routing
location: https://istio.io/docs/reference/config/istio.networking.v1alpha3.html
layout: protoc-gen-docs
generator: protoc-gen-docs
number_of_entries: 38
---
<p>Configuration affecting traffic routing. Here are a few terms useful to define
in the context of traffic routing.</p>
<p><code>Service</code> a unit of application behavior bound to a unique name in a
service registry. Services consist of multiple network <em>endpoints</em>
implemented by workload instances running on pods, containers, VMs etc.</p>
<p><code>Service versions (a.k.a. subsets)</code> - 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.</p>
<p><code>Source</code> - A downstream client calling a service.</p>
<p><code>Host</code> - The address used by a client when attempting to connect to a
service.</p>
<p><code>Access model</code> - 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.</p>
<h2 id="ConnectionPoolSettings">ConnectionPoolSettings</h2>
<section>
<p>Connection pool settings for an upstream host. The settings apply to
each individual host in the upstream service. See Envoy&rsquo;s <a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/circuit_breaking">circuit
breaker</a>
for more details. Connection pool settings can be applied at the TCP
level as well as at HTTP level.</p>
<p>For example, the following rule sets a limit of 100 connections to redis
service called myredissrv with a connect timeout of 30ms</p>
<pre><code class="language-yaml">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
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ConnectionPoolSettings-tcp">
<td><code>tcp</code></td>
<td><code><a href="#ConnectionPoolSettings-TCPSettings">ConnectionPoolSettings.TCPSettings</a></code></td>
<td>
<p>Settings common to both HTTP and TCP upstream connections.</p>
</td>
</tr>
<tr id="ConnectionPoolSettings-http">
<td><code>http</code></td>
<td><code><a href="#ConnectionPoolSettings-HTTPSettings">ConnectionPoolSettings.HTTPSettings</a></code></td>
<td>
<p>HTTP connection pool settings.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ConnectionPoolSettings-HTTPSettings">ConnectionPoolSettings.HTTPSettings</h2>
<section>
<p>Settings applicable to HTTP1.1/HTTP2/GRPC connections.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ConnectionPoolSettings-HTTPSettings-http1_max_pending_requests">
<td><code>http1MaxPendingRequests</code></td>
<td><code>int32</code></td>
<td>
<p>Maximum number of pending HTTP requests to a destination. Default 1024.</p>
</td>
</tr>
<tr id="ConnectionPoolSettings-HTTPSettings-http2_max_requests">
<td><code>http2MaxRequests</code></td>
<td><code>int32</code></td>
<td>
<p>Maximum number of requests to a backend. Default 1024.</p>
</td>
</tr>
<tr id="ConnectionPoolSettings-HTTPSettings-max_requests_per_connection">
<td><code>maxRequestsPerConnection</code></td>
<td><code>int32</code></td>
<td>
<p>Maximum number of requests per connection to a backend. Setting this
parameter to 1 disables keep alive.</p>
</td>
</tr>
<tr id="ConnectionPoolSettings-HTTPSettings-max_retries">
<td><code>maxRetries</code></td>
<td><code>int32</code></td>
<td>
<p>Maximum number of retries that can be outstanding to all hosts in a
cluster at a given time. Defaults to 3.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ConnectionPoolSettings-TCPSettings">ConnectionPoolSettings.TCPSettings</h2>
<section>
<p>Settings common to both HTTP and TCP upstream connections.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ConnectionPoolSettings-TCPSettings-max_connections">
<td><code>maxConnections</code></td>
<td><code>int32</code></td>
<td>
<p>Maximum number of HTTP1 /TCP connections to a destination host.</p>
</td>
</tr>
<tr id="ConnectionPoolSettings-TCPSettings-connect_timeout">
<td><code>connectTimeout</code></td>
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration">google.protobuf.Duration</a></code></td>
<td>
<p>TCP connection timeout.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="CorsPolicy">CorsPolicy</h2>
<section>
<p>Describes the Cross-Origin Resource Sharing (CORS) policy, for a given
service. Refer to
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access<em>control</em>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.</p>
<pre><code class="language-yaml">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: &quot;1d&quot;
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="CorsPolicy-allow_origin">
<td><code>allowOrigin</code></td>
<td><code>string[]</code></td>
<td>
<p>The list of origins that are allowed to perform CORS requests. The
content will be serialized into the Access-Control-Allow-Origin
header. Wildcard * will allow all origins.</p>
</td>
</tr>
<tr id="CorsPolicy-allow_methods">
<td><code>allowMethods</code></td>
<td><code>string[]</code></td>
<td>
<p>List of HTTP methods allowed to access the resource. The content will
be serialized into the Access-Control-Allow-Methods header.</p>
</td>
</tr>
<tr id="CorsPolicy-allow_headers">
<td><code>allowHeaders</code></td>
<td><code>string[]</code></td>
<td>
<p>List of HTTP headers that can be used when requesting the
resource. Serialized to Access-Control-Allow-Methods header.</p>
</td>
</tr>
<tr id="CorsPolicy-expose_headers">
<td><code>exposeHeaders</code></td>
<td><code>string[]</code></td>
<td>
<p>A white list of HTTP headers that the browsers are allowed to
access. Serialized into Access-Control-Expose-Headers header.</p>
</td>
</tr>
<tr id="CorsPolicy-max_age">
<td><code>maxAge</code></td>
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration">google.protobuf.Duration</a></code></td>
<td>
<p>Specifies how long the the results of a preflight request can be
cached. Translates to the Access-Control-Max-Age header.</p>
</td>
</tr>
<tr id="CorsPolicy-allow_credentials">
<td><code>allowCredentials</code></td>
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#boolvalue">google.protobuf.BoolValue</a></code></td>
<td>
<p>Indicates whether the caller is allowed to send the actual request
(not the preflight) using credentials. Translates to
Access-Control-Allow-Credentials header.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Destination">Destination</h2>
<section>
<p>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&rsquo;s service registry is composed of all the services found
in the platform&rsquo;s service registry (e.g., Kubernetes services, Consul
services), as well as services declared through the
<a href="#ServiceEntry">ServiceEntry</a> resource.</p>
<p><em>Note for Kubernetes users</em>: When short names are used (e.g. &ldquo;reviews&rdquo;
instead of &ldquo;reviews.default.svc.cluster.local&rdquo;), Istio will interpret
the short name based on the namespace of the rule, not the service. A
rule in the &ldquo;default&rdquo; namespace containing a host &ldquo;reviews will be
interpreted as &ldquo;reviews.default.svc.cluster.local&rdquo;, irrespective of the
actual namespace associated with the reviews service. <em>To avoid potential
misconfigurations, it is recommended to always use fully qualified
domain names over short names.</em></p>
<p>The following Kubernetes example routes all traffic by default to pods
of the reviews service with label &ldquo;version: v1&rdquo; (i.e., subset v1), and
some to subset v2, in a kubernetes environment.</p>
<pre><code class="language-yaml">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: &quot;/wpcatalog&quot;
- uri:
prefix: &quot;/consumercatalog&quot;
rewrite:
uri: &quot;/newcatalog&quot;
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
</code></pre>
<p>And the associated DestinationRule</p>
<pre><code class="language-yaml">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
</code></pre>
<p>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&rsquo;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&rsquo;s namespace does
not have an impact in resolving the name of the productpage service.</p>
<pre><code class="language-yaml">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
</code></pre>
<p>To control routing for traffic bound to services outside the mesh, external
services must first be added to Istio&rsquo;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.</p>
<pre><code class="language-yaml">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
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Destination-host">
<td><code>host</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED. The name of a service from the service registry. Service
names are looked up from the platform&rsquo;s service registry (e.g.,
Kubernetes services, Consul services, etc.) and from the hosts
declared by <a href="#ServiceEntry">ServiceEntry</a>. Traffic forwarded to
destinations that are not found in either of the two, will be dropped.</p>
<p><em>Note for Kubernetes users</em>: When short names are used (e.g. &ldquo;reviews&rdquo;
instead of &ldquo;reviews.default.svc.cluster.local&rdquo;), Istio will interpret
the short name based on the namespace of the rule, not the service. A
rule in the &ldquo;default&rdquo; namespace containing a host &ldquo;reviews will be
interpreted as &ldquo;reviews.default.svc.cluster.local&rdquo;, irrespective of
the actual namespace associated with the reviews service. <em>To avoid
potential misconfigurations, it is recommended to always use fully
qualified domain names over short names.</em></p>
</td>
</tr>
<tr id="Destination-subset">
<td><code>subset</code></td>
<td><code>string</code></td>
<td>
<p>The name of a subset within the service. Applicable only to services
within the mesh. The subset must be defined in a corresponding
DestinationRule.</p>
</td>
</tr>
<tr id="Destination-port">
<td><code>port</code></td>
<td><code><a href="#PortSelector">PortSelector</a></code></td>
<td>
<p>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.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="DestinationRule">DestinationRule</h2>
<section>
<p><code>DestinationRule</code> 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:</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: bookinfo-ratings
spec:
host: ratings.prod.svc.cluster.local
trafficPolicy:
loadBalancer:
simple: LEAST_CONN
</code></pre>
<p>Version specific policies can be specified by defining a named
<code>subset</code> 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).</p>
<pre><code class="language-yaml">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
</code></pre>
<p><strong>Note:</strong> Policies specified for subsets will not take effect until
a route rule explicitly sends traffic to this subset.</p>
<p>Traffic policies can be customized to specific ports as well. The
following rule uses the least connection load balancing policy for all
traffic to port 80, while uses a round robin load balancing setting for
traffic to the port 9080.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: bookinfo-ratings-port
spec:
host: ratings.prod.svc.cluster.local
trafficPolicy: # Apply to all ports
portLevelSettings:
- port:
number: 80
loadBalancer:
simple: LEAST_CONN
- port:
number: 9080
loadBalancer:
simple: ROUND_ROBIN
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="DestinationRule-host">
<td><code>host</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED. The name of a service from the service registry. Service
names are looked up from the platform&rsquo;s service registry (e.g.,
Kubernetes services, Consul services, etc.) and from the hosts
declared by <a href="#ServiceEntry">ServiceEntries</a>. Rules defined for
services that do not exist in the service registry will be ignored.</p>
<p><em>Note for Kubernetes users</em>: When short names are used (e.g. &ldquo;reviews&rdquo;
instead of &ldquo;reviews.default.svc.cluster.local&rdquo;), Istio will interpret
the short name based on the namespace of the rule, not the service. A
rule in the &ldquo;default&rdquo; namespace containing a host &ldquo;reviews will be
interpreted as &ldquo;reviews.default.svc.cluster.local&rdquo;, irrespective of
the actual namespace associated with the reviews service. <em>To avoid
potential misconfigurations, it is recommended to always use fully
qualified domain names over short names.</em></p>
<p>Note that the host field applies to both HTTP and TCP services.</p>
</td>
</tr>
<tr id="DestinationRule-traffic_policy">
<td><code>trafficPolicy</code></td>
<td><code><a href="#TrafficPolicy">TrafficPolicy</a></code></td>
<td>
<p>Traffic policies to apply (load balancing policy, connection pool
sizes, outlier detection).</p>
</td>
</tr>
<tr id="DestinationRule-subsets">
<td><code>subsets</code></td>
<td><code><a href="#Subset">Subset[]</a></code></td>
<td>
<p>One or more named sets that represent individual versions of a
service. Traffic policies can be overridden at subset level.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="DestinationWeight">DestinationWeight</h2>
<section>
<p>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 &ldquo;reviews&rdquo; service to
instances with the &ldquo;v2&rdquo; tag and the remaining traffic (i.e., 75%) to
&ldquo;v1&rdquo;.</p>
<pre><code class="language-yaml">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
</code></pre>
<p>And the associated DestinationRule</p>
<pre><code class="language-yaml">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
</code></pre>
<p>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</p>
<pre><code class="language-yaml">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
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="DestinationWeight-destination">
<td><code>destination</code></td>
<td><code><a href="#Destination">Destination</a></code></td>
<td>
<p>REQUIRED. Destination uniquely identifies the instances of a service
to which the request/connection should be forwarded to.</p>
</td>
</tr>
<tr id="DestinationWeight-weight">
<td><code>weight</code></td>
<td><code>int32</code></td>
<td>
<p>REQUIRED. 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 destination in a rule, the weight value is assumed to
be 100.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Gateway">Gateway</h2>
<section>
<p><code>Gateway</code> 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.</p>
<p>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 <code>app: my-gateway-controller</code>. 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.</p>
<pre><code class="language-yaml">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
hosts:
- &quot;*&quot;
- port:
number: 2379 # to expose internal service via external port 2379
name: mongo
protocol: MONGO
hosts:
- &quot;*&quot;
</code></pre>
<p>The Gateway specification above describes the L4-L6 properties of a load
balancer. A <code>VirtualService</code> can then be bound to a gateway to control
the forwarding of traffic arriving at a particular host or gateway port.</p>
<p>For example, the following VirtualService splits traffic for
&ldquo;https://uk.bookinfo.com/reviews&rdquo;, &ldquo;https://eu.bookinfo.com/reviews&rdquo;,
&ldquo;http://uk.bookinfo.com:9080/reviews&rdquo;,
&ldquo;http://eu.bookinfo.com:9080/reviews&rdquo; into two versions (prod and qa) of
an internal reviews service on port 9080. In addition, requests
containing the cookie &ldquo;user: dev-123&rdquo; will be sent to special port 7777
in the qa version. The same rule is also applicable inside the mesh for
requests to the &ldquo;reviews.prod.svc.cluster.local&rdquo; service. This rule is
applicable across ports 443, 9080. Note that &ldquo;http://uk.bookinfo.com&rdquo;
gets redirected to &ldquo;https://uk.bookinfo.com&rdquo; (i.e. 80 redirects to 443).</p>
<pre><code class="language-yaml">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
</code></pre>
<p>The following VirtualService forwards traffic arriving at (external)
port 27017 from &ldquo;172.17.16.0/24&rdquo; 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 <code>mesh</code>.</p>
<pre><code class="language-yaml">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: &quot;172.17.16.0/24&quot;
route:
- destination:
name: mongo.prod.svc.cluster.local
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Gateway-servers">
<td><code>servers</code></td>
<td><code><a href="#Server">Server[]</a></code></td>
<td>
<p>REQUIRED: A list of server specifications.</p>
</td>
</tr>
<tr id="Gateway-selector">
<td><code>selector</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>One or more labels that indicate a specific set of pods/VMs
on which this gateway configuration should be applied.
The scope of label search is platform dependent.
On Kubernetes, for example, the scope includes pods running in
all reachable namespaces.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="HTTPFaultInjection">HTTPFaultInjection</h2>
<section>
<p>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.</p>
<p><em>Note:</em> Delay and abort faults are independent of one another, even if
both are specified simultaneously.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="HTTPFaultInjection-delay">
<td><code>delay</code></td>
<td><code><a href="#HTTPFaultInjection-Delay">HTTPFaultInjection.Delay</a></code></td>
<td>
<p>Delay requests before forwarding, emulating various failures such as
network issues, overloaded upstream service, etc.</p>
</td>
</tr>
<tr id="HTTPFaultInjection-abort">
<td><code>abort</code></td>
<td><code><a href="#HTTPFaultInjection-Abort">HTTPFaultInjection.Abort</a></code></td>
<td>
<p>Abort Http request attempts and return error codes back to downstream
service, giving the impression that the upstream service is faulty.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="HTTPFaultInjection-Abort">HTTPFaultInjection.Abort</h2>
<section>
<p>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 &ldquo;ratings&rdquo; service &ldquo;v1&rdquo;.</p>
<pre><code class="language-yaml">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
</code></pre>
<p>The <em>httpStatus</em> field is used to indicate the HTTP status code to
return to the caller. The optional <em>percent</em> field, a value between 0
and 100, is used to only abort a certain percentage of requests. If
not specified, all requests are aborted.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="HTTPFaultInjection-Abort-percent">
<td><code>percent</code></td>
<td><code>int32</code></td>
<td>
<p>Percentage of requests to be aborted with the error code provided (0-100).</p>
</td>
</tr>
<tr id="HTTPFaultInjection-Abort-http_status" class="oneof oneof-start">
<td><code>httpStatus</code></td>
<td><code>int32 (oneof)</code></td>
<td>
<p>REQUIRED. HTTP status code to use to abort the Http request.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="HTTPFaultInjection-Delay">HTTPFaultInjection.Delay</h2>
<section>
<p>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 &ldquo;v1&rdquo; version of the &ldquo;reviews&rdquo;
service from all pods with label env: prod</p>
<pre><code class="language-yaml">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
</code></pre>
<p>The <em>fixedDelay</em> field is used to indicate the amount of delay in
seconds. An optional <em>percent</em> 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.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="HTTPFaultInjection-Delay-percent">
<td><code>percent</code></td>
<td><code>int32</code></td>
<td>
<p>Percentage of requests on which the delay will be injected (0-100).</p>
</td>
</tr>
<tr id="HTTPFaultInjection-Delay-fixed_delay" class="oneof oneof-start">
<td><code>fixedDelay</code></td>
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration">google.protobuf.Duration (oneof)</a></code></td>
<td>
<p>REQUIRED. Add a fixed delay before forwarding the request. Format:
1h/1m/1s/1ms. MUST be &gt;=1ms.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="HTTPMatchRequest">HTTPMatchRequest</h2>
<section>
<p>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 <code>cookie</code> with value
<code>user=jason</code>.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- headers:
cookie:
regex: &quot;^(.*?;)?(user=jason)(;.*)?&quot;
uri:
prefix: &quot;/ratings/v2/&quot;
route:
- destination:
host: ratings.prod.svc.cluster.local
</code></pre>
<p>HTTPMatchRequest CANNOT be empty.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="HTTPMatchRequest-uri">
<td><code>uri</code></td>
<td><code><a href="#StringMatch">StringMatch</a></code></td>
<td>
<p>URI to match
values are case-sensitive and formatted as follows:</p>
<ul>
<li><p><code>exact: &quot;value&quot;</code> for exact string match</p></li>
<li><p><code>prefix: &quot;value&quot;</code> for prefix-based match</p></li>
<li><p><code>regex: &quot;value&quot;</code> for ECMAscript style regex-based match</p></li>
</ul>
</td>
</tr>
<tr id="HTTPMatchRequest-scheme">
<td><code>scheme</code></td>
<td><code><a href="#StringMatch">StringMatch</a></code></td>
<td>
<p>URI Scheme
values are case-sensitive and formatted as follows:</p>
<ul>
<li><p><code>exact: &quot;value&quot;</code> for exact string match</p></li>
<li><p><code>prefix: &quot;value&quot;</code> for prefix-based match</p></li>
<li><p><code>regex: &quot;value&quot;</code> for ECMAscript style regex-based match</p></li>
</ul>
</td>
</tr>
<tr id="HTTPMatchRequest-method">
<td><code>method</code></td>
<td><code><a href="#StringMatch">StringMatch</a></code></td>
<td>
<p>HTTP Method
values are case-sensitive and formatted as follows:</p>
<ul>
<li><p><code>exact: &quot;value&quot;</code> for exact string match</p></li>
<li><p><code>prefix: &quot;value&quot;</code> for prefix-based match</p></li>
<li><p><code>regex: &quot;value&quot;</code> for ECMAscript style regex-based match</p></li>
</ul>
</td>
</tr>
<tr id="HTTPMatchRequest-authority">
<td><code>authority</code></td>
<td><code><a href="#StringMatch">StringMatch</a></code></td>
<td>
<p>HTTP Authority
values are case-sensitive and formatted as follows:</p>
<ul>
<li><p><code>exact: &quot;value&quot;</code> for exact string match</p></li>
<li><p><code>prefix: &quot;value&quot;</code> for prefix-based match</p></li>
<li><p><code>regex: &quot;value&quot;</code> for ECMAscript style regex-based match</p></li>
</ul>
</td>
</tr>
<tr id="HTTPMatchRequest-headers">
<td><code>headers</code></td>
<td><code>map&lt;string,&nbsp;<a href="#StringMatch">StringMatch</a>&gt;</code></td>
<td>
<p>The header keys must be lowercase and use hyphen as the separator,
e.g. <em>x-request-id</em>.</p>
<p>Header values are case-sensitive and formatted as follows:</p>
<ul>
<li><p><code>exact: &quot;value&quot;</code> for exact string match</p></li>
<li><p><code>prefix: &quot;value&quot;</code> for prefix-based match</p></li>
<li><p><code>regex: &quot;value&quot;</code> for ECMAscript style regex-based match</p></li>
</ul>
<p><strong>Note:</strong> The keys <code>uri</code>, <code>scheme</code>, <code>method</code>, and <code>authority</code> will be ignored.</p>
</td>
</tr>
<tr id="HTTPMatchRequest-port">
<td><code>port</code></td>
<td><code>uint32</code></td>
<td>
<p>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.</p>
</td>
</tr>
<tr id="HTTPMatchRequest-source_labels">
<td><code>sourceLabels</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>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 at the top, it should include the reserved gateway
<code>mesh</code> in order for this field to be applicable.</p>
</td>
</tr>
<tr id="HTTPMatchRequest-gateways">
<td><code>gateways</code></td>
<td><code>string[]</code></td>
<td>
<p>Names of gateways where the rule should be applied to. Gateway names
at the top of the VirtualService (if any) are overridden. The gateway match is
independent of sourceLabels.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="HTTPRedirect">HTTPRedirect</h2>
<section>
<p>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.</p>
<pre><code class="language-yaml">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
...
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="HTTPRedirect-uri">
<td><code>uri</code></td>
<td><code>string</code></td>
<td>
<p>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.</p>
</td>
</tr>
<tr id="HTTPRedirect-authority">
<td><code>authority</code></td>
<td><code>string</code></td>
<td>
<p>On a redirect, overwrite the Authority/Host portion of the URL with
this value.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="HTTPRetry">HTTPRetry</h2>
<section>
<p>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.</p>
<pre><code class="language-yaml">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
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="HTTPRetry-attempts">
<td><code>attempts</code></td>
<td><code>int32</code></td>
<td>
<p>REQUIRED. Number of retries for a given request. The interval
between retries will be determined automatically (25ms+). Actual
number of retries attempted depends on the httpReqTimeout.</p>
</td>
</tr>
<tr id="HTTPRetry-per_try_timeout">
<td><code>perTryTimeout</code></td>
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration">google.protobuf.Duration</a></code></td>
<td>
<p>Timeout per retry attempt for a given request. format: 1h/1m/1s/1ms. MUST BE &gt;=1ms.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="HTTPRewrite">HTTPRewrite</h2>
<section>
<p>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.</p>
<pre><code class="language-yaml">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
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="HTTPRewrite-uri">
<td><code>uri</code></td>
<td><code>string</code></td>
<td>
<p>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.</p>
</td>
</tr>
<tr id="HTTPRewrite-authority">
<td><code>authority</code></td>
<td><code>string</code></td>
<td>
<p>rewrite the Authority/Host header with this value.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="HTTPRoute">HTTPRoute</h2>
<section>
<p>Describes match conditions and actions for routing HTTP/1.1, HTTP2, and
gRPC traffic. See VirtualService for usage examples.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="HTTPRoute-match">
<td><code>match</code></td>
<td><code><a href="#HTTPMatchRequest">HTTPMatchRequest[]</a></code></td>
<td>
<p>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.</p>
</td>
</tr>
<tr id="HTTPRoute-route">
<td><code>route</code></td>
<td><code><a href="#DestinationWeight">DestinationWeight[]</a></code></td>
<td>
<p>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.</p>
</td>
</tr>
<tr id="HTTPRoute-redirect">
<td><code>redirect</code></td>
<td><code><a href="#HTTPRedirect">HTTPRedirect</a></code></td>
<td>
<p>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 302 redirect to a different URI or Authority.</p>
</td>
</tr>
<tr id="HTTPRoute-rewrite">
<td><code>rewrite</code></td>
<td><code><a href="#HTTPRewrite">HTTPRewrite</a></code></td>
<td>
<p>Rewrite HTTP URIs and Authority headers. Rewrite cannot be used with
Redirect primitive. Rewrite will be performed before forwarding.</p>
</td>
</tr>
<tr id="HTTPRoute-websocket_upgrade">
<td><code>websocketUpgrade</code></td>
<td><code>bool</code></td>
<td>
<p>Indicates that a HTTP/1.1 client connection to this particular route
should be allowed (and expected) to upgrade to a WebSocket connection.
The default is false. Istio&rsquo;s reference sidecar implementation (Envoy)
expects the first request to this route to contain the WebSocket
upgrade headers. Otherwise, the request will be rejected. Note that
Websocket allows secondary protocol negotiation which may then be
subject to further routing rules based on the protocol selected.</p>
</td>
</tr>
<tr id="HTTPRoute-timeout">
<td><code>timeout</code></td>
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration">google.protobuf.Duration</a></code></td>
<td>
<p>Timeout for HTTP requests.</p>
</td>
</tr>
<tr id="HTTPRoute-retries">
<td><code>retries</code></td>
<td><code><a href="#HTTPRetry">HTTPRetry</a></code></td>
<td>
<p>Retry policy for HTTP requests.</p>
</td>
</tr>
<tr id="HTTPRoute-fault">
<td><code>fault</code></td>
<td><code><a href="#HTTPFaultInjection">HTTPFaultInjection</a></code></td>
<td>
<p>Fault injection policy to apply on HTTP traffic.</p>
</td>
</tr>
<tr id="HTTPRoute-mirror">
<td><code>mirror</code></td>
<td><code><a href="#Destination">Destination</a></code></td>
<td>
<p>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.</p>
</td>
</tr>
<tr id="HTTPRoute-cors_policy">
<td><code>corsPolicy</code></td>
<td><code><a href="#CorsPolicy">CorsPolicy</a></code></td>
<td>
<p>Cross-Origin Resource Sharing policy (CORS). Refer to
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access<em>control</em>CORS
for further details about cross origin resource sharing.</p>
</td>
</tr>
<tr id="HTTPRoute-append_headers">
<td><code>appendHeaders</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>Additional HTTP headers to add before forwarding a request to the
destination service.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="L4MatchAttributes">L4MatchAttributes</h2>
<section>
<p>L4 connection match attributes. Note that L4 connection matching support
is incomplete.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="L4MatchAttributes-destination_subnet">
<td><code>destinationSubnet</code></td>
<td><code>string</code></td>
<td>
<p>IPv4 or IPv6 ip address of destination with optional subnet. E.g.,
a.b.c.d/xx form or just a.b.c.d. This is only valid when the
destination service has several IPs and the application explicitly
specifies a particular IP.</p>
</td>
</tr>
<tr id="L4MatchAttributes-port">
<td><code>port</code></td>
<td><code>uint32</code></td>
<td>
<p>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.</p>
</td>
</tr>
<tr id="L4MatchAttributes-source_subnet">
<td><code>sourceSubnet</code></td>
<td><code>string</code></td>
<td>
<p>IPv4 or IPv6 ip address of source with optional subnet. E.g., a.b.c.d/xx
form or just a.b.c.d</p>
</td>
</tr>
<tr id="L4MatchAttributes-source_labels">
<td><code>sourceLabels</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>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 at the top, it should include the reserved gateway
<code>mesh</code> in order for this field to be applicable.</p>
</td>
</tr>
<tr id="L4MatchAttributes-gateways">
<td><code>gateways</code></td>
<td><code>string[]</code></td>
<td>
<p>Names of gateways where the rule should be applied to. Gateway names
at the top of the VirtualService (if any) are overridden. The gateway match is
independent of sourceLabels.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="LoadBalancerSettings">LoadBalancerSettings</h2>
<section>
<p>Load balancing policies to apply for a specific destination. See Envoy&rsquo;s
load balancing
<a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing.html">documentation</a>
for more details.</p>
<p>For example, the following rule uses a round robin load balancing policy
for all traffic going to the ratings service.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: bookinfo-ratings
spec:
host: ratings.prod.svc.cluster.local
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
</code></pre>
<p>The following example uses the consistent hashing based load balancer
for the same ratings service using the Cookie header as the hash key.</p>
<pre><code class="language-yaml"> apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: bookinfo-ratings
spec:
host: ratings.prod.svc.cluster.local
trafficPolicy:
loadBalancer:
consistentHash:
http_header: Cookie
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="LoadBalancerSettings-simple" class="oneof oneof-start">
<td><code>simple</code></td>
<td><code><a href="#LoadBalancerSettings-SimpleLB">LoadBalancerSettings.SimpleLB (oneof)</a></code></td>
<td>
</td>
</tr>
<tr id="LoadBalancerSettings-consistent_hash" class="oneof">
<td><code>consistentHash</code></td>
<td><code><a href="#LoadBalancerSettings-ConsistentHashLB">LoadBalancerSettings.ConsistentHashLB (oneof)</a></code></td>
<td>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="LoadBalancerSettings-SimpleLB">LoadBalancerSettings.SimpleLB</h2>
<section>
<p>Standard load balancing algorithms that require no tuning.</p>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="LoadBalancerSettings-SimpleLB-ROUND_ROBIN">
<td><code>ROUND_ROBIN</code></td>
<td>
<p>Round Robin policy. Default</p>
</td>
</tr>
<tr id="LoadBalancerSettings-SimpleLB-LEAST_CONN">
<td><code>LEAST_CONN</code></td>
<td>
<p>The least request load balancer uses an O(1) algorithm which selects
two random healthy hosts and picks the host which has fewer active
requests.</p>
</td>
</tr>
<tr id="LoadBalancerSettings-SimpleLB-RANDOM">
<td><code>RANDOM</code></td>
<td>
<p>The random load balancer selects a random healthy host. The random
load balancer generally performs better than round robin if no health
checking policy is configured.</p>
</td>
</tr>
<tr id="LoadBalancerSettings-SimpleLB-PASSTHROUGH">
<td><code>PASSTHROUGH</code></td>
<td>
<p>This option will forward the connection to the original IP address
requested by the caller without doing any form of load
balancing. This option must be used with care. It is meant for
advanced use cases. Refer to Original Destination load balancer in
Envoy for further details.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="OutlierDetection">OutlierDetection</h2>
<section>
<p>A Circuit breaker implementation that tracks the status of each
individual host in the upstream service. Applicable to both HTTP and
TCP services. For HTTP services, hosts that continually return 5xx
errors for API calls are ejected from the pool for a pre-defined period
of time. For TCP services, connection timeouts or connection
failures to a given host counts as an error when measuring the
consecutive errors metric. See Envoy&rsquo;s <a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/outlier">outlier
detection</a>
for more details.</p>
<p>The following rule sets a connection pool size of 100 connections and
1000 concurrent HTTP2 requests, with no more than 10 req/connection to
&ldquo;reviews&rdquo; 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.</p>
<pre><code class="language-yaml">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:
consecutiveErrors: 7
interval: 5m
baseEjectionTime: 15m
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="OutlierDetection-consecutive_errors">
<td><code>consecutiveErrors</code></td>
<td><code>int32</code></td>
<td>
<p>Number of errors before a host is ejected from the connection
pool. Defaults to 5. When the upstream host is accessed over HTTP, a
5xx return code qualifies as an error. When the upstream host is
accessed over an opaque TCP connection, connect timeouts and
connection error/failure events qualify as an error.</p>
</td>
</tr>
<tr id="OutlierDetection-interval">
<td><code>interval</code></td>
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration">google.protobuf.Duration</a></code></td>
<td>
<p>Time interval between ejection sweep analysis. format:
1h/1m/1s/1ms. MUST BE &gt;=1ms. Default is 10s.</p>
</td>
</tr>
<tr id="OutlierDetection-base_ejection_time">
<td><code>baseEjectionTime</code></td>
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration">google.protobuf.Duration</a></code></td>
<td>
<p>Minimum ejection duration. A host will remain ejected for a period
equal to the product of minimum ejection duration and the number of
times the host has been ejected. This technique allows the system to
automatically increase the ejection period for unhealthy upstream
servers. format: 1h/1m/1s/1ms. MUST BE &gt;=1ms. Default is 30s.</p>
</td>
</tr>
<tr id="OutlierDetection-max_ejection_percent">
<td><code>maxEjectionPercent</code></td>
<td><code>int32</code></td>
<td>
<p>Maximum % of hosts in the load balancing pool for the upstream
service that can be ejected. Defaults to 10%.</p>
</td>
</tr>
<tr id="OutlierDetection-http">
<td><code>http</code></td>
<td><code><a href="#OutlierDetection-HTTPSettings">OutlierDetection.HTTPSettings</a></code></td>
<td>
<p>DEPRECATED.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="OutlierDetection-HTTPSettings">OutlierDetection.HTTPSettings</h2>
<section>
<p>Outlier detection settings for HTTP1.1/HTTP2/GRPC connections.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="OutlierDetection-HTTPSettings-consecutive_errors">
<td><code>consecutiveErrors</code></td>
<td><code>int32</code></td>
<td>
<p>Number of 5XX errors before a host is ejected from the connection
pool. Defaults to 5.</p>
</td>
</tr>
<tr id="OutlierDetection-HTTPSettings-interval">
<td><code>interval</code></td>
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration">google.protobuf.Duration</a></code></td>
<td>
<p>Time interval between ejection sweep analysis. format:
1h/1m/1s/1ms. MUST BE &gt;=1ms. Default is 10s.</p>
</td>
</tr>
<tr id="OutlierDetection-HTTPSettings-base_ejection_time">
<td><code>baseEjectionTime</code></td>
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration">google.protobuf.Duration</a></code></td>
<td>
<p>Minimum ejection duration. A host will remain ejected for a period
equal to the product of minimum ejection duration and the number of
times the host has been ejected. This technique allows the system to
automatically increase the ejection period for unhealthy upstream
servers. format: 1h/1m/1s/1ms. MUST BE &gt;=1ms. Default is 30s.</p>
</td>
</tr>
<tr id="OutlierDetection-HTTPSettings-max_ejection_percent">
<td><code>maxEjectionPercent</code></td>
<td><code>int32</code></td>
<td>
<p>Maximum % of hosts in the load balancing pool for the upstream
service that can be ejected. Defaults to 10%.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Port">Port</h2>
<section>
<p>Port describes the properties of a specific port of a service.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Port-number">
<td><code>number</code></td>
<td><code>uint32</code></td>
<td>
<p>REQUIRED: A valid non-negative integer port number.</p>
</td>
</tr>
<tr id="Port-protocol">
<td><code>protocol</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED: The protocol exposed on the port.
MUST BE one of HTTP|HTTPS|GRPC|HTTP2|MONGO|TCP|TCP-TLS.
TCP-TLS is used to indicate secure connections to non HTTP services.</p>
</td>
</tr>
<tr id="Port-name">
<td><code>name</code></td>
<td><code>string</code></td>
<td>
<p>Label assigned to the port.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="PortSelector">PortSelector</h2>
<section>
<p>PortSelector specifies the number of a port to be used for
matching or selection for final routing.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="PortSelector-number" class="oneof oneof-start">
<td><code>number</code></td>
<td><code>uint32 (oneof)</code></td>
<td>
<p>Valid port number</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Server">Server</h2>
<section>
<p><code>Server</code> describes the properties of the proxy on a given load balancer
port. For example,</p>
<pre><code class="language-yaml">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
hosts:
- &quot;*&quot;
</code></pre>
<p>Another example</p>
<pre><code class="language-yaml">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
hosts:
- &quot;*&quot;
</code></pre>
<p>The following is an example of TLS configuration for port 443</p>
<pre><code class="language-yaml">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
hosts:
- &quot;*&quot;
tls:
mode: SIMPLE
serverCertificate: /etc/certs/server.pem
privateKey: /etc/certs/privatekey.pem
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Server-port">
<td><code>port</code></td>
<td><code><a href="#Port">Port</a></code></td>
<td>
<p>REQUIRED: The Port on which the proxy should listen for incoming
connections</p>
</td>
</tr>
<tr id="Server-hosts">
<td><code>hosts</code></td>
<td><code>string[]</code></td>
<td>
<p>REQUIRED. A list of hosts exposed by this gateway. At least one
host is required. While typically applicable to
HTTP services, it can also be used for TCP services using TLS with
SNI. May contain a wildcard prefix for the bottom-level component of
a domain name. For example <code>*.foo.com</code> matches <code>bar.foo.com</code>
and <code>*.com</code> matches <code>bar.foo.com</code>, <code>example.com</code>, and so on.</p>
<p><strong>Note</strong>: A <code>VirtualService</code> that is bound to a gateway must have one
or more hosts that match the hosts specified in a server. The match
could be an exact match or a suffix match with the server&rsquo;s hosts. For
example, if the server&rsquo;s hosts specifies &ldquo;*.example.com&rdquo;,
VirtualServices with hosts dev.example.com, prod.example.com will
match. However, VirtualServices with hosts example.com or
newexample.com will not match.</p>
</td>
</tr>
<tr id="Server-tls">
<td><code>tls</code></td>
<td><code><a href="#Server-TLSOptions">Server.TLSOptions</a></code></td>
<td>
<p>Set of TLS related options that govern the server&rsquo;s behavior. Use
these options to control if all http requests should be redirected to
https, and the TLS modes to use.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Server-TLSOptions">Server.TLSOptions</h2>
<section>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Server-TLSOptions-https_redirect">
<td><code>httpsRedirect</code></td>
<td><code>bool</code></td>
<td>
<p>If set to true, the load balancer will send a 302 redirect for all
http connections, asking the clients to use HTTPS.</p>
</td>
</tr>
<tr id="Server-TLSOptions-mode">
<td><code>mode</code></td>
<td><code><a href="#Server-TLSOptions-TLSmode">Server.TLSOptions.TLSmode</a></code></td>
<td>
<p>Optional: Indicates whether connections to this port should be
secured using TLS. The value of this field determines how TLS is
enforced.</p>
</td>
</tr>
<tr id="Server-TLSOptions-server_certificate">
<td><code>serverCertificate</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED if mode is <code>SIMPLE</code> or <code>MUTUAL</code>. The path to the file
holding the server-side TLS certificate to use.</p>
</td>
</tr>
<tr id="Server-TLSOptions-private_key">
<td><code>privateKey</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED if mode is <code>SIMPLE</code> or <code>MUTUAL</code>. The path to the file
holding the server&rsquo;s private key.</p>
</td>
</tr>
<tr id="Server-TLSOptions-ca_certificates">
<td><code>caCertificates</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED if mode is <code>MUTUAL</code>. The path to a file containing
certificate authority certificates to use in verifying a presented
client side certificate.</p>
</td>
</tr>
<tr id="Server-TLSOptions-subject_alt_names">
<td><code>subjectAltNames</code></td>
<td><code>string[]</code></td>
<td>
<p>A list of alternate names to verify the subject identity in the
certificate presented by the client.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Server-TLSOptions-TLSmode">Server.TLSOptions.TLSmode</h2>
<section>
<p>TLS modes enforced by the proxy</p>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Server-TLSOptions-TLSmode-PASSTHROUGH">
<td><code>PASSTHROUGH</code></td>
<td>
<p>Forward the connection to the upstream server selected based on
the SNI string presented by the client.</p>
</td>
</tr>
<tr id="Server-TLSOptions-TLSmode-SIMPLE">
<td><code>SIMPLE</code></td>
<td>
<p>Secure connections with standard TLS semantics.</p>
</td>
</tr>
<tr id="Server-TLSOptions-TLSmode-MUTUAL">
<td><code>MUTUAL</code></td>
<td>
<p>Secure connections to the upstream using mutual TLS by presenting
client certificates for authentication.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ServiceEntry">ServiceEntry</h2>
<section>
<p><code>ServiceEntry</code> enables adding additional entries into Istio&rsquo;s internal
service registry, so that auto-discovered services in the mesh can
access/route to these manually specified services. A service entry
describes the properties of a service (DNS name, VIPs ,ports, protocols,
endpoints). These services could be external to the mesh (e.g., web
APIs) or mesh-internal services that are not part of the platform&rsquo;s
service registry (e.g., a set of VMs talking to services in Kubernetes).</p>
<p>The following configuration adds a set of MongoDB instances running on
unmanaged VMs to Istio&rsquo;s registry, so that these services can be treated
as any other service in the mesh. The associated DestinationRule is used
to initiate mTLS connections to the database instances.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-mongocluster
spec:
hosts:
- mymongodb.somedomain # not used
addresses:
- 192.192.192.192/24 # VIPs
ports:
- number: 27018
name: mongodb
protocol: MONGO
location: MESH_INTERNAL
resolution: STATIC
endpoints:
- address: 2.2.2.2
- address: 3.3.3.3
</code></pre>
<p>and the associated DestinationRule</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: mtls-mongocluster
spec:
host: mymongodb.somedomain
trafficPolicy:
tls:
mode: MUTUAL
clientCertificate: /etc/certs/myclientcert.pem
privateKey: /etc/certs/client_private_key.pem
caCertificates: /etc/certs/rootcacerts.pem
</code></pre>
<p>The following example demonstrates the use of wildcards in the hosts for
external services. 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 <code>NONE</code>.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-wildcard-example
spec:
hosts:
- &quot;*.bar.com&quot;
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: NONE
</code></pre>
<p>The following example demonstrates a service that is available via a
Unix Domain Socket on the host of the client. The resolution must be
set to STATIC to use unix address endpoints.</p>
<pre><code>apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: unix-domain-socket-example
spec:
hosts:
- &quot;example.unix.local&quot;
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: STATIC
endpoints:
- address: unix:///var/run/example/socket
</code></pre>
<p>For HTTP based services, it is possible to create a VirtualService
backed by multiple DNS addressable 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 external
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</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-dns
spec:
hosts:
- foo.bar.com
location: MESH_EXTERNAL
ports:
- number: 443
name: https
protocol: HTTP
resolution: 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
</code></pre>
<p>and a DestinationRule to initiate TLS connections to the ServiceEntry.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: tls-foobar
spec:
host: foo.bar.com
trafficPolicy:
tls:
mode: SIMPLE # initiates HTTPS
</code></pre>
<p>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.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ServiceEntry-hosts">
<td><code>hosts</code></td>
<td><code>string[]</code></td>
<td>
<p>REQUIRED. The hosts associated with the ServiceEntry. Could be a DNS
name with wildcard prefix (external services only). DNS names in hosts
will be ignored if the application accesses the service over non-HTTP
protocols such as mongo/opaque TCP/even HTTPS. In such scenarios, the
IP addresses specified in the Addresses field or the port will be used
to uniquely identify the destination.</p>
</td>
</tr>
<tr id="ServiceEntry-addresses">
<td><code>addresses</code></td>
<td><code>string[]</code></td>
<td>
<p>The virtual IP addresses associated with the service. Could be CIDR
prefix. For HTTP services, the addresses field will be ignored and
the destination will be identified based on the HTTP Host/Authority
header. For non-HTTP protocols such as mongo/opaque TCP/even HTTPS,
the hosts will be ignored. If one or more IP addresses are specified,
the incoming traffic will be idenfified as belonging to this service
if the destination IP matches the IP/CIDRs specified in the addresses
field. If the Addresses field is empty, traffic will be identified
solely based on the destination port. In such scenarios, the port on
which the service is being accessed must not be shared by any other
service in the mesh. In other words, the sidecar will behave as a
simple TCP proxy, forwarding incoming traffic on a specified port to
the specified destination endpoint IP/host. Unix domain socket
addresses are not supported in this field.</p>
</td>
</tr>
<tr id="ServiceEntry-ports">
<td><code>ports</code></td>
<td><code><a href="#Port">Port[]</a></code></td>
<td>
<p>REQUIRED. The ports associated with the external service. If the
Endpoints are unix domain socket addresses, there must be exactly one
port.</p>
</td>
</tr>
<tr id="ServiceEntry-location">
<td><code>location</code></td>
<td><code><a href="#ServiceEntry-Location">ServiceEntry.Location</a></code></td>
<td>
<p>Specify whether the service should be considered external to the mesh
or part of the mesh.</p>
</td>
</tr>
<tr id="ServiceEntry-resolution">
<td><code>resolution</code></td>
<td><code><a href="#ServiceEntry-Resolution">ServiceEntry.Resolution</a></code></td>
<td>
<p>Service discovery mode for the hosts. If not set, Istio will attempt
to infer the discovery mode based on the value of hosts and endpoints.</p>
</td>
</tr>
<tr id="ServiceEntry-endpoints">
<td><code>endpoints</code></td>
<td><code><a href="#ServiceEntry-Endpoint">ServiceEntry.Endpoint[]</a></code></td>
<td>
<p>One or more endpoints associated with the service.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ServiceEntry-Endpoint">ServiceEntry.Endpoint</h2>
<section>
<p>Endpoint defines a network address (IP or hostname) associated with
the mesh service.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ServiceEntry-Endpoint-address">
<td><code>address</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED: Address associated with the network endpoint without the
port. Domain names can be used if and only if the resolution is set
to DNS, and must be fully-qualified without wildcards. Use the form
unix:///absolute/path/to/socket for unix domain socket endpoints.</p>
</td>
</tr>
<tr id="ServiceEntry-Endpoint-ports">
<td><code>ports</code></td>
<td><code>map&lt;string,&nbsp;uint32&gt;</code></td>
<td>
<p>Set of ports associated with the endpoint. The ports must be
associated with a port name that was declared as part of the
service. Do not use for unix:// addresses.</p>
</td>
</tr>
<tr id="ServiceEntry-Endpoint-labels">
<td><code>labels</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>One or more labels associated with the endpoint.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ServiceEntry-Location">ServiceEntry.Location</h2>
<section>
<p>Location specifies whether the service is part of Istio mesh or
outside the mesh. Location determines the behavior of several
features, such as service-to-service mTLS authentication, policy
enforcement, etc. When communicating with services outside the mesh,
Istio&rsquo;s mTLS authentication is disabled, and policy enforcement is
performed on the client-side as opposed to server-side.</p>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ServiceEntry-Location-MESH_EXTERNAL">
<td><code>MESH_EXTERNAL</code></td>
<td>
<p>Signifies that the service is external to the mesh. Typically used
to indicate external services consumed through APIs.</p>
</td>
</tr>
<tr id="ServiceEntry-Location-MESH_INTERNAL">
<td><code>MESH_INTERNAL</code></td>
<td>
<p>Signifies that the service is part of the mesh. Typically used to
indicate services added explicitly as part of expanding the service
mesh to include unmanaged infrastructure (e.g., VMs added to a
Kubernetes based service mesh).</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ServiceEntry-Resolution">ServiceEntry.Resolution</h2>
<section>
<p>Resolution determines how the proxy will resolve the IP addresses of
the network endpoints associated with the service, so that it can
route to one of them. The resolution mode specified here has no impact
on how the application resolves the IP address associated with the
service. The application may still have to use DNS to resolve the
service to an IP so that the outbound traffic can be captured by the
Proxy. Alternatively, for HTTP services, the application could
directly communicate with the proxy (e.g., by setting HTTP_PROXY) to
talk to these services.</p>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ServiceEntry-Resolution-NONE">
<td><code>NONE</code></td>
<td>
<p>Assume that incoming connections have already been resolved (to a
specific destination IP address). Such connections are typically
routed via the proxy using mechanisms such as IP table REDIRECT/
eBPF. After performing any routing related transformations, the
proxy will forward the connection to the IP address to which the
connection was bound.</p>
</td>
</tr>
<tr id="ServiceEntry-Resolution-STATIC">
<td><code>STATIC</code></td>
<td>
<p>Use the static IP addresses specified in endpoints (see below) as the
backing instances associated with the service.</p>
</td>
</tr>
<tr id="ServiceEntry-Resolution-DNS">
<td><code>DNS</code></td>
<td>
<p>Attempt to resolve the IP address by querying the ambient DNS,
during request processing. If no endpoints are specified, the proxy
will resolve the DNS address specified in the hosts field, if
wildcards are not used. If endpoints are specified, the DNS
addresses specified in the endpoints will be resolved to determine
the destination IP address. DNS resolution cannot be used with unix
domain socket endpoints.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="StringMatch">StringMatch</h2>
<section>
<p>Describes how to match a given string in HTTP headers. Match is
case-sensitive.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="StringMatch-exact" class="oneof oneof-start">
<td><code>exact</code></td>
<td><code>string (oneof)</code></td>
<td>
<p>exact string match</p>
</td>
</tr>
<tr id="StringMatch-prefix" class="oneof">
<td><code>prefix</code></td>
<td><code>string (oneof)</code></td>
<td>
<p>prefix-based match</p>
</td>
</tr>
<tr id="StringMatch-regex" class="oneof">
<td><code>regex</code></td>
<td><code>string (oneof)</code></td>
<td>
<p>ECMAscript style regex-based match</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Subset">Subset</h2>
<section>
<p>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 <a href="#VirtualService">VirtualService</a> 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).</p>
<pre><code class="language-yaml">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
</code></pre>
<p><strong>Note:</strong> Policies specified for subsets will not take effect until
a route rule explicitly sends traffic to this subset.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Subset-name">
<td><code>name</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED. Name of the subset. The service name and the subset name can
be used for traffic splitting in a route rule.</p>
</td>
</tr>
<tr id="Subset-labels">
<td><code>labels</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>REQUIRED. Labels apply a filter over the endpoints of a service in the
service registry. See route rules for examples of usage.</p>
</td>
</tr>
<tr id="Subset-traffic_policy">
<td><code>trafficPolicy</code></td>
<td><code><a href="#TrafficPolicy">TrafficPolicy</a></code></td>
<td>
<p>Traffic policies that apply to this subset. Subsets inherit the
traffic policies specified at the DestinationRule level. Settings
specified at the subset level will override the corresponding settings
specified at the DestinationRule level.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="TCPRoute">TCPRoute</h2>
<section>
<p>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.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo-Mongo
spec:
hosts:
- mongo.prod.svc.cluster.local
tcp:
- match:
- port: 27017
sourceSubnet: &quot;172.17.16.0/24&quot;
route:
- destination:
host: mongo.backup.svc.cluster.local
port:
number: 5555
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="TCPRoute-match">
<td><code>match</code></td>
<td><code><a href="#L4MatchAttributes">L4MatchAttributes[]</a></code></td>
<td>
<p>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.</p>
</td>
</tr>
<tr id="TCPRoute-route">
<td><code>route</code></td>
<td><code><a href="#DestinationWeight">DestinationWeight[]</a></code></td>
<td>
<p>The destination to which the connection should be forwarded to.
Currently, only one destination is allowed for TCP services. When TCP
weighted routing support is introduced in Envoy, multiple destinations
with weights can be specified.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="TLSSettings">TLSSettings</h2>
<section>
<p>SSL/TLS related settings for upstream connections. See Envoy&rsquo;s <a href="https://www.envoyproxy.io/docs/envoy/latest/api-v1/cluster_manager/cluster_ssl.html#config-cluster-manager-cluster-ssl">TLS
context</a>
for more details. These settings are common to both HTTP and TCP upstreams.</p>
<p>For example, the following rule configures a client to use mutual TLS
for connections to upstream database cluster.</p>
<pre><code class="language-yaml">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
</code></pre>
<p>The following rule configures a client to use TLS when talking to a
foreign service whose domain matches *.foo.com.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: tls-foo
spec:
host: &quot;*.foo.com&quot;
trafficPolicy:
tls:
mode: SIMPLE
</code></pre>
<p>The following rule configures a client to use Istio mutual TLS when talking
to rating services.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: ratings-istio-mtls
spec:
host: ratings.prod.svc.cluster.local
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="TLSSettings-mode">
<td><code>mode</code></td>
<td><code><a href="#TLSSettings-TLSmode">TLSSettings.TLSmode</a></code></td>
<td>
<p>REQUIRED: Indicates whether connections to this port should be secured
using TLS. The value of this field determines how TLS is enforced.</p>
</td>
</tr>
<tr id="TLSSettings-client_certificate">
<td><code>clientCertificate</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED if mode is <code>MUTUAL</code>. The path to the file holding the
client-side TLS certificate to use.
Should be empty if mode is <code>ISTIO_MUTUAL</code>.</p>
</td>
</tr>
<tr id="TLSSettings-private_key">
<td><code>privateKey</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED if mode is <code>MUTUAL</code>. The path to the file holding the
client&rsquo;s private key.
Should be empty if mode is <code>ISTIO_MUTUAL</code>.</p>
</td>
</tr>
<tr id="TLSSettings-ca_certificates">
<td><code>caCertificates</code></td>
<td><code>string</code></td>
<td>
<p>OPTIONAL: The path to the file containing certificate authority
certificates to use in verifying a presented server certificate. If
omitted, the proxy will not verify the server&rsquo;s certificate.
Should be empty if mode is <code>ISTIO_MUTUAL</code>.</p>
</td>
</tr>
<tr id="TLSSettings-subject_alt_names">
<td><code>subjectAltNames</code></td>
<td><code>string[]</code></td>
<td>
<p>A list of alternate names to verify the subject identity in the
certificate. If specified, the proxy will verify that the server
certificate&rsquo;s subject alt name matches one of the specified values.
Should be empty if mode is <code>ISTIO_MUTUAL</code>.</p>
</td>
</tr>
<tr id="TLSSettings-sni">
<td><code>sni</code></td>
<td><code>string</code></td>
<td>
<p>SNI string to present to the server during TLS handshake.
Should be empty if mode is <code>ISTIO_MUTUAL</code>.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="TLSSettings-TLSmode">TLSSettings.TLSmode</h2>
<section>
<p>TLS connection mode</p>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="TLSSettings-TLSmode-DISABLE">
<td><code>DISABLE</code></td>
<td>
<p>Do not setup a TLS connection to the upstream endpoint.</p>
</td>
</tr>
<tr id="TLSSettings-TLSmode-SIMPLE">
<td><code>SIMPLE</code></td>
<td>
<p>Originate a TLS connection to the upstream endpoint.</p>
</td>
</tr>
<tr id="TLSSettings-TLSmode-MUTUAL">
<td><code>MUTUAL</code></td>
<td>
<p>Secure connections to the upstream using mutual TLS by presenting
client certificates for authentication.</p>
</td>
</tr>
<tr id="TLSSettings-TLSmode-ISTIO_MUTUAL">
<td><code>ISTIO_MUTUAL</code></td>
<td>
<p>Secure connections to the upstream using mutual TLS by presenting
client certificates for authentication.
Compared to Mutual mode, this mode uses certificates generated
automatically by Istio for mTLS authentication. When this mode is
used, all other fields in <code>TLSSettings</code> should be empty.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="TrafficPolicy">TrafficPolicy</h2>
<section>
<p>Traffic policies to apply for a specific destination, across all
destination ports. See DestinationRule for examples.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="TrafficPolicy-load_balancer">
<td><code>loadBalancer</code></td>
<td><code><a href="#LoadBalancerSettings">LoadBalancerSettings</a></code></td>
<td>
<p>Settings controlling the load balancer algorithms.</p>
</td>
</tr>
<tr id="TrafficPolicy-connection_pool">
<td><code>connectionPool</code></td>
<td><code><a href="#ConnectionPoolSettings">ConnectionPoolSettings</a></code></td>
<td>
<p>Settings controlling the volume of connections to an upstream service</p>
</td>
</tr>
<tr id="TrafficPolicy-outlier_detection">
<td><code>outlierDetection</code></td>
<td><code><a href="#OutlierDetection">OutlierDetection</a></code></td>
<td>
<p>Settings controlling eviction of unhealthy hosts from the load balancing pool</p>
</td>
</tr>
<tr id="TrafficPolicy-tls">
<td><code>tls</code></td>
<td><code><a href="#TLSSettings">TLSSettings</a></code></td>
<td>
<p>TLS related settings for connections to the upstream service.</p>
</td>
</tr>
<tr id="TrafficPolicy-port_level_settings">
<td><code>portLevelSettings</code></td>
<td><code><a href="#TrafficPolicy-PortTrafficPolicy">TrafficPolicy.PortTrafficPolicy[]</a></code></td>
<td>
<p>Traffic policies specific to individual ports. Note that port level
settings will override the destination-level settings. Traffic
settings specified at the destination-level will not be inherited when
overridden by port-level settings, i.e. default values will be applied
to fields omitted in port-level traffic policies.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="TrafficPolicy-PortTrafficPolicy">TrafficPolicy.PortTrafficPolicy</h2>
<section>
<p>Traffic policies that apply to specific ports of the service</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="TrafficPolicy-PortTrafficPolicy-port">
<td><code>port</code></td>
<td><code><a href="#PortSelector">PortSelector</a></code></td>
<td>
<p>Specifies the port name or number of a port on the destination service
on which this policy is being applied.</p>
<p>Names must comply with DNS label syntax (rfc1035) and therefore cannot
collide with numbers. If there are multiple ports on a service with
the same protocol the names should be of the form <protocol-name>-<DNS
label>.</p>
</td>
</tr>
<tr id="TrafficPolicy-PortTrafficPolicy-load_balancer">
<td><code>loadBalancer</code></td>
<td><code><a href="#LoadBalancerSettings">LoadBalancerSettings</a></code></td>
<td>
<p>Settings controlling the load balancer algorithms.</p>
</td>
</tr>
<tr id="TrafficPolicy-PortTrafficPolicy-connection_pool">
<td><code>connectionPool</code></td>
<td><code><a href="#ConnectionPoolSettings">ConnectionPoolSettings</a></code></td>
<td>
<p>Settings controlling the volume of connections to an upstream service</p>
</td>
</tr>
<tr id="TrafficPolicy-PortTrafficPolicy-outlier_detection">
<td><code>outlierDetection</code></td>
<td><code><a href="#OutlierDetection">OutlierDetection</a></code></td>
<td>
<p>Settings controlling eviction of unhealthy hosts from the load balancing pool</p>
</td>
</tr>
<tr id="TrafficPolicy-PortTrafficPolicy-tls">
<td><code>tls</code></td>
<td><code><a href="#TLSSettings">TLSSettings</a></code></td>
<td>
<p>TLS related settings for connections to the upstream service.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="VirtualService">VirtualService</h2>
<section>
<p>A <code>VirtualService</code> 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.</p>
<p>The source of traffic can also be matched in a routing rule. This allows routing
to be customized for specific client contexts.</p>
<p>The following example on Kubernetes, routes all HTTP traffic by default to
pods of the reviews service with label &ldquo;version: v1&rdquo;. In addition,
HTTP requests containing /wpcatalog/, /consumercatalog/ url prefixes will
be rewritten to /newcatalog and sent to pods with label &ldquo;version: v2&rdquo;.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews.prod.svc.cluster.local
http:
- match:
- uri:
prefix: &quot;/wpcatalog&quot;
- uri:
prefix: &quot;/consumercatalog&quot;
rewrite:
uri: &quot;/newcatalog&quot;
route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v2
- route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v1
</code></pre>
<p>A subset/version of a route destination is identified with a reference
to a named service subset which must be declared in a corresponding
<code>DestinationRule</code>.</p>
<pre><code class="language-yaml">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
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="VirtualService-hosts">
<td><code>hosts</code></td>
<td><code>string[]</code></td>
<td>
<p>REQUIRED. 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.</p>
<p><strong>A host name can be defined by only one VirtualService</strong>. A single
VirtualService can be used to describe traffic properties for multiple
HTTP and TCP ports.</p>
<p><em>Note for Kubernetes users</em>: When short names are used (e.g. &ldquo;reviews&rdquo;
instead of &ldquo;reviews.default.svc.cluster.local&rdquo;), Istio will interpret
the short name based on the namespace of the rule, not the service. A
rule in the &ldquo;default&rdquo; namespace containing a host &ldquo;reviews will be
interpreted as &ldquo;reviews.default.svc.cluster.local&rdquo;, irrespective of
the actual namespace associated with the reviews service. <em>To avoid
potential misconfigurations, it is recommended to always use fully
qualified domain names over short names.</em></p>
<p>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.</p>
</td>
</tr>
<tr id="VirtualService-gateways">
<td><code>gateways</code></td>
<td><code>string[]</code></td>
<td>
<p>The names of gateways and sidecars that should apply these routes. 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 HTTP/TCP
routes. The reserved word <code>mesh</code> is used to imply all the sidecars in
the mesh. When this field is omitted, the default gateway (<code>mesh</code>)
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 <code>mesh</code> as one of the gateway names.</p>
</td>
</tr>
<tr id="VirtualService-http">
<td><code>http</code></td>
<td><code><a href="#HTTPRoute">HTTPRoute[]</a></code></td>
<td>
<p>An ordered list of route rules for HTTP traffic.
The first rule matching an incoming request is used.</p>
</td>
</tr>
<tr id="VirtualService-tcp">
<td><code>tcp</code></td>
<td><code><a href="#TCPRoute">TCPRoute[]</a></code></td>
<td>
<p>An ordered list of route rules for TCP traffic.
The first rule matching an incoming request is used.</p>
</td>
</tr>
</tbody>
</table>
</section>
Reference in New Issue View Git Blame Copy Permalink