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/index.html

4436 lines
126 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
title: Traffic Routing
description: Configuration affecting traffic routing.
location: https://istio.io/docs/reference/config/istio.networking.v1alpha3.html
layout: protoc-gen-docs
generator: protoc-gen-docs
aliases:
- /docs/reference/config/istio.routing.v1alpha1/
number_of_entries: 59
---
<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="ConfigScope">ConfigScope</h2>
<section>
<p>ConfigScope defines the visibility of an Istio configuration artifact in
a namespace when the namespace is imported. By default all
configuration artifacts are public. Configurations with private scope
will not be imported when the namespace containing the configuration is
imported in a ServiceDependency.</p>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ConfigScope-PUBLIC">
<td><code>PUBLIC</code></td>
<td>
<p>Config with this scope are visible to all workloads in the mesh</p>
</td>
</tr>
<tr id="ConfigScope-PRIVATE">
<td><code>PRIVATE</code></td>
<td>
<p>Configs with this scope are visible to only workloads in the same
namespace as the configuration resource.</p>
</td>
</tr>
</tbody>
</table>
</section>
<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
tcpKeepalive:
time: 7200s
interval: 75s
</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>
<tr id="ConnectionPoolSettings-TCPSettings-tcp_keepalive">
<td><code>tcpKeepalive</code></td>
<td><code><a href="#ConnectionPoolSettings-TCPSettings-TcpKeepalive">ConnectionPoolSettings.TCPSettings.TcpKeepalive</a></code></td>
<td>
<p>If set then set SO_KEEPALIVE on the socket to enable TCP Keepalives.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ConnectionPoolSettings-TCPSettings-TcpKeepalive">ConnectionPoolSettings.TCPSettings.TcpKeepalive</h2>
<section>
<p>TCP keepalive.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ConnectionPoolSettings-TCPSettings-TcpKeepalive-probes">
<td><code>probes</code></td>
<td><code>uint32</code></td>
<td>
<p>Maximum number of keepalive probes to send without response before
deciding the connection is dead. Default is to use the OS level configuration
(unless overridden, Linux defaults to 9.)</p>
</td>
</tr>
<tr id="ConnectionPoolSettings-TCPSettings-TcpKeepalive-time">
<td><code>time</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>The time duration a connection needs to be idle before keep-alive
probes start being sent. Default is to use the OS level configuration
(unless overridden, Linux defaults to 7200s (ie 2 hours.)</p>
</td>
</tr>
<tr id="ConnectionPoolSettings-TCPSettings-TcpKeepalive-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>The time duration between keep-alive probes.
Default is to use the OS level configuration
(unless overridden, Linux defaults to 75s.)</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-Headers 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 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>
<tr id="DestinationRule-config_scope">
<td><code>configScope</code></td>
<td><code><a href="#ConfigScope">ConfigScope</a></code></td>
<td>
<p>The visibility setting associated with this DestinationRule. Set to
PRIVATE if this destination rule should not be exported, i.e. restrict
the applicability of this destination rule to only workloads in the same
namespace as the destination rule.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter">EnvoyFilter</h2>
<section>
<p><code>EnvoyFilter</code> describes Envoy proxy-specific filters that can be used to
customize the Envoy proxy configuration generated by Istio networking
subsystem (Pilot). This feature must be used with care, as incorrect
configurations could potentially destabilize the entire mesh.</p>
<p>NOTE 1: Since this is break glass configuration, there will not be any
backward compatibility across different Istio releases. In other words,
this configuration is subject to change based on internal implementation
of Istio networking subsystem.</p>
<p>NOTE 2: When multiple EnvoyFilters are bound to the same workload, all filter
configurations will be processed sequentially in order of creation time.
The behavior is undefined if multiple EnvoyFilter configurations conflict
with each other.</p>
<p>The following example for Kubernetes enables Envoy&rsquo;s Lua filter for all
inbound calls arriving at service port 8080 of the reviews service pod with
labels &ldquo;app: reviews&rdquo;.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: reviews-lua
spec:
workloadLabels:
app: reviews
filters:
- listenerMatch:
portNumber: 8080
listenerType: SIDECAR_INBOUND #will match with the inbound listener for reviews:8080
filterName: envoy.lua
filterType: HTTP
filterConfig:
inlineCode: |
... lua code ...
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-workload_labels">
<td><code>workloadLabels</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 whose
proxies should be configured to use these additional filters. The
scope of label search is platform dependent. On Kubernetes, for
example, the scope includes pods running in all reachable
namespaces. Omitting the selector applies the filter to all proxies in
the mesh.
NOTE: There can be only one EnvoyFilter bound to a specific workload.
The behavior is undefined if multiple EnvoyFilter configurations are
specified for the same workload.</p>
</td>
</tr>
<tr id="EnvoyFilter-filters">
<td><code>filters</code></td>
<td><code><a href="#EnvoyFilter-Filter">EnvoyFilter.Filter[]</a></code></td>
<td>
<p>REQUIRED: Envoy network filters/http filters to be added to matching
listeners. When adding network filters to http connections, care
should be taken to ensure that the filter is added before
envoy.http<em>connection</em>manager.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter-Filter">EnvoyFilter.Filter</h2>
<section>
<p>Envoy filters to be added to a network or http filter chain.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-Filter-listener_match">
<td><code>listenerMatch</code></td>
<td><code><a href="#EnvoyFilter-ListenerMatch">EnvoyFilter.ListenerMatch</a></code></td>
<td>
<p>Filter will be added to the listener only if the match conditions are true.
If not specified, the filters will be applied to all listeners.</p>
</td>
</tr>
<tr id="EnvoyFilter-Filter-insert_position">
<td><code>insertPosition</code></td>
<td><code><a href="#EnvoyFilter-InsertPosition">EnvoyFilter.InsertPosition</a></code></td>
<td>
<p>Insert position in the filter chain. Defaults to FIRST</p>
</td>
</tr>
<tr id="EnvoyFilter-Filter-filter_type">
<td><code>filterType</code></td>
<td><code><a href="#EnvoyFilter-Filter-FilterType">EnvoyFilter.Filter.FilterType</a></code></td>
<td>
<p>REQUIRED: The type of filter to instantiate.</p>
</td>
</tr>
<tr id="EnvoyFilter-Filter-filter_name">
<td><code>filterName</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED: The name of the filter to instantiate. The name must match a supported
filter <em>compiled into</em> Envoy.</p>
</td>
</tr>
<tr id="EnvoyFilter-Filter-filter_config">
<td><code>filterConfig</code></td>
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#struct">google.protobuf.Struct</a></code></td>
<td>
<p>REQUIRED: Filter specific configuration which depends on the filter being
instantiated.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter-Filter-FilterType">EnvoyFilter.Filter.FilterType</h2>
<section>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-Filter-FilterType-INVALID">
<td><code>INVALID</code></td>
<td>
<p>placeholder</p>
</td>
</tr>
<tr id="EnvoyFilter-Filter-FilterType-HTTP">
<td><code>HTTP</code></td>
<td>
<p>Http filter</p>
</td>
</tr>
<tr id="EnvoyFilter-Filter-FilterType-NETWORK">
<td><code>NETWORK</code></td>
<td>
<p>Network filter</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter-InsertPosition">EnvoyFilter.InsertPosition</h2>
<section>
<p>Indicates the relative index in the filter chain where the filter should be inserted.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-InsertPosition-index">
<td><code>index</code></td>
<td><code><a href="#EnvoyFilter-InsertPosition-Index">EnvoyFilter.InsertPosition.Index</a></code></td>
<td>
<p>Position of this filter in the filter chain.</p>
</td>
</tr>
<tr id="EnvoyFilter-InsertPosition-relative_to">
<td><code>relativeTo</code></td>
<td><code>string</code></td>
<td>
<p>If BEFORE or AFTER position is specified, specify the name of the
filter relative to which this filter should be inserted.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter-InsertPosition-Index">EnvoyFilter.InsertPosition.Index</h2>
<section>
<p>Index/position in the filter chain.</p>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-InsertPosition-Index-FIRST">
<td><code>FIRST</code></td>
<td>
<p>Insert first</p>
</td>
</tr>
<tr id="EnvoyFilter-InsertPosition-Index-LAST">
<td><code>LAST</code></td>
<td>
<p>Insert last</p>
</td>
</tr>
<tr id="EnvoyFilter-InsertPosition-Index-BEFORE">
<td><code>BEFORE</code></td>
<td>
<p>Insert before the named filter.</p>
</td>
</tr>
<tr id="EnvoyFilter-InsertPosition-Index-AFTER">
<td><code>AFTER</code></td>
<td>
<p>Insert after the named filter.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter-ListenerMatch">EnvoyFilter.ListenerMatch</h2>
<section>
<p>Select a listener to add the filter to based on the match conditions.
All conditions specified in the ListenerMatch must be met for the filter
to be applied to a listener.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-ListenerMatch-port_number">
<td><code>portNumber</code></td>
<td><code>uint32</code></td>
<td>
<p>The service port/gateway port to which traffic is being
sent/received. If not specified, matches all listeners. Even though
inbound listeners are generated for the instance/pod ports, only
service ports should be used to match listeners.</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-port_name_prefix">
<td><code>portNamePrefix</code></td>
<td><code>string</code></td>
<td>
<p>Instead of using specific port numbers, a set of ports matching a
given port name prefix can be selected. E.g., &ldquo;mongo&rdquo; selects ports
named mongo-port, mongo, mongoDB, MONGO, etc. Matching is case
insensitive.</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-listener_type">
<td><code>listenerType</code></td>
<td><code><a href="#EnvoyFilter-ListenerMatch-ListenerType">EnvoyFilter.ListenerMatch.ListenerType</a></code></td>
<td>
<p>Inbound vs outbound sidecar listener or gateway listener. If not specified,
matches all listeners.</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-listener_protocol">
<td><code>listenerProtocol</code></td>
<td><code><a href="#EnvoyFilter-ListenerMatch-ListenerProtocol">EnvoyFilter.ListenerMatch.ListenerProtocol</a></code></td>
<td>
<p>Selects a class of listeners for the same protocol. If not
specified, applies to listeners on all protocols. Use the protocol
selection to select all HTTP listeners (includes HTTP2/gRPC/HTTPS
where Envoy terminates TLS) or all TCP listeners (includes HTTPS
passthrough using SNI).</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-address">
<td><code>address</code></td>
<td><code>string[]</code></td>
<td>
<p>One or more IP addresses to which the listener is bound. If
specified, should match at least one address in the list.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter-ListenerMatch-ListenerProtocol">EnvoyFilter.ListenerMatch.ListenerProtocol</h2>
<section>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-ListenerMatch-ListenerProtocol-ALL">
<td><code>ALL</code></td>
<td>
<p>All protocols</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-ListenerProtocol-HTTP">
<td><code>HTTP</code></td>
<td>
<p>HTTP or HTTPS (with termination) / HTTP2/gRPC</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-ListenerProtocol-TCP">
<td><code>TCP</code></td>
<td>
<p>Any non-HTTP listener</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="EnvoyFilter-ListenerMatch-ListenerType">EnvoyFilter.ListenerMatch.ListenerType</h2>
<section>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="EnvoyFilter-ListenerMatch-ListenerType-ANY">
<td><code>ANY</code></td>
<td>
<p>All listeners</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-ListenerType-SIDECAR_INBOUND">
<td><code>SIDECAR_INBOUND</code></td>
<td>
<p>Inbound listener in sidecar</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-ListenerType-SIDECAR_OUTBOUND">
<td><code>SIDECAR_OUTBOUND</code></td>
<td>
<p>Outbound listener in sidecar</p>
</td>
</tr>
<tr id="EnvoyFilter-ListenerMatch-ListenerType-GATEWAY">
<td><code>GATEWAY</code></td>
<td>
<p>Gateway listener</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
namespace: some-config-namespace
spec:
selector:
app: my-gateway-controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- uk.bookinfo.com
- eu.bookinfo.com
tls:
httpsRedirect: true # sends 301 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
namespace: bookinfo-namespace
spec:
hosts:
- reviews.prod.svc.cluster.local
- uk.bookinfo.com
- eu.bookinfo.com
gateways:
- some-config-namespace/my-gateway
- mesh # applies to all the sidecars in the mesh
http:
- match:
- headers:
cookie:
user: dev-123
route:
- destination:
port:
number: 7777
host: reviews.qa.svc.cluster.local
- match:
uri:
prefix: /reviews/
route:
- destination:
port:
number: 9080 # can be omitted if its the only port for reviews
host: reviews.prod.svc.cluster.local
weight: 80
- destination:
host: reviews.qa.svc.cluster.local
weight: 20
</code></pre>
<p>The following VirtualService forwards traffic arriving at (external)
port 27017 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
namespace: bookinfo-namespace
spec:
hosts:
- mongosvr.prod.svc.cluster.local #name of internal Mongo service
gateways:
- some-config-namespace/my-gateway # can omit the namespace if gateway is in same
namespace as virtual service.
tcp:
- match:
- port: 27017
route:
- destination:
host: mongo.prod.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="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>REQUIRED: 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 1 out of every 1000 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:
percentage:
value: 0.001
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>percentage</em> field can be 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" class="deprecated ">
<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).
Use of integer <code>percent</code> value is deprecated. Use the double <code>percentage</code>
field instead.</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>
<tr id="HTTPFaultInjection-Abort-percentage">
<td><code>percentage</code></td>
<td><code><a href="#Percent">Percent</a></code></td>
<td>
<p>Percentage of requests to be aborted with the error code provided.</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 1 out of every 1000 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:
percentage:
value: 0.001
fixedDelay: 5s
</code></pre>
<p>The <em>fixedDelay</em> field is used to indicate the amount of delay in seconds.
The optional <em>percentage</em> field 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" class="deprecated ">
<td><code>percent</code></td>
<td><code>int32</code></td>
<td>
<p>Percentage of requests on which the delay will be injected (0-100).
Use of integer <code>percent</code> value is deprecated. Use the double <code>percentage</code>
field instead.</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>
<tr id="HTTPFaultInjection-Delay-percentage">
<td><code>percentage</code></td>
<td><code><a href="#Percent">Percent</a></code></td>
<td>
<p>Percentage of requests on which the delay will be injected.</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 custom <code>end-user</code> header
with value <code>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:
end-user:
exact: jason
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 301 redirect response to the caller,
where the Authority/Host and the URI in the response can be swapped with
the specified values. For example, the following rule redirects
requests for /v1/getProductRatings API on the ratings service to
/v1/bookRatings provided by the bookratings service.</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
retryOn: gateway-error,connect-failure,refused-stream
</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>
<tr id="HTTPRetry-retry_on">
<td><code>retryOn</code></td>
<td><code>string</code></td>
<td>
<p>Specifies the conditions under which retry takes place.
One or more policies can be specified using a ‘,’ delimited list.
The supported policies can be found in
&ldquo;https://www.envoyproxy.io/docs/envoy/latest/configuration/http<em>filters/router</em>filter#x-envoy-retry-on&rdquo;
and &ldquo;https://www.envoyproxy.io/docs/envoy/latest/configuration/http<em>filters/router</em>filter#x-envoy-retry-grpc-on&rdquo;</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 HTTPRouteDestination. 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="#HTTPRouteDestination">HTTPRouteDestination[]</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 301 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-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 at the client side.
Note that timeouts or retries will not be enabled when faults are
enabled on the client side.</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/CORS
for further details about cross origin resource sharing.</p>
</td>
</tr>
<tr id="HTTPRoute-append_headers" class="deprecated ">
<td><code>appendHeaders</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>Use of <code>append_headers</code> is deprecated. Use the <code>headers</code>
field instead.</p>
</td>
</tr>
<tr id="HTTPRoute-remove_response_headers" class="deprecated ">
<td><code>removeResponseHeaders</code></td>
<td><code>string[]</code></td>
<td>
<p>Use of <code>remove_response_header</code> is deprecated. Use the <code>headers</code>
field instead.</p>
</td>
</tr>
<tr id="HTTPRoute-append_response_headers" class="deprecated ">
<td><code>appendResponseHeaders</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>Use of <code>append_response_headers</code> is deprecated. Use the <code>headers</code>
field instead.</p>
</td>
</tr>
<tr id="HTTPRoute-remove_request_headers" class="deprecated ">
<td><code>removeRequestHeaders</code></td>
<td><code>string[]</code></td>
<td>
<p>Use of <code>remove_request_headers</code> is deprecated. Use the <code>headers</code>
field instead.</p>
</td>
</tr>
<tr id="HTTPRoute-append_request_headers" class="deprecated ">
<td><code>appendRequestHeaders</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>Use of <code>append_request_headers</code> is deprecated. Use the <code>headers</code>
field instead.</p>
</td>
</tr>
<tr id="HTTPRoute-headers">
<td><code>headers</code></td>
<td><code><a href="#Headers">Headers</a></code></td>
<td>
<p>Header manipulation rules</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="HTTPRouteDestination">HTTPRouteDestination</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="HTTPRouteDestination-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="HTTPRouteDestination-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 one destination in a rule, the weight value is assumed to
be 100.</p>
</td>
</tr>
<tr id="HTTPRouteDestination-remove_response_headers" class="deprecated ">
<td><code>removeResponseHeaders</code></td>
<td><code>string[]</code></td>
<td>
<p>Use of <code>remove_response_header</code> is deprecated. Use the <code>headers</code>
field instead.</p>
</td>
</tr>
<tr id="HTTPRouteDestination-append_response_headers" class="deprecated ">
<td><code>appendResponseHeaders</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>Use of <code>append_response_headers</code> is deprecated. Use the <code>headers</code>
field instead.</p>
</td>
</tr>
<tr id="HTTPRouteDestination-remove_request_headers" class="deprecated ">
<td><code>removeRequestHeaders</code></td>
<td><code>string[]</code></td>
<td>
<p>Use of <code>remove_request_headers</code> is deprecated. Use the <code>headers</code>
field instead.</p>
</td>
</tr>
<tr id="HTTPRouteDestination-append_request_headers" class="deprecated ">
<td><code>appendRequestHeaders</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>Use of <code>append_request_headers</code> is deprecated. Use the <code>headers</code>
field instead.</p>
</td>
</tr>
<tr id="HTTPRouteDestination-headers">
<td><code>headers</code></td>
<td><code><a href="#Headers">Headers</a></code></td>
<td>
<p>Header manipulation rules</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Headers">Headers</h2>
<section>
<p>Header manipulation rules</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Headers-request">
<td><code>request</code></td>
<td><code><a href="#Headers-HeaderOperations">Headers.HeaderOperations</a></code></td>
<td>
<p>Header manipulation rules to apply before forwarding a request
to the destination service</p>
</td>
</tr>
<tr id="Headers-response">
<td><code>response</code></td>
<td><code><a href="#Headers-HeaderOperations">Headers.HeaderOperations</a></code></td>
<td>
<p>Header manipulation rules to apply before returning a response
to the caller</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Headers-HeaderOperations">Headers.HeaderOperations</h2>
<section>
<p>HeaderOperations Describes the header manipulations to apply</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Headers-HeaderOperations-set">
<td><code>set</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>Overwrite the headers specified by key with the given values</p>
</td>
</tr>
<tr id="Headers-HeaderOperations-add">
<td><code>add</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>Append the given values to the headers specified by keys
(will create a comma-separated list of values)</p>
</td>
</tr>
<tr id="Headers-HeaderOperations-remove">
<td><code>remove</code></td>
<td><code>string[]</code></td>
<td>
<p>Remove a the specified headers</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_subnets">
<td><code>destinationSubnets</code></td>
<td><code>string[]</code></td>
<td>
<p>IPv4 or IPv6 ip addresses of destination with optional subnet. E.g.,
a.b.c.d/xx form or just a.b.c.d.</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_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/load_balancing">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 sets up sticky sessions for the ratings service
hashing-based load balancer for the same ratings service using the
the User cookie 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:
httpCookie:
name: user
ttl: 0s
</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-ConsistentHashLB">LoadBalancerSettings.ConsistentHashLB</h2>
<section>
<p>Consistent Hash-based load balancing can be used to provide soft
session affinity based on HTTP headers, cookies or other
properties. This load balancing policy is applicable only for HTTP
connections. The affinity to a particular destination host will be
lost when one or more hosts are added/removed from the destination
service.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="LoadBalancerSettings-ConsistentHashLB-http_header_name" class="oneof oneof-start">
<td><code>httpHeaderName</code></td>
<td><code>string (oneof)</code></td>
<td>
<p>Hash based on a specific HTTP header.</p>
</td>
</tr>
<tr id="LoadBalancerSettings-ConsistentHashLB-http_cookie" class="oneof">
<td><code>httpCookie</code></td>
<td><code><a href="#LoadBalancerSettings-ConsistentHashLB-HTTPCookie">LoadBalancerSettings.ConsistentHashLB.HTTPCookie (oneof)</a></code></td>
<td>
<p>Hash based on HTTP cookie.</p>
</td>
</tr>
<tr id="LoadBalancerSettings-ConsistentHashLB-use_source_ip" class="oneof">
<td><code>useSourceIp</code></td>
<td><code>bool (oneof)</code></td>
<td>
<p>Hash based on the source IP address.</p>
</td>
</tr>
<tr id="LoadBalancerSettings-ConsistentHashLB-minimum_ring_size">
<td><code>minimumRingSize</code></td>
<td><code>uint64</code></td>
<td>
<p>The minimum number of virtual nodes to use for the hash
ring. Defaults to 1024. Larger ring sizes result in more granular
load distributions. If the number of hosts in the load balancing
pool is larger than the ring size, each host will be assigned a
single virtual node.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="LoadBalancerSettings-ConsistentHashLB-HTTPCookie">LoadBalancerSettings.ConsistentHashLB.HTTPCookie</h2>
<section>
<p>Describes a HTTP cookie that will be used as the hash key for the
Consistent Hash load balancer. If the cookie is not present, it will
be generated.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="LoadBalancerSettings-ConsistentHashLB-HTTPCookie-name">
<td><code>name</code></td>
<td><code>string</code></td>
<td>
<p>REQUIRED. Name of the cookie.</p>
</td>
</tr>
<tr id="LoadBalancerSettings-ConsistentHashLB-HTTPCookie-path">
<td><code>path</code></td>
<td><code>string</code></td>
<td>
<p>Path to set for the cookie.</p>
</td>
</tr>
<tr id="LoadBalancerSettings-ConsistentHashLB-HTTPCookie-ttl">
<td><code>ttl</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>REQUIRED. Lifetime of the cookie.</p>
</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
502, 503 or 504 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-min_health_percent">
<td><code>minHealthPercent</code></td>
<td><code>int32</code></td>
<td>
<p>Outlier detection will be enabled as long as the associated load balancing
pool has at least min<em>health</em>percent hosts in healthy mode. When the
percentage of healthy hosts in the load balancing pool drops below this
threshold, outlier detection will be disabled and the proxy will load balance
across all hosts in the pool (healthy and unhealthy). The default is 50%.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Percent">Percent</h2>
<section>
<p>Percent specifies a percentage in the range of [0.0, 100.0].</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Percent-value">
<td><code>value</code></td>
<td><code>double</code></td>
<td>
</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|TLS.
TLS implies the connection will be routed based on the SNI header to
the destination without terminating the TLS connection.</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="RouteDestination">RouteDestination</h2>
<section>
<p>L4 routing rule weighted destination.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="RouteDestination-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="RouteDestination-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. If there is only one destination in a rule, all traffic will be
routed to it irrespective of the weight.</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 301 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>
<tr id="Server-TLSOptions-min_protocol_version">
<td><code>minProtocolVersion</code></td>
<td><code><a href="#Server-TLSOptions-TLSProtocol">Server.TLSOptions.TLSProtocol</a></code></td>
<td>
<p>Optional: Minimum TLS protocol version.</p>
</td>
</tr>
<tr id="Server-TLSOptions-max_protocol_version">
<td><code>maxProtocolVersion</code></td>
<td><code><a href="#Server-TLSOptions-TLSProtocol">Server.TLSOptions.TLSProtocol</a></code></td>
<td>
<p>Optional: Maximum TLS protocol version.</p>
</td>
</tr>
<tr id="Server-TLSOptions-cipher_suites">
<td><code>cipherSuites</code></td>
<td><code>string[]</code></td>
<td>
<p>Optional: If specified, only support the specified cipher list.
Otherwise default to the default cipher list supported by Envoy.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Server-TLSOptions-TLSProtocol">Server.TLSOptions.TLSProtocol</h2>
<section>
<p>TLS protocol versions.</p>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="Server-TLSOptions-TLSProtocol-TLS_AUTO">
<td><code>TLS_AUTO</code></td>
<td>
<p>Automatically choose the optimal TLS version.</p>
</td>
</tr>
<tr id="Server-TLSOptions-TLSProtocol-TLSV1_0">
<td><code>TLSV1_0</code></td>
<td>
<p>TLS version 1.0</p>
</td>
</tr>
<tr id="Server-TLSOptions-TLSProtocol-TLSV1_1">
<td><code>TLSV1_1</code></td>
<td>
<p>TLS version 1.1</p>
</td>
</tr>
<tr id="Server-TLSOptions-TLSProtocol-TLSV1_2">
<td><code>TLSV1_2</code></td>
<td>
<p>TLS version 1.2</p>
</td>
</tr>
<tr id="Server-TLSOptions-TLSProtocol-TLSV1_3">
<td><code>TLSV1_3</code></td>
<td>
<p>TLS version 1.3</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>The SNI string presented by the client will be used as the match
criterion in a VirtualService TLS route to determine the
destination service from the service registry.</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>
<tr id="Server-TLSOptions-TLSmode-AUTO_PASSTHROUGH">
<td><code>AUTO_PASSTHROUGH</code></td>
<td>
<p>Similar to the passthrough mode, except servers with this TLS mode
do not require an associated VirtualService to map from the SNI
value to service in the registry. The destination details such as
the service/subset/port are encoded in the SNI value. The proxy
will forward to the upstream (Envoy) cluster (a group of
endpoints) specified by the SNI value. This server is typically
used to provide connectivity between services in disparate L3
networks that otherwise do not have direct connectivity between
their respective endpoints. Use of this mode assumes that both the
source and the destination are using Istio mTLS to secure traffic.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ServiceDependency">ServiceDependency</h2>
<section>
<p><code>ServiceDependency</code> describes the set of services that a workload depends on
for its operation. In other words, it describes the properties of
outgoing traffic from a given workload. By default, the service mesh
established by Istio will have a full mesh connectivity - i.e. every
workload will have proxy configuration required to reach every other
workload in the mesh. However most connectivity graphs are sparse in
practice. The ServiceDependency provides a way to declare the service
dependencies associated with each workload such that the amount of
configuration sent to the sidecars can be scoped to the requisite
dependencies.</p>
<p>Services and configuration in a mesh are organized into one or more
namespaces (e.g., a Kubernetes namespace or a CF org/space). Workloads
in a namespace have an implicit dependency on other workloads in the
same namespace. In addition, to declare dependencies on workloads in
other namespaces, a ServiceDependency resource has to be specified in the
current namespace. <em><em>Each namespace MUST have only one ServiceDependency
resource named &ldquo;default&rdquo;</em></em>. The behavior of the system is undefined if
more than one ServiceDependency resource exists in a given namespace. The set
of dependencies specified in a ServiceDependency resource will be used to
compute the sidecar configuration for every workload in the namespace.</p>
<p>NOTE 1: If workloads in the mesh depend only on other workloads in the
same namespace, set defaultServiceDependency.importMode to SAME_NAMESPACE
in the mesh global config map (in values.yaml).</p>
<p>NOTE 2: To facilitate incremental pruning of the` sidecar
configuration, the default import mode for the mesh is set to
ALL_NAMESPACES. In other words, every workload will be able to reach
every other workload. Adding a ServiceDependency resource in a namespace will
automatically prune the configuration for the workloads in that
namespace.</p>
<p>The following examples illustrate a few specific use cases of ServiceDependency.</p>
<p>The example below declares a ServiceDependency resource in the prod-us1
namespace that specifies that workloads in the namespace will be able to
reach the services in the prod-apis namespace only.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: ServiceDependency
metadata:
name: default
namespace: prod-us1
spec:
dependencies:
- imports:
- namespace: prod-apis
</code></pre>
<p>In a mesh where the default service dependency is set to SAME_NAMESPACE
only, if one or more workloads need to be able to reach every other
service in the mesh (e.g., metrics collection server), the following
ServiceDependency resource can be used to specify such a dependency:</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: ServiceDependency
metadata:
name: default
namespace: metrics-collection
spec:
dependencies:
- imports:
- namespace: '*'
</code></pre>
<p>The configuration above will allow workloads in the metrics-collection
namespace to access service in any namespace while workloads in other
namespaces will be configured for namespace local access as per the
global default service dependency (SAME_NAMESPACE).</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ServiceDependency-dependencies">
<td><code>dependencies</code></td>
<td><code><a href="#ServiceDependency-Dependency">ServiceDependency.Dependency[]</a></code></td>
<td>
<p>REQUIRED. The set of services that workloads in this namespace are
expected to talk to, in addition to other workloads in the same
namespace. Dependencies describe the properties of outbound traffic from
a given workload.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ServiceDependency-Dependency">ServiceDependency.Dependency</h2>
<section>
<p>Dependency describes a workload and the set of service dependencies
for the workload.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ServiceDependency-Dependency-imports">
<td><code>imports</code></td>
<td><code><a href="#ServiceDependency-Import">ServiceDependency.Import[]</a></code></td>
<td>
<p>REQUIRED: Import describes the set of namespaces whose exported
services will be accessed by the workloads selected by the
sourceWorkloadLabels. The sidecars attached to the workloads will be
configured with information required to reach other services in the
same namespace and the imported services. In addition to the
explicitly specified namespaces, namespaces specified in the global
mesh config (through defaultServiceDependency.importNamespaces) will also be
imported.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ServiceDependency-Import">ServiceDependency.Import</h2>
<section>
<p>Import describes the set of namespaces whose exported services
(real/virtual) will be accessed by workloads in a given namespace. The
sidecars attached to the workloads will be configured with information
required to reach the imported services only. The gateways in the
current namespace will only honor imported VirtualServices instead of
every VirtualService that binds itself to the gateway.</p>
<p>Importing a service from a namespace will automatically import the
exported configuration artifacts associated with the service, such as
VirtualService, DestinationRule, etc. The service in a namespace can be
a service in the service registry (e.g., a kubernetes or cloud foundry
service) or a service specified via ServiceEntry configuration.</p>
<p>NOTE: Only exported services and configuration artifacts from a
namespace can be imported. Private services/configuration will not be
imported. See the scope setting associated with VirtualService,
DestinationRule, ServiceEntry, etc.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="ServiceDependency-Import-namespace">
<td><code>namespace</code></td>
<td><code>string</code></td>
<td>
<p>The configuration namespace whose services need to be imported.
Specify * to import all namespaces. The import can be scoped further
by specifying individual hosts.</p>
</td>
</tr>
<tr id="ServiceDependency-Import-host">
<td><code>host</code></td>
<td><code>string</code></td>
<td>
<p>A FQDN or wildcard prefixed DNS name of the host to import from the
specified namespace. The hostnames include names of services from the
service registry as well as those specified in a VirtualService.</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 uses a combination of service entry and TLS
routing in virtual service to demonstrate the use of SNI routing to
forward unterminated TLS traffic from the application to external
services via the sidecar. The sidecar inspects the SNI value in the
ClientHello message to route to the appropriate external service.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-https
spec:
hosts:
- api.dropboxapi.com
- www.googleapis.com
- api.facebook.com
location: MESH_EXTERNAL
ports:
- number: 443
name: https
protocol: TLS
resolution: DNS
</code></pre>
<p>And the associated VirtualService to route based on the SNI value.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: tls-routing
spec:
hosts:
- api.dropboxapi.com
- www.googleapis.com
- api.facebook.com
tls:
- match:
- port: 443
sniHosts:
- api.dropboxapi.com
route:
- destination:
host: api.dropboxapi.com
- match:
- port: 443
sniHosts:
- www.googleapis.com
route:
- destination:
host: www.googleapis.com
- match:
- port: 443
sniHosts:
- api.facebook.com
route:
- destination:
host: api.facebook.com
</code></pre>
<p>The following example demonstrates the use of a dedicated egress gateway
through which all external service traffic is forwarded.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-httpbin
spec:
hosts:
- httpbin.com
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: DNS
</code></pre>
<p>Define a gateway to handle all egress traffic.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- &quot;*&quot;
</code></pre>
<p>And the associated VirtualService to route from the sidecar to the
gateway service (istio-egressgateway.istio-system.svc.cluster.local), as
well as route from the gateway to the external service.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: gateway-routing
spec:
hosts:
- httpbin.com
gateways:
- mesh
- istio-egressgateway
http:
- match:
- port: 80
gateways:
- mesh
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
- match:
- port: 80
gateway:
- istio-egressgateway
route:
- destination:
host: httpbin.com
</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 class="language-yaml">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:8080,
uk.foo.bar.com:9080, and in.foo.bar.com:7080</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: 80
name: http
protocol: HTTP
resolution: DNS
endpoints:
- address: us.foo.bar.com
ports:
https: 8080
- address: uk.foo.bar.com
ports:
https: 9080
- address: in.foo.bar.com
ports:
https: 7080
</code></pre>
<p>With HTTP_PROXY=http://localhost/, calls from the application to
http://foo.bar.com will be load balanced across the three domains
specified above. In other words, a call to http://foo.bar.com/baz would
be translated to http://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/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/HTTPS,
the hosts will be ignored. If one or more IP addresses are specified,
the incoming traffic will be identified 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>REQUIRED: Service discovery mode for the hosts. Care must be taken
when setting the resolution mode to NONE for a TCP port without
accompanying IP addresses. In such cases, traffic to any IP on
said port will be allowed (i.e. 0.0.0.0:<port>).</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>
<tr id="ServiceEntry-config_scope">
<td><code>configScope</code></td>
<td><code><a href="#ConfigScope">ConfigScope</a></code></td>
<td>
<p>The visibility setting associated with this service entry. Set to
PRIVATE if this service should not be visible outside the namespace
where the service entry was added. The default scope is public,
i.e. the service added by the service entry will be visible to
workloads in the entire mesh.</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>
<tr id="ServiceEntry-Endpoint-network">
<td><code>network</code></td>
<td><code>string</code></td>
<td>
<p>Network enables Istio to group endpoints resident in the same L3
domain/network. All endpoints in the same network are assumed to be
directly reachable from one another. When endpoints in different
networks cannot reach each other directly, an Istio Gateway can be
used to establish connectivity (usually using the
AUTO_PASSTHROUGH mode in a Gateway Server). This is
an advanced configuration used typically for spanning an Istio mesh
over multiple clusters.</p>
</td>
</tr>
<tr id="ServiceEntry-Endpoint-locality">
<td><code>locality</code></td>
<td><code>string</code></td>
<td>
<p>The locality associated with the endpoint. A locality corresponds
to a failure domain (e.g., country/region/zone). Arbitrary failure
domain hierarchies can be represented by separating each
encapsulating failure domain by /. For example, the locality of an
an endpoint in US, in US-East-1 region, within availability zone
az-1, in data center rack r11 can be represented as
us/us-east-1/az-1/r11. Istio will configure the sidecar to route to
endpoints within the same locality as the sidecar. If none of the
endpoints in the locality are available, endpoints parent locality
(but within the same network ID) will be chosen. For example, if
there are two endpoints in same network (networkID &ldquo;n1&rdquo;), say e1
with locality us/us-east-1/az-1/r11 and e2 with locality
us/us-east-1/az-2/r12, a sidecar from us/us-east-1/az-1/r11 locality
will prefer e1 from the same locality over e2 from a different
locality. Endpoint e2 could be the IP associated with a gateway
(that bridges networks n1 and n2), or the IP associated with a
standard service endpoint.</p>
</td>
</tr>
<tr id="ServiceEntry-Endpoint-weight">
<td><code>weight</code></td>
<td><code>uint32</code></td>
<td>
<p>The load balancing weight associated with the endpoint. Endpoints
with higher weights will receive proportionally higher traffic.</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>
<p>One or more labels are typically required to identify the subset destination,
however, when the corresponding DestinationRule represents a host that
supports multiple SNI hosts (e.g., an egress gateway), a subset without labels
may be meaningful. In this case a traffic policy with <a href="#TLSSettings">TLSSettings</a>
can be used to identify a specific SNI host corresponding to the named 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>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 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
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="#RouteDestination">RouteDestination[]</a></code></td>
<td>
<p>The destination to which the connection should be forwarded to.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="TLSMatchAttributes">TLSMatchAttributes</h2>
<section>
<p>TLS connection match attributes.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="TLSMatchAttributes-sni_hosts">
<td><code>sniHosts</code></td>
<td><code>string[]</code></td>
<td>
<p>REQUIRED. SNI (server name indicator) to match on. Wildcard prefixes
can be used in the SNI value, e.g., *.com will match foo.example.com
as well as example.com. An SNI value must be a subset (i.e., fall
within the domain) of the corresponding virtual serivce&rsquo;s hosts.</p>
</td>
</tr>
<tr id="TLSMatchAttributes-destination_subnets">
<td><code>destinationSubnets</code></td>
<td><code>string[]</code></td>
<td>
<p>IPv4 or IPv6 ip addresses of destination with optional subnet. E.g.,
a.b.c.d/xx form or just a.b.c.d.</p>
</td>
</tr>
<tr id="TLSMatchAttributes-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="TLSMatchAttributes-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="TLSMatchAttributes-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="TLSRoute">TLSRoute</h2>
<section>
<p>Describes match conditions and actions for routing unterminated TLS
traffic (TLS/HTTPS) The following routing rule forwards unterminated TLS
traffic arriving at port 443 of gateway called &ldquo;mygateway&rdquo; to internal
services in the mesh based on the SNI value.</p>
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo-sni
spec:
hosts:
- &quot;*.bookinfo.com&quot;
gateways:
- mygateway
tls:
- match:
- port: 443
sniHosts:
- login.bookinfo.com
route:
- destination:
host: login.prod.svc.cluster.local
- match:
- port: 443
sniHosts:
- reviews.bookinfo.com
route:
- destination:
host: reviews.prod.svc.cluster.local
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="TLSRoute-match">
<td><code>match</code></td>
<td><code><a href="#TLSMatchAttributes">TLSMatchAttributes[]</a></code></td>
<td>
<p>REQUIRED. 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="TLSRoute-route">
<td><code>route</code></td>
<td><code><a href="#RouteDestination">RouteDestination[]</a></code></td>
<td>
<p>The destination to which the connection should be forwarded to.</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-v2/api/v2/auth/cert.proto.html">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.</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.</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 with path starting with /wpcatalog/ or /consumercatalog/ 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 protocol-specific 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. HTTP routes will be
applied to platform service ports named &lsquo;http-<em>&rsquo;/&lsquo;http2-</em>&rsquo;/&lsquo;grpc-*&rsquo;, gateway
ports with protocol HTTP/HTTP2/GRPC/ TLS-terminated-HTTPS and service
entry ports using HTTP/HTTP2/GRPC protocols. The first rule matching
an incoming request is used.</p>
</td>
</tr>
<tr id="VirtualService-tls">
<td><code>tls</code></td>
<td><code><a href="#TLSRoute">TLSRoute[]</a></code></td>
<td>
<p>An ordered list of route rule for non-terminated TLS &amp; HTTPS
traffic. Routing is typically performed using the SNI value presented
by the ClientHello message. TLS routes will be applied to platform
service ports named &lsquo;https-<em>&rsquo;, &lsquo;tls-</em>&rsquo;, unterminated gateway ports using
HTTPS/TLS protocols (i.e. with &ldquo;passthrough&rdquo; TLS mode) and service
entry ports using HTTPS/TLS protocols. The first rule matching an
incoming request is used. NOTE: Traffic &lsquo;https-<em>&rsquo; or &lsquo;tls-</em>&rsquo; ports
without associated virtual service will be treated as opaque TCP
traffic.</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 opaque TCP traffic. TCP routes will
be applied to any port that is not a HTTP or TLS port. The first rule
matching an incoming request is used.</p>
</td>
</tr>
<tr id="VirtualService-config_scope">
<td><code>configScope</code></td>
<td><code><a href="#ConfigScope">ConfigScope</a></code></td>
<td>
<p>The visibility setting associated with this VirtualService. Set to
PRIVATE if this virtual service should not be exported, i.e. restrict
the applicability of this virtual service to only workloads in the same
namespace as the virtual service.</p>
</td>
</tr>
</tbody>
</table>
</section>
Reference in New Issue View Git Blame Copy Permalink