update dependencies

Signed-off-by: hongming <talonwan@yunify.com>
2020-12-22 16:48:26 +08:00
parent 4a11a50544
commit fe6c5de00f
2857 changed files with 252134 additions and 115656 deletions
--- a/vendor/istio.io/api/networking/v1alpha3/sidecar.pb.html
+++ b/vendor/istio.io/api/networking/v1alpha3/sidecar.pb.html
@@ -4,7 +4,8 @@ description: Configuration affecting network reachability of a sidecar.
 location: https://istio.io/docs/reference/config/networking/sidecar.html
 layout: protoc-gen-docs
 generator: protoc-gen-docs
-aliases: [/docs/reference/config/networking/v1alpha3/sidecar.html]
+schema: istio.networking.v1alpha3.Sidecar
+aliases: [/docs/reference/config/networking/v1alpha3/sidecar]
 number_of_entries: 7
 ---
 <p><code>Sidecar</code> describes the configuration of the sidecar proxy that mediates
@@ -28,22 +29,29 @@ workload instance, preference will be given to the resource with a
 <code>workloadSelector</code> that selects this workload instance, over a <code>Sidecar</code> configuration
 without any <code>workloadSelector</code>.</p>

-<p>NOTE 1: <em><em>Each namespace can have only one <code>Sidecar</code> configuration without any
-<code>workloadSelector</code></em></em>. The behavior of the system is undefined if more
-than one selector-less <code>Sidecar</code> configurations exist in a given namespace. The
-behavior of the system is undefined if two or more <code>Sidecar</code> configurations
-with a <code>workloadSelector</code> select the same workload instance.</p>
+<p><strong>NOTE 1</strong>: <em><em>Each namespace can have only one <code>Sidecar</code>
+configuration without any <code>workloadSelector</code></em> that specifies the
+default for all pods in that namespace</em>. It is recommended to use
+the name <code>default</code> for the namespace-wide sidecar. The behavior of
+the system is undefined if more than one selector-less <code>Sidecar</code>
+configurations exist in a given namespace. The behavior of the
+system is undefined if two or more <code>Sidecar</code> configurations with a
+<code>workloadSelector</code> select the same workload instance.</p>

-<p>NOTE 2: <em><em>A <code>Sidecar</code> configuration in the <code>MeshConfig</code>
+<p><strong>NOTE 2</strong>: <em><em>A <code>Sidecar</code> configuration in the <code>MeshConfig</code>
 <a href="https://istio.io/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig">root namespace</a>
 will be applied by default to all namespaces without a <code>Sidecar</code>
 configuration</em></em>. This global default <code>Sidecar</code> configuration should not have
 any <code>workloadSelector</code>.</p>

-<p>The example below declares a global default <code>Sidecar</code> configuration in the
-root namespace called <code>istio-config</code>, that configures sidecars in
-all namespaces to allow egress traffic only to other workloads in
-the same namespace, and to services in the <code>istio-system</code> namespace.</p>
+<p>The example below declares a global default <code>Sidecar</code> configuration
+in the root namespace called <code>istio-config</code>, that configures
+sidecars in all namespaces to allow egress traffic only to other
+workloads in the same namespace as well as to services in the
+<code>istio-system</code> namespace.</p>
+
+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>

 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: Sidecar
@@ -57,11 +65,33 @@ spec:
    - &quot;istio-system/*&quot;
 </code></pre>

-<p>The example below declares a <code>Sidecar</code> configuration in the <code>prod-us1</code>
-namespace that overrides the global default defined above, and
-configures the sidecars in the namespace to allow egress traffic to
-public services in the <code>prod-us1</code>, <code>prod-apis</code>, and the <code>istio-system</code>
-namespaces.</p>
+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: Sidecar
+metadata:
+  name: default
+  namespace: istio-config
+spec:
+  egress:
+  - hosts:
+    - &quot;./*&quot;
+    - &quot;istio-system/*&quot;
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
+<p>The example below declares a <code>Sidecar</code> configuration in the
+<code>prod-us1</code> namespace that overrides the global default defined
+above, and configures the sidecars in the namespace to allow egress
+traffic to public services in the <code>prod-us1</code>, <code>prod-apis</code>, and the
+<code>istio-system</code> namespaces.</p>
+
+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>

 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: Sidecar
@@ -76,19 +106,47 @@ spec:
    - &quot;istio-system/*&quot;
 </code></pre>

-<p>The example below declares a <code>Sidecar</code> configuration in the <code>prod-us1</code> namespace
-that accepts inbound HTTP traffic on port 9080 and forwards
-it to the attached workload instance listening on a Unix domain socket. In the
-egress direction, in addition to the <code>istio-system</code> namespace, the sidecar
-proxies only HTTP traffic bound for port 9080 for services in the
-<code>prod-us1</code> namespace.</p>
+<p>{{</tab>}}</p>

-<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
 kind: Sidecar
 metadata:
  name: default
  namespace: prod-us1
 spec:
+  egress:
+  - hosts:
+    - &quot;prod-us1/*&quot;
+    - &quot;prod-apis/*&quot;
+    - &quot;istio-system/*&quot;
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
+<p>The following example declares a <code>Sidecar</code> configuration in the
+<code>prod-us1</code> namespace for all pods with labels <code>app: ratings</code>
+belonging to the <code>ratings.prod-us1</code> service.  The workload accepts
+inbound HTTP traffic on port 9080. The traffic is then forwarded to
+the attached workload instance listening on a Unix domain
+socket. In the egress direction, in addition to the <code>istio-system</code>
+namespace, the sidecar proxies only HTTP traffic bound for port
+9080 for services in the <code>prod-us1</code> namespace.</p>
+
+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
+kind: Sidecar
+metadata:
+  name: ratings
+  namespace: prod-us1
+spec:
+  workloadSelector:
+    labels:
+      app: ratings
  ingress:
  - port:
      number: 9080
@@ -106,18 +164,56 @@ spec:
    - &quot;istio-system/*&quot;
 </code></pre>

-<p>If the workload is deployed without IPTables-based traffic capture, the
-<code>Sidecar</code> configuration is the only way to configure the ports on the proxy
-attached to the workload instance. The following example declares a <code>Sidecar</code>
-configuration in the <code>prod-us1</code> namespace for all pods with labels
-<code>app: productpage</code> belonging to the <code>productpage.prod-us1</code> service. Assuming
-that these pods are deployed without IPtable rules (i.e. the <code>istio-init</code>
-container) and the proxy metadata <code>ISTIO_META_INTERCEPTION_MODE</code> is set to
-<code>NONE</code>, the specification, below, allows such pods to receive HTTP traffic
-on port 9080 and forward it to the application listening on
-<code>127.0.0.1:8080</code>. It also allows the application to communicate with a
-backing MySQL database on <code>127.0.0.1:3306</code>, that then gets proxied to the
-externally hosted MySQL service at <code>mysql.foo.com:3306</code>.</p>
+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: Sidecar
+metadata:
+  name: ratings
+  namespace: prod-us1
+spec:
+  workloadSelector:
+    labels:
+      app: ratings
+  ingress:
+  - port:
+      number: 9080
+      protocol: HTTP
+      name: somename
+    defaultEndpoint: unix:///var/run/someuds.sock
+  egress:
+  - port:
+      number: 9080
+      protocol: HTTP
+      name: egresshttp
+    hosts:
+    - &quot;prod-us1/*&quot;
+  - hosts:
+    - &quot;istio-system/*&quot;
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
+<p>If the workload is deployed without IPTables-based traffic capture,
+the <code>Sidecar</code> configuration is the only way to configure the ports
+on the proxy attached to the workload instance. The following
+example declares a <code>Sidecar</code> configuration in the <code>prod-us1</code>
+namespace for all pods with labels <code>app: productpage</code> belonging to
+the <code>productpage.prod-us1</code> service. Assuming that these pods are
+deployed without IPtable rules (i.e. the <code>istio-init</code> container)
+and the proxy metadata <code>ISTIO_META_INTERCEPTION_MODE</code> is set to
+<code>NONE</code>, the specification, below, allows such pods to receive HTTP
+traffic on port 9080 (wrapped inside Istio mutual TLS) and forward
+it to the application listening on <code>127.0.0.1:8080</code>. It also allows
+the application to communicate with a backing MySQL database on
+<code>127.0.0.1:3306</code>, that then gets proxied to the externally hosted
+MySQL service at <code>mysql.foo.com:3306</code>.</p>
+
+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>

 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: Sidecar
@@ -146,8 +242,45 @@ spec:
    - &quot;*/mysql.foo.com&quot;
 </code></pre>

+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: Sidecar
+metadata:
+  name: no-ip-tables
+  namespace: prod-us1
+spec:
+  workloadSelector:
+    labels:
+      app: productpage
+  ingress:
+  - port:
+      number: 9080 # binds to proxy_instance_ip:9080 (0.0.0.0:9080, if no unicast IP is available for the instance)
+      protocol: HTTP
+      name: somename
+    defaultEndpoint: 127.0.0.1:8080
+    captureMode: NONE # not needed if metadata is set for entire proxy
+  egress:
+  - port:
+      number: 3306
+      protocol: MYSQL
+      name: egressmysql
+    captureMode: NONE # not needed if metadata is set for entire proxy
+    bind: 127.0.0.1
+    hosts:
+    - &quot;*/mysql.foo.com&quot;
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
 <p>And the associated service entry for routing to <code>mysql.foo.com:3306</code></p>

+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: ServiceEntry
 metadata:
@@ -164,6 +297,29 @@ spec:
  resolution: DNS
 </code></pre>

+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: ServiceEntry
+metadata:
+  name: external-svc-mysql
+  namespace: ns1
+spec:
+  hosts:
+  - mysql.foo.com
+  ports:
+  - number: 3306
+    name: mysql
+    protocol: MYSQL
+  location: MESH_EXTERNAL
+  resolution: DNS
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
 <p>It is also possible to mix and match traffic capture modes in a single
 proxy. For example, consider a setup where internal services are on the
 <code>192.168.0.0/16</code> subnet. So, IP tables are setup on the VM to capture all
@@ -171,10 +327,14 @@ outbound traffic on <code>192.168.0.0/16</code> subnet. Assume that the VM has a
 additional network interface on <code>172.16.0.0/16</code> subnet for inbound
 traffic. The following <code>Sidecar</code> configuration allows the VM to expose a
 listener on <code>172.16.1.32:80</code> (the VM&rsquo;s IP) for traffic arriving from the
-<code>172.16.0.0/16</code> subnet. Note that in this scenario, the
-<code>ISTIO_META_INTERCEPTION_MODE</code> metadata on the proxy in the VM should
-contain <code>REDIRECT</code> or <code>TPROXY</code> as its value, implying that IP tables
-based traffic capture is active.</p>
+<code>172.16.0.0/16</code> subnet.</p>
+
+<p><strong>NOTE</strong>: The <code>ISTIO_META_INTERCEPTION_MODE</code> metadata on the
+proxy in the VM should contain <code>REDIRECT</code> or <code>TPROXY</code> as its value,
+implying that IP tables based traffic capture is active.</p>
+
+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>

 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: Sidecar
@@ -203,42 +363,186 @@ spec:
    - &quot;*/*&quot;
 </code></pre>

-<h2 id="CaptureMode">CaptureMode</h2>
-<section>
-<p><code>CaptureMode</code> describes how traffic to a listener is expected to be
-captured. Applicable only when the listener is bound to an IP.</p>
+<p>{{</tab>}}</p>

-<table class="enum-values">
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: Sidecar
+metadata:
+  name: partial-ip-tables
+  namespace: prod-us1
+spec:
+  workloadSelector:
+    labels:
+      app: productpage
+  ingress:
+  - bind: 172.16.1.32
+    port:
+      number: 80 # binds to 172.16.1.32:80
+      protocol: HTTP
+      name: somename
+    defaultEndpoint: 127.0.0.1:8080
+    captureMode: NONE
+  egress:
+    # use the system detected defaults
+    # sets up configuration to handle outbound traffic to services
+    # in 192.168.0.0/16 subnet, based on information provided by the
+    # service registry
+  - captureMode: IPTABLES
+    hosts:
+    - &quot;*/*&quot;
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
+<h2 id="Sidecar">Sidecar</h2>
+<section>
+<p><code>Sidecar</code> describes the configuration of the sidecar proxy that mediates
+inbound and outbound communication of the workload instance to which it is
+attached.</p>
+
+<table class="message-fields">
 <thead>
 <tr>
-<th>Name</th>
+<th>Field</th>
+<th>Type</th>
 <th>Description</th>
+<th>Required</th>
 </tr>
 </thead>
 <tbody>
-<tr id="CaptureMode-DEFAULT">
-<td><code>DEFAULT</code></td>
+<tr id="Sidecar-workload_selector">
+<td><code>workloadSelector</code></td>
+<td><code><a href="#WorkloadSelector">WorkloadSelector</a></code></td>
 <td>
-<p>The default capture mode defined by the environment.</p>
+<p>Criteria used to select the specific set of pods/VMs on which this
+<code>Sidecar</code> configuration should be applied. If omitted, the <code>Sidecar</code>
+configuration will be applied to all workload instances in the same namespace.</p>

 </td>
-</tr>
-<tr id="CaptureMode-IPTABLES">
-<td><code>IPTABLES</code></td>
 <td>
-<p>Capture traffic using IPtables redirection.</p>
-
+No
 </td>
 </tr>
-<tr id="CaptureMode-NONE">
-<td><code>NONE</code></td>
+<tr id="Sidecar-ingress">
+<td><code>ingress</code></td>
+<td><code><a href="#IstioIngressListener">IstioIngressListener[]</a></code></td>
 <td>
-<p>No traffic capture. When used in an egress listener, the application is
-expected to explicitly communicate with the listener port or Unix
-domain socket. When used in an ingress listener, care needs to be taken
-to ensure that the listener port is not in use by other processes on
-the host.</p>
+<p>Ingress specifies the configuration of the sidecar for processing
+inbound traffic to the attached workload instance. If omitted, Istio will
+automatically configure the sidecar based on the information about the workload
+obtained from the orchestration platform (e.g., exposed ports, services,
+etc.). If specified, inbound ports are configured if and only if the
+workload instance is associated with a service.</p>

+</td>
+<td>
+No
+</td>
+</tr>
+<tr id="Sidecar-egress">
+<td><code>egress</code></td>
+<td><code><a href="#IstioEgressListener">IstioEgressListener[]</a></code></td>
+<td>
+<p>Egress specifies the configuration of the sidecar for processing
+outbound traffic from the attached workload instance to other
+services in the mesh. If not specified, inherits the system
+detected defaults from the namespace-wide or the global default Sidecar.</p>
+
+</td>
+<td>
+No
+</td>
+</tr>
+<tr id="Sidecar-outbound_traffic_policy">
+<td><code>outboundTrafficPolicy</code></td>
+<td><code><a href="#OutboundTrafficPolicy">OutboundTrafficPolicy</a></code></td>
+<td>
+<p>Configuration for the outbound traffic policy.  If your
+application uses one or more external services that are not known
+apriori, setting the policy to <code>ALLOW_ANY</code> will cause the
+sidecars to route any unknown traffic originating from the
+application to its requested destination. If not specified,
+inherits the system detected defaults from the namespace-wide or
+the global default Sidecar.</p>
+
+</td>
+<td>
+No
+</td>
+</tr>
+</tbody>
+</table>
+</section>
+<h2 id="IstioIngressListener">IstioIngressListener</h2>
+<section>
+<p><code>IstioIngressListener</code> specifies the properties of an inbound
+traffic listener on the sidecar proxy attached to a workload instance.</p>
+
+<table class="message-fields">
+<thead>
+<tr>
+<th>Field</th>
+<th>Type</th>
+<th>Description</th>
+<th>Required</th>
+</tr>
+</thead>
+<tbody>
+<tr id="IstioIngressListener-port">
+<td><code>port</code></td>
+<td><code><a href="https://istio.io/docs/reference/config/networking/gateway.html#Port">Port</a></code></td>
+<td>
+<p>The port associated with the listener.</p>
+
+</td>
+<td>
+Yes
+</td>
+</tr>
+<tr id="IstioIngressListener-bind">
+<td><code>bind</code></td>
+<td><code>string</code></td>
+<td>
+<p>The IP to which the listener should be bound. Must be in the
+format <code>x.x.x.x</code>. Unix domain socket addresses are not allowed in
+the bind field for ingress listeners. If omitted, Istio will
+automatically configure the defaults based on imported services
+and the workload instances to which this configuration is applied
+to.</p>
+
+</td>
+<td>
+No
+</td>
+</tr>
+<tr id="IstioIngressListener-capture_mode">
+<td><code>captureMode</code></td>
+<td><code><a href="#CaptureMode">CaptureMode</a></code></td>
+<td>
+<p>The captureMode option dictates how traffic to the listener is
+expected to be captured (or not).</p>
+
+</td>
+<td>
+No
+</td>
+</tr>
+<tr id="IstioIngressListener-default_endpoint">
+<td><code>defaultEndpoint</code></td>
+<td><code>string</code></td>
+<td>
+<p>The loopback IP endpoint or Unix domain socket to which
+traffic should be forwarded to. This configuration can be used to
+redirect traffic arriving at the bind <code>IP:Port</code> on the sidecar to a <code>localhost:port</code>
+or Unix domain socket where the application workload instance is listening for
+connections. Format should be <code>127.0.0.1:PORT</code> or <code>unix:///path/to/socket</code></p>
+
+</td>
+<td>
+Yes
 </td>
 </tr>
 </tbody>
@@ -357,10 +661,17 @@ Yes
 </tbody>
 </table>
 </section>
-<h2 id="IstioIngressListener">IstioIngressListener</h2>
+<h2 id="WorkloadSelector">WorkloadSelector</h2>
 <section>
-<p><code>IstioIngressListener</code> specifies the properties of an inbound
-traffic listener on the sidecar proxy attached to a workload instance.</p>
+<p><code>WorkloadSelector</code> specifies the criteria used to determine if the
+<code>Gateway</code>, <code>Sidecar</code>, or <code>EnvoyFilter</code> or <code>ServiceEntry</code>
+configuration can be applied to a proxy. The matching criteria
+includes the metadata associated with a proxy, workload instance
+info such as labels attached to the pod/VM, or any other info that
+the proxy provides to Istio during the initial handshake. If
+multiple conditions are specified, all conditions need to match in
+order for the workload instance to be selected. Currently, only
+label based selection mechanism is supported.</p>

 <table class="message-fields">
 <thead>
@@ -372,54 +683,14 @@ traffic listener on the sidecar proxy attached to a workload instance.</p>
 </tr>
 </thead>
 <tbody>
-<tr id="IstioIngressListener-port">
-<td><code>port</code></td>
-<td><code><a href="https://istio.io/docs/reference/config/networking/gateway.html#Port">Port</a></code></td>
+<tr id="WorkloadSelector-labels">
+<td><code>labels</code></td>
+<td><code>map&lt;string,&nbsp;string&gt;</code></td>
 <td>
-<p>The port associated with the listener.</p>
-
-</td>
-<td>
-Yes
-</td>
-</tr>
-<tr id="IstioIngressListener-bind">
-<td><code>bind</code></td>
-<td><code>string</code></td>
-<td>
-<p>The IP to which the listener should be bound. Must be in the
-format <code>x.x.x.x</code>. Unix domain socket addresses are not allowed in
-the bind field for ingress listeners. If omitted, Istio will
-automatically configure the defaults based on imported services
-and the workload instances to which this configuration is applied
-to.</p>
-
-</td>
-<td>
-No
-</td>
-</tr>
-<tr id="IstioIngressListener-capture_mode">
-<td><code>captureMode</code></td>
-<td><code><a href="#CaptureMode">CaptureMode</a></code></td>
-<td>
-<p>The captureMode option dictates how traffic to the listener is
-expected to be captured (or not).</p>
-
-</td>
-<td>
-No
-</td>
-</tr>
-<tr id="IstioIngressListener-default_endpoint">
-<td><code>defaultEndpoint</code></td>
-<td><code>string</code></td>
-<td>
-<p>The loopback IP endpoint or Unix domain socket to which
-traffic should be forwarded to. This configuration can be used to
-redirect traffic arriving at the bind <code>IP:Port</code> on the sidecar to a <code>localhost:port</code>
-or Unix domain socket where the application workload instance is listening for
-connections. Format should be <code>127.0.0.1:PORT</code> or <code>unix:///path/to/socket</code></p>
+<p>One or more labels that indicate a specific set of pods/VMs
+on which the configuration should be applied. The scope of
+label search is restricted to the configuration namespace in which the
+the resource is present.</p>

 </td>
 <td>
@@ -492,114 +763,42 @@ there are no services or <code>ServiceEntry</code> configurations for the destin
 </tbody>
 </table>
 </section>
-<h2 id="Sidecar">Sidecar</h2>
+<h2 id="CaptureMode">CaptureMode</h2>
 <section>
-<p><code>Sidecar</code> describes the configuration of the sidecar proxy that mediates
-inbound and outbound communication of the workload instance to which it is
-attached.</p>
+<p><code>CaptureMode</code> describes how traffic to a listener is expected to be
+captured. Applicable only when the listener is bound to an IP.</p>

-<table class="message-fields">
+<table class="enum-values">
 <thead>
 <tr>
-<th>Field</th>
-<th>Type</th>
+<th>Name</th>
 <th>Description</th>
-<th>Required</th>
 </tr>
 </thead>
 <tbody>
-<tr id="Sidecar-workload_selector">
-<td><code>workloadSelector</code></td>
-<td><code><a href="#WorkloadSelector">WorkloadSelector</a></code></td>
+<tr id="CaptureMode-DEFAULT">
+<td><code>DEFAULT</code></td>
 <td>
-<p>Criteria used to select the specific set of pods/VMs on which this
-<code>Sidecar</code> configuration should be applied. If omitted, the <code>Sidecar</code>
-configuration will be applied to all workload instances in the same namespace.</p>
+<p>The default capture mode defined by the environment.</p>

-</td>
-<td>
-No
 </td>
 </tr>
-<tr id="Sidecar-ingress">
-<td><code>ingress</code></td>
-<td><code><a href="#IstioIngressListener">IstioIngressListener[]</a></code></td>
+<tr id="CaptureMode-IPTABLES">
+<td><code>IPTABLES</code></td>
 <td>
-<p>Ingress specifies the configuration of the sidecar for processing
-inbound traffic to the attached workload instance. If omitted, Istio will
-automatically configure the sidecar based on the information about the workload
-obtained from the orchestration platform (e.g., exposed ports, services,
-etc.). If specified, inbound ports are configured if and only if the
-workload instance is associated with a service.</p>
+<p>Capture traffic using IPtables redirection.</p>

-</td>
-<td>
-No
 </td>
 </tr>
-<tr id="Sidecar-egress">
-<td><code>egress</code></td>
-<td><code><a href="#IstioEgressListener">IstioEgressListener[]</a></code></td>
+<tr id="CaptureMode-NONE">
+<td><code>NONE</code></td>
 <td>
-<p>Egress specifies the configuration of the sidecar for processing
-outbound traffic from the attached workload instance to other services in the
-mesh.</p>
+<p>No traffic capture. When used in an egress listener, the application is
+expected to explicitly communicate with the listener port or Unix
+domain socket. When used in an ingress listener, care needs to be taken
+to ensure that the listener port is not in use by other processes on
+the host.</p>

-</td>
-<td>
-Yes
-</td>
-</tr>
-<tr id="Sidecar-outbound_traffic_policy">
-<td><code>outboundTrafficPolicy</code></td>
-<td><code><a href="#OutboundTrafficPolicy">OutboundTrafficPolicy</a></code></td>
-<td>
-<p>This allows to configure the outbound traffic policy.
-If your application uses one or more external
-services that are not known apriori, setting the policy to <code>ALLOW_ANY</code>
-will cause the sidecars to route any unknown traffic originating from
-the application to its requested destination.</p>
-
-</td>
-<td>
-No
-</td>
-</tr>
-</tbody>
-</table>
-</section>
-<h2 id="WorkloadSelector">WorkloadSelector</h2>
-<section>
-<p><code>WorkloadSelector</code> specifies the criteria used to determine if the <code>Gateway</code>,
-<code>Sidecar</code>, or <code>EnvoyFilter</code> configuration can be applied to a proxy. The matching criteria
-includes the metadata associated with a proxy, workload instance info such as
-labels attached to the pod/VM, or any other info that the proxy provides
-to Istio during the initial handshake. If multiple conditions are
-specified, all conditions need to match in order for the workload instance to be
-selected. Currently, only label based selection mechanism is supported.</p>
-
-<table class="message-fields">
-<thead>
-<tr>
-<th>Field</th>
-<th>Type</th>
-<th>Description</th>
-<th>Required</th>
-</tr>
-</thead>
-<tbody>
-<tr id="WorkloadSelector-labels">
-<td><code>labels</code></td>
-<td><code>map&lt;string,&nbsp;string&gt;</code></td>
-<td>
-<p>One or more labels that indicate a specific set of pods/VMs
-on which this <code>Sidecar</code> configuration should be applied. The scope of
-label search is restricted to the configuration namespace in which the
-the resource is present.</p>
-
-</td>
-<td>
-Yes
 </td>
 </tr>
 </tbody>