mirror of https://github.com/istio/istio.io.git
Update reference docs. (#3650)
This commit is contained in:
Martin Taillefer
GitHub
parent
3fd7ce5ef1
commit
a61fae859c
|
|
@ -175,11 +175,11 @@ or “v1<em>” (prefix match), or “</em>alpha2” (suffix mat
|
|||
<section>
|
||||
<p>RbacConfig defines the global config to control Istio RBAC behavior.
|
||||
This Custom Resource is a singleton where only one Custom Resource should be created globally in
|
||||
the mesh and the namespace should be the same to other Istio components, which usually is istio-system.
|
||||
Note: This is enforced in both istioctl and server side, new Custom Resource will be rejected if found any
|
||||
the mesh and the namespace should be the same to other Istio components, which usually is <code>istio-system</code>.
|
||||
Note: This is enforced in both <code>istioctl</code> and server side, new Custom Resource will be rejected if found any
|
||||
existing one, the user should either delete the existing one or change the existing one directly.</p>
|
||||
|
||||
<p>Below is an example of RbacConfig object “istio-rbac-config” which enables Istio RBAC for all
|
||||
<p>Below is an example of an <code>RbacConfig</code> resource called <code>istio-rbac-config</code> which enables Istio RBAC for all
|
||||
services in the default namespace.</p>
|
||||
|
||||
<pre><code class="language-yaml">apiVersion: "rbac.istio.io/v1alpha1"
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ Discovery</a> of
|
|||
the issuer or (b) inferred from the email domain of the issuer (e.g. a
|
||||
Google service account).</p>
|
||||
|
||||
<p>Example: https://www.googleapis.com/oauth2/v1/certs</p>
|
||||
<p>Example: <code>https://www.googleapis.com/oauth2/v1/certs</code></p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
|
|
|||
|
|
@ -79,9 +79,9 @@ Use fs:/// to specify a file-based backend with absolute path to the directory.<
|
|||
<td><code>tlsSettings</code></td>
|
||||
<td><code><a href="/docs/reference/config/networking/v1alpha3/destination-rule.html#TLSSettings">istio.networking.v1alpha3.TLSSettings</a></code></td>
|
||||
<td>
|
||||
<p>Use the tls<em>settings to specify the tls mode to use. If the MCP server
|
||||
<p>Use the tls_settings to specify the tls mode to use. If the MCP server
|
||||
uses Istio mutual TLS and shares the root CA with Pilot, specify the TLS
|
||||
mode as ISTIO</em>MUTUAL.</p>
|
||||
mode as <code>ISTIO_MUTUAL</code>.</p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
|
@ -152,7 +152,7 @@ and similarly us-west should failover to us-east.</p>
|
|||
<td>
|
||||
<p>Optional: only one of distribute or failover can be set.
|
||||
Explicitly specify loadbalancing weight across different zones and geographical locations.
|
||||
Refer to <a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing.html?highlight=load_balancing_weight#locality-weighted-load-balancing">Locality weighted load balancing</a>
|
||||
Refer to <a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing/locality_weight">Locality weighted load balancing</a>
|
||||
If empty, the locality weight is set according to the endpoints number within it.</p>
|
||||
|
||||
</td>
|
||||
|
|
@ -757,7 +757,7 @@ the following rules:</p>
|
|||
<li><p>Implicitly: If the registry explicitly provides information about
|
||||
the network to which the endpoint belongs to. In some cases, its
|
||||
possible to indicate the network associated with the endpoint by
|
||||
adding ISTIO<em>META</em>NETWORK environment variable to the sidecar.</p></li>
|
||||
adding the <code>ISTIO_META_NETWORK</code> environment variable to the sidecar.</p></li>
|
||||
|
||||
<li><p>Explicitly:</p></li>
|
||||
</ol>
|
||||
|
|
@ -796,7 +796,7 @@ ranges for endpoints from different networks must not overlap.</p>
|
|||
<td>
|
||||
<p>Add all endpoints from the specified registry into this network.
|
||||
The names of the registries should correspond to the secret name
|
||||
that was used to configure the registry (kubernetes multicluster) or
|
||||
that was used to configure the registry (Kubernetes multicluster) or
|
||||
supplied by MCP server.</p>
|
||||
|
||||
</td>
|
||||
|
|
@ -911,7 +911,7 @@ DEPRECATED: Use <a href="#ProxyConfig-tracing">tracing</a> instead.</p>
|
|||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>Address of the Envoy Metrics Service implementation (e.g. metrics-service:15000).
|
||||
See https://www.envoyproxy.io/docs/envoy/latest/api-v2/config/metrics/v2/metrics_service.proto
|
||||
See <a href="https://www.envoyproxy.io/docs/envoy/latest/api-v2/config/metrics/v2/metrics_service.proto">Metric Service</a>
|
||||
for details about Envoy’s Metrics Service API.</p>
|
||||
|
||||
</td>
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ spec:
|
|||
- "bookinfo-namespace/*.bookinfo.com"
|
||||
tls:
|
||||
mode: SIMPLE # enables HTTPS on this port
|
||||
credentialName: bookinfo-secret # fetches certs from kubernetes secret
|
||||
credentialName: bookinfo-secret # fetches certs from Kubernetes secret
|
||||
- port:
|
||||
number: 9080
|
||||
name: http-wildcard
|
||||
|
|
@ -78,15 +78,15 @@ balancer. A <code>VirtualService</code> can then be bound to a gateway to contro
|
|||
the forwarding of traffic arriving at a particular host or gateway port.</p>
|
||||
|
||||
<p>For example, the following VirtualService splits traffic for
|
||||
“https://uk.bookinfo.com/reviews”, “https://eu.bookinfo.com/reviews”,
|
||||
“http://uk.bookinfo.com:9080/reviews”,
|
||||
“http://eu.bookinfo.com:9080/reviews” into two versions (prod and qa) of
|
||||
<code>https://uk.bookinfo.com/reviews</code>, <code>https://eu.bookinfo.com/reviews</code>,
|
||||
<code>http://uk.bookinfo.com:9080/reviews</code>,
|
||||
<code>http://eu.bookinfo.com:9080/reviews</code> into two versions (prod and qa) of
|
||||
an internal reviews service on port 9080. In addition, requests
|
||||
containing the cookie “user: dev-123” will be sent to special port 7777
|
||||
in the qa version. The same rule is also applicable inside the mesh for
|
||||
requests to the “reviews.prod.svc.cluster.local” service. This rule is
|
||||
applicable across ports 443, 9080. Note that “http://uk.bookinfo.com”
|
||||
gets redirected to “https://uk.bookinfo.com” (i.e. 80 redirects to 443).</p>
|
||||
applicable across ports 443, 9080. Note that <code>http://uk.bookinfo.com</code>
|
||||
gets redirected to <code>https://uk.bookinfo.com</code> (i.e. 80 redirects to 443).</p>
|
||||
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
|
|
@ -339,7 +339,7 @@ connections.</p>
|
|||
While typically applicable to
|
||||
HTTP services, it can also be used for TCP services using TLS with SNI.
|
||||
A host is specified as a <code>dnsName</code> with an optional <code>namespace/</code> prefix.
|
||||
The <code>dnsName</code> should be specified using FQDN format, opionally including
|
||||
The <code>dnsName</code> should be specified using FQDN format, optionally including
|
||||
a wildcard character in the left-most component (e.g., <code>prod/*.example.com</code>).
|
||||
Set the <code>dnsName</code> to <code>*</code> to select all <code>VirtualService</code> hosts from the
|
||||
specified namespace (e.g.,<code>prod/*</code>). If no <code>namespace/</code> is specified,
|
||||
|
|
@ -452,7 +452,7 @@ to identify the serverCertificate and the privateKey. The
|
|||
credentialName appended with suffix “-cacert” is used to identify
|
||||
the CaCertificates associated with this server. Gateway workloads
|
||||
capable of fetching credentials from a remote credential store such
|
||||
as kubernetes secrets, will be configured to retrieve the
|
||||
as Kubernetes secrets, will be configured to retrieve the
|
||||
serverCertificate and the privateKey using credentialName, instead
|
||||
of using the file system paths specified above. If using mutual TLS,
|
||||
gateway workloads will retrieve the CaCertificates using
|
||||
|
|
|
|||
|
|
@ -167,8 +167,8 @@ spec:
|
|||
- "*"
|
||||
</code></pre>
|
||||
|
||||
<p>And the associated VirtualService to route from the sidecar to the
|
||||
gateway service (istio-egressgateway.istio-system.svc.cluster.local), as
|
||||
<p>And the associated <code>VirtualService</code> to route from the sidecar to the
|
||||
gateway service (<code>istio-egressgateway.istio-system.svc.cluster.local</code>), as
|
||||
well as route from the gateway to the external service. Note that the
|
||||
virtual service is exported to all namespaces enabling them to route traffic
|
||||
through the gateway to the external service. Forcing traffic to go through
|
||||
|
|
@ -226,7 +226,7 @@ spec:
|
|||
|
||||
<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>
|
||||
set to STATIC to use Unix address endpoints.</p>
|
||||
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
|
|
@ -245,10 +245,10 @@ spec:
|
|||
- address: unix:///var/run/example/socket
|
||||
</code></pre>
|
||||
|
||||
<p>For HTTP-based services, it is possible to create a VirtualService
|
||||
<p>For HTTP-based services, it is possible to create a <code>VirtualService</code>
|
||||
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
|
||||
application can use the <code>HTTP_PROXY</code> environment variable to transparently
|
||||
reroute API calls for the <code>VirtualService</code> 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>
|
||||
|
|
@ -283,10 +283,9 @@ spec:
|
|||
specified above. In other words, a call to <code>http://foo.bar.com/baz</code> would
|
||||
be translated to <code>http://uk.foo.bar.com/baz</code>.</p>
|
||||
|
||||
<p>The following example illustrates the usage of a ServiceEntry
|
||||
<p>The following example illustrates the usage of a <code>ServiceEntry</code>
|
||||
containing a subject alternate name
|
||||
whose format conforms to the SPIFEE standard
|
||||
<a href="https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md">https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md</a>:</p>
|
||||
whose format conforms to the <a href="https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md">SPIFEE standard</a>:</p>
|
||||
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
|
|
@ -466,7 +465,7 @@ unix:///absolute/path/to/socket for Unix domain socket endpoints.</p>
|
|||
<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>
|
||||
service. Do not use for <code>unix://</code> addresses.</p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
|
@ -615,7 +614,7 @@ 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
|
||||
the destination IP address. DNS resolution cannot be used with Unix
|
||||
domain socket endpoints.</p>
|
||||
|
||||
</td>
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ attached to the workload. The following example declares a Sidecar
|
|||
resource in the prod-us1 namespace for all pods with labels “app:
|
||||
productpage” belonging to the productpage.prod-us1 service. Assuming
|
||||
that these pods are deployed without IPtable rules (i.e. the Istio init
|
||||
container) and the proxy metadata ISTIO<em>META</em>INTERCEPTION_MODE is set to
|
||||
container) and the proxy metadata <code>ISTIO_META_INTERCEPTION_MODE</code> is set to
|
||||
NONE, the specification below allows such pods to receive HTTP traffic
|
||||
on port 9080 and forward it to the application listening on
|
||||
127.0.0.1:8080. It also allows the application to communicate with a
|
||||
|
|
@ -149,7 +149,7 @@ additional network interface on 172.16.0.0/16 subnet for inbound
|
|||
traffic. The following Sidecar configuration allows the VM to expose a
|
||||
listener on 172.16.1.32:80 (the VM’s IP) for traffic arriving from the
|
||||
172.16.0.0/16 subnet. Note that in this scenario, the
|
||||
ISTIO<em>META</em>INTERCEPTION_MODE metadata on the proxy in the VM should
|
||||
<code>ISTIO_META_INTERCEPTION_MODE</code> metadata on the proxy in the VM should
|
||||
contain “REDIRECT” or “TPROXY” as its value, implying that IP tables
|
||||
based traffic capture is active.</p>
|
||||
|
||||
|
|
@ -287,7 +287,7 @@ The corresponding service can be a service in the service registry
|
|||
using a <code>ServiceEntry</code> or <code>VirtualService</code> configuration. Any
|
||||
associated <code>DestinationRule</code> in the same namespace will also be used.</p>
|
||||
|
||||
<p>The <code>dnsName</code> should be specified using FQDN format, opionally including
|
||||
<p>The <code>dnsName</code> should be specified using FQDN format, optionally including
|
||||
a wildcard character in the left-most component (e.g., <code>prod/*.example.com</code>).
|
||||
Set the <code>dnsName</code> to <code>*</code> to select all services from the specified namespace
|
||||
(e.g.,<code>prod/*</code>). The <code>namespace</code> can also be set to <code>*</code> to select a particular
|
||||
|
|
@ -358,7 +358,7 @@ captureMode must be DEFAULT or NONE for Unix domain socket binds.</p>
|
|||
traffic should be forwarded to. This configuration can be used to
|
||||
redirect traffic arriving at the bind point on the sidecar to a port
|
||||
or Unix domain socket where the application workload is listening for
|
||||
connections. Format should be 127.0.0.1:PORT or unix:///path/to/socket</p>
|
||||
connections. Format should be 127.0.0.1:PORT or <code>unix:///path/to/socket</code></p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
|
|
|||
|
|
@ -97,8 +97,7 @@ spec:
|
|||
<h2 id="CorsPolicy">CorsPolicy</h2>
|
||||
<section>
|
||||
<p>Describes the Cross-Origin Resource Sharing (CORS) policy, for a given
|
||||
service. Refer to
|
||||
<a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS">https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS</a>
|
||||
service. Refer to <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS">CORS</a>
|
||||
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
|
||||
|
|
@ -831,9 +830,8 @@ number of retries attempted depends on the httpReqTimeout.</p>
|
|||
<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
|
||||
<a href="https://www.envoyproxy.io/docs/envoy/latest/configuration/http_filters/router_filter#x-envoy-retry-on">https://www.envoyproxy.io/docs/envoy/latest/configuration/http_filters/router_filter#x-envoy-retry-on</a>
|
||||
and <a href="https://www.envoyproxy.io/docs/envoy/latest/configuration/http_filters/router_filter#x-envoy-retry-grpc-on">https://www.envoyproxy.io/docs/envoy/latest/configuration/http_filters/router_filter#x-envoy-retry-grpc-on</a></p>
|
||||
See the <a href="https://www.envoyproxy.io/docs/envoy/latest/configuration/http_filters/router_filter#x-envoy-retry-on">supported policies</a>
|
||||
and <a href="https://www.envoyproxy.io/docs/envoy/latest/configuration/http_filters/router_filter#x-envoy-retry-grpc-on">here</a> for more details.</p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ of an Istio deployment.</p>
|
|||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>Required. Name of the component producing these attributes. This can be
|
||||
the proxy (with the canonical name “istio-proxy”) or the name of an
|
||||
the proxy (with the canonical name <code>istio-proxy</code>) or the name of an
|
||||
<code>attributes</code> kind adapter in Mixer.</p>
|
||||
|
||||
</td>
|
||||
|
|
@ -109,9 +109,9 @@ which is how attributes are referred to in aspect configuration, must conform to
|
|||
match the regular expression <code>[\.-]</code>.</p>
|
||||
|
||||
<p>Attribute names must be unique within a single Istio deployment. The set of canonical
|
||||
attributes are described at https://istio.io/docs/reference/attribute-vocabulary.html.
|
||||
attributes are described at <a href="/docs/reference/config/policy-and-telemetry/attribute-vocabulary/">here</a>.
|
||||
Attributes not in that list should be named with a component-specific suffix such as
|
||||
request.count-my.component.</p>
|
||||
<code>request.count-my.component</code>.</p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
|
@ -1084,7 +1084,7 @@ TLS for connection to the backend.</p>
|
|||
<p>A Rule is a selector and a set of intentions to be executed when the
|
||||
selector is <code>true</code></p>
|
||||
|
||||
<p>The following example instructs Mixer to invoke ‘prometheus-handler’ handler for all services and pass it the
|
||||
<p>The following example instructs Mixer to invoke <code>prometheus-handler</code> handler for all services and pass it the
|
||||
instance constructed using the ‘RequestCountByService’ instance.</p>
|
||||
|
||||
<pre><code class="language-yaml">- match: match(destination.service.host, "*")
|
||||
|
|
|
|||
Loading…
Reference in New Issue