new networking reference docs (#3358)

2019-02-25 20:13:27 -05:00 · 2019-02-25 20:13:27 -05:00 · 2baef16e51
parent 860fd27e91
commit 2baef16e51
34 changed files with 4788 additions and 4742 deletions
--- a/content/about/notes/1.0.3/index.md
+++ b/content/about/notes/1.0.3/index.md
@ -13,7 +13,7 @@ This release note describes what's different between Istio 1.0.2 and Istio 1.0.3

 - [Validating webhook](/help/ops/setup/validation) is now mandatory. Disabling it may result in Pilot crashes.

- [Service entry](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry) validation now rejects the wildcard hostname (`*`) when configuring DNS resolution. The API has never allowed this, however `ServiceEntry` was erroneously excluded from validation in the previous release. Use of wildcards as part of a hostname, e.g. `*.bar.com`, remains unchanged.
+- [Service entry](/docs/reference/config/networking/v1alpha3/service-entry/) validation now rejects the wildcard hostname (`*`) when configuring DNS resolution. The API has never allowed this, however `ServiceEntry` was erroneously excluded from validation in the previous release. Use of wildcards as part of a hostname, e.g. `*.bar.com`, remains unchanged.

 - The core dump path for `istio-proxy` has changed to `/var/lib/istio`.

--- a/content/about/notes/1.0/index.md
+++ b/content/about/notes/1.0/index.md
@ -15,7 +15,7 @@ relative to 0.8 as most of the effort for this release went into fixing bugs and
 ## Networking

 - **SNI Routing using Virtual Services**. Newly introduced `TLS` sections in
-[`VirtualService`](/docs/reference/config/istio.networking.v1alpha3/#VirtualService) can be used to route TLS traffic
+[`VirtualService`](/docs/reference/config/networking/v1alpha3/virtual-service/) can be used to route TLS traffic
 based on SNI values. Service ports named as TLS/HTTPS can be used in conjunction with
 virtual service TLS routes. TLS/HTTPS ports without an accompanying virtual service will be treated as opaque TCP.

@ -104,4 +104,4 @@ be configured using [authentication policies](/docs/concepts/security/#authentic
  for more details.

 - Mesh expansion functionality, which lets you add raw VMs to a mesh is broken in 1.0. We're expecting to produce a
-patch that fixes this problem within a few days.
+patch that fixes this problem within a few days.
--- a/content/blog/2018/egress-https/index.md
+++ b/content/blog/2018/egress-https/index.md
@ -93,7 +93,7 @@ So what might have gone wrong? Ah... The answer is that I forgot to tell you to
 an external service, in this case to the Google Books web service. By default, the Istio sidecar proxies
 ([Envoy proxies](https://www.envoyproxy.io)) **block all the traffic to destinations outside the cluster**. To enable
 such traffic, you must define a
-[mesh-external service entry](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry).
+[mesh-external service entry](/docs/reference/config/networking/v1alpha3/service-entry/).

 ### Enable HTTPS access to a Google Books web service

--- a/content/blog/2018/egress-mongo/index.md
+++ b/content/blog/2018/egress-mongo/index.md
@ -121,7 +121,7 @@ _reviews_ service always calls the _ratings_ service. In addition, route all the
 service to _ratings v2_ that uses your database.

    Specify the routing for both services above by adding two
-    [virtual services](/docs/reference/config/istio.networking.v1alpha3/#VirtualService). These virtual services are
+    [virtual services](/docs/reference/config/networking/v1alpha3/virtual-service/). These virtual services are
    specified in `samples/bookinfo/networking/virtual-service-ratings-mongodb.yaml` of an Istio release archive.
    ***Important:*** make sure you
    [applied the default destination rules](/docs/examples/bookinfo/#apply-default-destination-rules) before running the
--- a/content/blog/2018/egress-tcp/index.md
+++ b/content/blog/2018/egress-tcp/index.md
@ -20,7 +20,7 @@ In my previous blog post, [Consuming External Web Services](/blog/2018/egress-ht
 over TCP. You will use the [Istio Bookinfo sample application](/docs/examples/bookinfo/), the version in which the book
  ratings data is persisted in a MySQL database. You deploy this database outside the cluster and configure the
  _ratings_ microservice to use it. You define a
- [Service Entry](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry) to allow the in-mesh applications to
+ [Service Entry](/docs/reference/config/networking/v1alpha3/service-entry/) to allow the in-mesh applications to
 access the external database.

 ## Bookinfo sample application with external ratings database
@ -203,7 +203,7 @@ _reviews_ service always calls the _ratings_ service. In addition, route all the
 service to _ratings v2-mysql_ that uses your database.

    Specify the routing for both services above by adding two
-    [virtual services](/docs/reference/config/istio.networking.v1alpha3/#VirtualService). These virtual services are
+    [virtual services](/docs/reference/config/networking/v1alpha3/virtual-service/). These virtual services are
    specified in `samples/bookinfo/networking/virtual-service-ratings-mysql.yaml` of an Istio release archive.
    ***Important:*** make sure you
    [applied the default destination rules](/docs/examples/bookinfo/#apply-default-destination-rules) before running the
--- a/content/blog/2018/v1alpha3-routing/index.md
+++ b/content/blog/2018/v1alpha3-routing/index.md
@ -76,7 +76,7 @@ resources.

 ### `Gateway`

-A [`Gateway`](/docs/reference/config/istio.networking.v1alpha3/#Gateway)
+A [`Gateway`](/docs/reference/config/networking/v1alpha3/gateway/)
 configures a load balancer for HTTP/TCP traffic, regardless of
 where it will be running.  Any number of gateways can exist within the mesh
 and multiple different gateway implementations can co-exist. In fact, a
@ -156,7 +156,7 @@ scalability issues with the previous model.
 In effect, what has changed is that instead of configuring routing using a set of individual configuration resources
 (rules) for a particular destination service, each containing a precedence field to control the order of evaluation, we
 now configure the (virtual) destination itself, with all of its rules in an ordered list within a corresponding
-[`VirtualService`](/docs/reference/config/istio.networking.v1alpha3/#VirtualService) resource.
+[`VirtualService`](/docs/reference/config/networking/v1alpha3/virtual-service/) resource.
 For example, where previously we had two `RouteRule` resources for the
 [Bookinfo](/docs/examples/bookinfo/) application’s `reviews` service, like this:

@ -274,7 +274,7 @@ In addition to this fundamental restructuring, `VirtualService` includes several

 ### `DestinationRule`

-A [`DestinationRule`](/docs/reference/config/istio.networking.v1alpha3/#DestinationRule)
+A [`DestinationRule`](/docs/reference/config/networking/v1alpha3/destination-rule/)
 configures the set of policies to be applied while forwarding traffic to a service. They are
 intended to be authored by service owners, describing the circuit breakers, load balancer settings, TLS settings, etc..
 `DestinationRule` is more or less the same as its predecessor, `DestinationPolicy`, with the following exceptions:
@ -318,7 +318,7 @@ Notice that, unlike `DestinationPolicy`, multiple policies (e.g., default and v2

 ### `ServiceEntry`

-[`ServiceEntry`](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry)
+[`ServiceEntry`](/docs/reference/config/networking/v1alpha3/service-entry/)
 is used to add additional entries into the service registry that Istio maintains internally.
 It is most commonly used to allow one to model traffic to external dependencies of the mesh
 such as APIs consumed from the web or traffic to services in legacy infrastructure.
--- a/content/blog/2019/custom-ingress-gateway/index.md
+++ b/content/blog/2019/custom-ingress-gateway/index.md
@ -7,7 +7,7 @@ keywords: [ingress,traffic-management]
 attribution: Julien Senon
 ---

-This post provides instructions to manually create a custom ingress [gateway](/docs/reference/config/istio.networking.v1alpha3/#Gateway) with automatic provisioning of certificates based on cert-manager.
+This post provides instructions to manually create a custom ingress [gateway](/docs/reference/config/networking/v1alpha3/gateway/) with automatic provisioning of certificates based on cert-manager.

 The creation of custom ingress gateway could be used in order to have different `loadbalancer` in order to isolate traffic.

@ -230,4 +230,4 @@ The creation of custom ingress gateway could be used in order to have different
      SSL certificate verify ok.
    {{< /text >}}

-**Congratulations!** You can now use your custom `istio-custom-gateway` [gateway](/docs/reference/config/istio.networking.v1alpha3/#Gateway) configuration object.
+**Congratulations!** You can now use your custom `istio-custom-gateway` [gateway](/docs/reference/config/networking/v1alpha3/gateway/) configuration object.
--- a/content/docs/concepts/security/index.md
+++ b/content/docs/concepts/security/index.md
@ -327,7 +327,7 @@ work. As you'll remember from the [Architecture section](/docs/concepts/security
 authentication policies apply to requests that a service **receives**. To
 specify client-side authentication rules in mutual TLS, you need to specify the
 `TLSSettings` in the `DestinationRule`. You can find more information in our
-[TLS settings reference docs](/docs/reference/config/istio.networking.v1alpha3/#TLSSettings).
+[TLS settings reference docs](/docs/reference/config/networking/v1alpha3/destination-rule/#TLSSettings).
 Like other Istio configuration, you can specify authentication policies in
 `.yaml` files. You deploy policies using `kubectl`.

--- a/content/docs/concepts/traffic-management/index.md
+++ b/content/docs/concepts/traffic-management/index.md
@ -80,7 +80,7 @@ dynamic updates to load balancing pools
 and routing tables.

 You can specify high-level traffic management rules through
-[Pilot's Rule configuration](/docs/reference/config/istio.networking.v1alpha3/). These rules are translated into low-level
+[Pilot's Rule configuration](/docs/reference/config/networking/). These rules are translated into low-level
 configurations and distributed to Envoy instances.

 ## Request routing
@ -232,8 +232,8 @@ and prevent localized failures from cascading instability to other nodes.

 Istio's traffic management rules allow you to set defaults for failure recovery per
 service and version that apply to all callers. However, consumers of a service can also
-override [timeout](/docs/reference/config/istio.networking.v1alpha3/#HTTPRoute-timeout)
-and [retry](/docs/reference/config/istio.networking.v1alpha3/#HTTPRoute-retries)
+override [timeout](/docs/reference/config/networking/v1alpha3/virtual-service/#HTTPRoute-timeout)
+and [retry](/docs/reference/config/networking/v1alpha3/virtual-service/#HTTPRoute-retries)
 defaults by providing request-level overrides through special HTTP headers.
 With the Envoy proxy implementation, the headers are `x-envoy-upstream-rq-timeout-ms` and
 `x-envoy-max-retries`, respectively.
@ -331,15 +331,15 @@ etc.
 There are four traffic management configuration resources in Istio:
 `VirtualService`, `DestinationRule`, `ServiceEntry`, and `Gateway`:

-* A [`VirtualService`](/docs/reference/config/istio.networking.v1alpha3/#VirtualService)
+* A [`VirtualService`](/docs/reference/config/networking/v1alpha3/virtual-service/)
 defines the rules that control how requests for a service are routed within an Istio service mesh.

-* A [`DestinationRule`](/docs/reference/config/istio.networking.v1alpha3/#DestinationRule)
+* A [`DestinationRule`](/docs/reference/config/networking/v1alpha3/destination-rule/)
 configures the set of policies to be applied to a request after `VirtualService` routing has occurred.

-* A [`ServiceEntry`](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry) is commonly used to enable requests to services outside of an Istio service mesh.
+* A [`ServiceEntry`](/docs/reference/config/networking/v1alpha3/service-entry/) is commonly used to enable requests to services outside of an Istio service mesh.

-* A [`Gateway`](/docs/reference/config/istio.networking.v1alpha3/#Gateway)
+* A [`Gateway`](/docs/reference/config/networking/v1alpha3/gateway/)
 configures a load balancer for HTTP/TCP traffic, most commonly operating at the edge of the mesh to enable ingress traffic for an application.

 For example, you can implement a simple rule to send 100% of incoming traffic for a *reviews* service to version "v1" by using a `VirtualService` configuration as follows:
@ -393,12 +393,12 @@ Rules can be configured using the `kubectl` command. See the
 task](/docs/tasks/traffic-management/request-routing/) for examples.

 The following sections provide a basic overview of the traffic management configuration resources.
-See [networking reference](/docs/reference/config/istio.networking.v1alpha3/)
+See [networking reference](/docs/reference/config/networking/)
 for detailed information.

 ### Virtual Services

-A [`VirtualService`](/docs/reference/config/istio.networking.v1alpha3/#VirtualService)
+A [`VirtualService`](/docs/reference/config/networking/v1alpha3/virtual-service/)
 defines the rules that control how requests for a service are routed within an Istio service mesh.
 For example, a virtual service could route requests to different versions of a service or to a completely different service than was requested.
 Requests can be routed based on the request source and destination, HTTP paths and
@ -786,7 +786,7 @@ priorities of each rule when there is more than one.

 ### Destination rules

-A [`DestinationRule`](/docs/reference/config/istio.networking.v1alpha3/#DestinationRule)
+A [`DestinationRule`](/docs/reference/config/networking/v1alpha3/destination-rule/)
 configures the set of policies to be applied to a request after `VirtualService` routing has occurred. They are
 intended to be authored by service owners, describing the circuit breakers, load balancer settings, TLS settings, and other settings.

@ -941,7 +941,7 @@ start, is generally considered a best practice in Istio.

 ### Service entries

-A [`ServiceEntry`](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry)
+A [`ServiceEntry`](/docs/reference/config/networking/v1alpha3/service-entry/)
 is used to add additional entries into the service registry that Istio maintains internally.
 It is most commonly used to enable requests to services outside of an Istio service mesh.
 For example, the following `ServiceEntry` can be used to allow external calls to services hosted
@ -1008,7 +1008,7 @@ about accessing external services.

 ### Gateways

-A [Gateway](/docs/reference/config/istio.networking.v1alpha3/#Gateway)
+A [Gateway](/docs/reference/config/networking/v1alpha3/gateway/)
 configures a load balancer for HTTP/TCP traffic, most commonly operating at the edge of the
 mesh to enable ingress traffic for an application.

@ -1069,5 +1069,5 @@ complete ingress gateway example.
 Although primarily used to manage ingress traffic, a `Gateway` can also be used to model
 a purely internal or egress proxy. Irrespective of the location, all gateways
 can be configured and controlled in the same way. See
-[gateway reference](/docs/reference/config/istio.networking.v1alpha3/#Gateway)
+[gateway reference](/docs/reference/config/networking/v1alpha3/gateway/)
 for details.
--- a/content/docs/examples/advanced-gateways/egress-gateway/index.md
+++ b/content/docs/examples/advanced-gateways/egress-gateway/index.md
@ -11,7 +11,7 @@ There, the external services are called directly from the client sidecar.
 This example also shows how to configure Istio to call external services, although this time
 indirectly via a dedicated _egress gateway_ service.

-Istio uses [ingress and egress gateways](/docs/reference/config/istio.networking.v1alpha3/#Gateway)
+Istio uses [ingress and egress gateways](/docs/reference/config/networking/v1alpha3/gateway/)
 to configure load balancers executing at the edge of a service mesh.
 An ingress gateway allows you to define entry points into the mesh that all incoming traffic flows through.
 Egress gateway is a symmetrical concept; it defines exit points from the mesh. Egress gateways allow
--- a/content/docs/examples/advanced-gateways/egress-tls-origination/index.md
+++ b/content/docs/examples/advanced-gateways/egress-tls-origination/index.md
@ -8,7 +8,7 @@ weight: 20
 The [Control Egress Traffic](/docs/tasks/traffic-management/egress/) task demonstrates how external, i.e., outside of the
 service mesh, HTTP and HTTPS services can be accessed from applications inside the mesh. As described in that task,
 by default Istio-enabled applications are unable to access URLs outside of the cluster. To enable external access,
-a [`ServiceEntry`](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry) for the external service must be
+a [`ServiceEntry`](/docs/reference/config/networking/v1alpha3/service-entry/) for the external service must be
 defined, or alternatively, [direct access to external services](/docs/tasks/traffic-management/egress/#direct-access-to-external-services)
 must be configured.

--- a/content/docs/reference/config/authorization/istio.rbac.v1alpha1/index.html
+++ b/content/docs/reference/config/authorization/istio.rbac.v1alpha1/index.html
@ -1,10 +1,10 @@
 ---
-WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE https://github.com/istio/api REPO
-source_repo: https://github.com/istio/api
+WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE istio REPO
+source_repo: istio
 title: RBAC
 description: Configuration for Role Based Access Control.
 location: https://istio.io/docs/reference/config/authorization/istio.rbac.v1alpha1.html
-layout: protoc-gen-docs
+layout: partner-component
 generator: protoc-gen-docs
 number_of_entries: 9
 ---
--- a/content/docs/reference/config/istio.authentication.v1alpha1/index.html
+++ b/content/docs/reference/config/istio.authentication.v1alpha1/index.html
@ -1,10 +1,10 @@
 ---
-WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE https://github.com/istio/api REPO
-source_repo: https://github.com/istio/api
+WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE istio REPO
+source_repo: istio
 title: Authentication Policy
 description: Authentication policy for Istio services.
 location: https://istio.io/docs/reference/config/istio.authentication.v1alpha1.html
-layout: protoc-gen-docs
+layout: partner-component
 generator: protoc-gen-docs
 number_of_entries: 11
 ---
@ -13,7 +13,7 @@ number_of_entries: 11
 <h2 id="Jwt">Jwt</h2>
 <section>
 <p>JSON Web Token (JWT) token format for authentication as defined by
-<a href="https://tools.ietf.org/html/rfc7519">RFC 7519</a>. See <a href="https://tools.ietf.org/html/rfc6749">OAuth
+https://tools.ietf.org/html/rfc7519. See <a href="https://tools.ietf.org/html/rfc6749">OAuth
 2.0</a> and <a href="http://openid.net/connect">OIDC
 1.0</a> for how this is used in the whole
 authentication flow.</p>
@ -337,13 +337,12 @@ or origin) should be used as principal. By default, it uses peer.</p>

 <p>Examples:</p>

-<p>Policy to enable mTLS for all services in namespace frod. The policy name must be
-<code>default</code>, and it contains no rule for <code>targets</code>.</p>
+<p>Policy to enable mTLS for all services in namespace frod</p>

 <pre><code class="language-yaml">apiVersion: authentication.istio.io/v1alpha1
 kind: Policy
 metadata:
-  name: default
+  name: mTLS_enable
  namespace: frod
 spec:
  peers:
@ -355,7 +354,7 @@ spec:
 <pre><code class="language-yaml">apiVersion: authentication.istio.io/v1alpha1
 kind: Policy
 metadata:
-  name: productpage_mTLS_disable
+  name: mTLS_disable
  namespace: frod
 spec:
  targets:
@ -368,7 +367,7 @@ for productpage:9000 except the path &lsquo;/health_check&rsquo; . Principal is
 <pre><code class="language-yaml">apiVersion: authentication.istio.io/v1alpha1
 kind: Policy
 metadata:
-  name: productpage_mTLS_with_JWT
+  name: mTLS_enable
  namespace: frod
 spec:
  target:
--- a/content/docs/reference/config/istio.mesh.v1alpha1/index.html
+++ b/content/docs/reference/config/istio.mesh.v1alpha1/index.html
@ -1,10 +1,10 @@
 ---
-WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE https://github.com/istio/api REPO
-source_repo: https://github.com/istio/api
+WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE istio REPO
+source_repo: istio
 title: Service Mesh
 description: Configuration affecting the service mesh as a whole.
 location: https://istio.io/docs/reference/config/istio.mesh.v1alpha1.html
-layout: protoc-gen-docs
+layout: partner-component
 generator: protoc-gen-docs
 number_of_entries: 19
 ---
@ -95,7 +95,7 @@ distribution of traffic to endpoints based on the localities of where the
 traffic originates and where it will terminate. These localities are
 specified using arbitrary labels that designate a hierarchy of localities in
 &lbrace;region}/&lbrace;zone}/&lbrace;sub-zone} form. For additional detail refer to
-<a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing/locality_weight">Locality Weight</a>
+https://www.envoyproxy.io/docs/envoy/latest/intro/arch<em>overview/load</em>balancing/locality_weight
 The following example shows how to setup locality weights mesh-wide.</p>

 <p>Given a mesh with workloads and their service deployed to &ldquo;us-west/zone1/<em>&rdquo;
@ -477,7 +477,7 @@ can be configured for a single control plane.</p>
 <td><code>string</code></td>
 <td>
 <p>The trust domain corresponds to the trust root of a system.
-Refer to <a href="https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md#21-trust-domain">SPIFEE-ID</a>
+Refer to https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md#21-trust-domain
 Fallback to old identity format(without trust domain) if not set.</p>

 </td>
@ -896,16 +896,6 @@ DEPRECATED: Use <a href="#ProxyConfig-tracing">tracing</a> instead.</p>
 <td>
 <p>IP Address and Port of a statsd UDP listener (e.g. <em>10.75.241.127:9125</em>).</p>

-</td>
-</tr>
-<tr id="ProxyConfig-envoy_metrics_service_address">
-<td><code>envoyMetricsServiceAddress</code></td>
-<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
-for details about Envoy&rsquo;s Metrics Service API.</p>
-
 </td>
 </tr>
 <tr id="ProxyConfig-proxy_admin_port">
--- a/content/docs/reference/config/istio.networking.v1alpha3/index.html
+++ b/content/docs/reference/config/istio.networking.v1alpha3/index.html
--- a/content/docs/reference/config/networking/_index.md
+++ b/content/docs/reference/config/networking/_index.md
@ -0,0 +1,9 @@
+---
+title: Traffic Management
+description: Describes how to configure HTTP/TCP routing features.
+weight: 11
+type: section-index
+aliases:
+    - /docs/reference/config/istio.routing.v1alpha1/
+    - /docs/reference/config/istio.networking.v1alpha3/
+---
--- a/content/docs/reference/config/networking/v1alpha3/destination-rule/index.html
+++ b/content/docs/reference/config/networking/v1alpha3/destination-rule/index.html
--- a/content/docs/reference/config/networking/v1alpha3/envoy-filter/index.html
+++ b/content/docs/reference/config/networking/v1alpha3/envoy-filter/index.html
@ -0,0 +1,402 @@
+---
+WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE https://github.com/rshriram/api REPO
+source_repo: https://github.com/rshriram/api
+title: Envoy Filter
+description: Configuration affecting insertion of custom envoy filters.
+location: https://istio.io/docs/reference/config/networking/v1alpha3/envoy-filter.html
+layout: partner-component
+generator: protoc-gen-docs
+number_of_entries: 8
+---
+<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>
+
+<h2 id="EnvoyFilter">EnvoyFilter</h2>
+<section>
+<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>
--- a/content/docs/reference/config/networking/v1alpha3/gateway/index.html
+++ b/content/docs/reference/config/networking/v1alpha3/gateway/index.html
@ -0,0 +1,565 @@
+---
+WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE https://github.com/rshriram/api REPO
+source_repo: https://github.com/rshriram/api
+title: Gateway
+description: Configuration affecting edge load balancer.
+location: https://istio.io/docs/reference/config/networking/v1alpha3/gateway.html
+layout: partner-component
+generator: protoc-gen-docs
+number_of_entries: 6
+---
+<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>
+
+<h2 id="Gateway">Gateway</h2>
+<section>
+<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 restricted to the configuration namespace in which the
+the resource is present. In other words, the Gateway resource must
+reside in the same namespace as the gateway workload.</p>
+
+</td>
+</tr>
+</tbody>
+</table>
+</section>
+<h2 id="Port">Port</h2>
+<section>
+<p>Port describes the properties of a specific port of a service.</p>
+
+<table class="message-fields">
+<thead>
+<tr>
+<th>Field</th>
+<th>Type</th>
+<th>Description</th>
+</tr>
+</thead>
+<tbody>
+<tr id="Port-number">
+<td><code>number</code></td>
+<td><code>uint32</code></td>
+<td>
+<p>REQUIRED: A valid non-negative integer port number.</p>
+
+</td>
+</tr>
+<tr id="Port-protocol">
+<td><code>protocol</code></td>
+<td><code>string</code></td>
+<td>
+<p>REQUIRED: The protocol exposed on the port.
+MUST BE one of HTTP|HTTPS|GRPC|HTTP2|MONGO|TCP|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="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. If using unix domain socket, use 0 as the port number,
+with a valid protocol and port name, along with the bind parameter.</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>
+<tr id="Server-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 by default. Format should be 127.0.0.1:PORT or
+unix:///path/to/socket or unix://@foobar (Linux abstract namespace).</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-credential_name">
+<td><code>credentialName</code></td>
+<td><code>string</code></td>
+<td>
+<p>The credentialName stands for a unique identifier that can be used
+to identify the serverCertificate and the privateKey. The credentialName
+appended with suffix &ldquo;-cacert&rdquo; is used to identify the CaCertificates
+associated with this server. Gateway workloads capable of fetching
+credentials from a remote credential store 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
+credentialName-cacert. The semantics of the name are platform dependent.
+In Kubernetes, the default Istio supplied credential server expects the
+credentialName to match the name of the Kubernetes secret that holds the
+server certificate, the private key, and the CA certificate
+(if using mutual TLS).</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>
--- a/content/docs/reference/config/networking/v1alpha3/service-entry/index.html
+++ b/content/docs/reference/config/networking/v1alpha3/service-entry/index.html
@ -0,0 +1,614 @@
+---
+WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE https://github.com/rshriram/api REPO
+source_repo: https://github.com/rshriram/api
+title: Service Entry
+description: Configuration affecting service registry.
+location: https://istio.io/docs/reference/config/networking/v1alpha3/service-entry.html
+layout: partner-component
+generator: protoc-gen-docs
+number_of_entries: 4
+---
+<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.
+The &lsquo;exportTo&rsquo; field allows for control over the visibility of a service
+declaration to other namespaces in the mesh. By default a service is exported
+to all namespaces. The following example restricts the visibility to the
+current namespace, represented by &ldquo;.&rdquo;, so that it cannot be used by other
+namespaces.</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
+kind: ServiceEntry
+metadata:
+  name: external-svc-httpbin
+  namespace : egress
+spec:
+  hosts:
+  - httpbin.com
+  exportTo:
+  - &quot;.&quot;
+  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
+ namespace: egress
+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. 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
+a managed middle proxy like this is a common practice.</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
+kind: VirtualService
+metadata:
+  name: gateway-routing
+  namespace: egress
+spec:
+  hosts:
+  - httpbin.com
+  exportTo:
+  - *
+  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 <code>HTTP_PROXY=http://localhost/</code>, calls from the application to
+<code>http://foo.bar.com</code> will be load balanced across the three domains
+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
+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>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
+kind: ServiceEntry
+metadata:
+  name: httpbin
+  namespace : httpbin-ns
+spec:
+  hosts:
+  - httpbin.com
+  location: MESH_INTERNAL
+  ports:
+  - number: 80
+    name: http
+    protocol: HTTP
+  resolution: STATIC
+  endpoints:
+  - address: 2.2.2.2
+  - address: 3.3.3.3
+  subjectAltNames:
+  - &quot;spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account&quot;
+</code></pre>
+
+<h2 id="ServiceEntry">ServiceEntry</h2>
+<section>
+<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="/docs/reference/config/networking/v1alpha3/gateway.html#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-export_to">
+<td><code>exportTo</code></td>
+<td><code>string[]</code></td>
+<td>
+<p>A list of namespaces to which this service is exported. Exporting a service
+allows it to used by sidecars, gateways and virtual services defined in
+other namespaces. This feature provides a mechanism for service owners
+and mesh administrators to control the visibility of services across
+namespace boundaries.</p>
+
+<p>If no namespaces are specified then the service is exported to all
+namespaces by default.</p>
+
+<p>The value &ldquo;.&rdquo; is reserved and defines an export to the same namespace that
+the service is declared in, similarly the value &ldquo;*&rdquo; is reserved and
+defines an export to all namespaces.</p>
+
+<p>For a Kubernetes Service the equivalent effect can be achieved by setting
+the annotation &ldquo;networking.istio.io/exportTo&rdquo; to a comma-separated list
+of namespace names.</p>
+
+</td>
+</tr>
+<tr id="ServiceEntry-subject_alt_names">
+<td><code>subjectAltNames</code></td>
+<td><code>string[]</code></td>
+<td>
+<p>The list of subject alternate names allowed for workloads that
+implement this service. This information is used to enforce
+<a href="/docs/concepts/security/#secure-naming">secure-naming</a>.
+If specified, the proxy will verify that the server
+certificate&rsquo;s subject alternate name matches one of the specified values.</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>
--- a/content/docs/reference/config/networking/v1alpha3/sidecar/index.html
+++ b/content/docs/reference/config/networking/v1alpha3/sidecar/index.html
@ -0,0 +1,350 @@
+---
+WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE https://github.com/rshriram/api REPO
+source_repo: https://github.com/rshriram/api
+title: Sidecar
+description: Configuration affecting network reachability of a sidecar.
+location: https://istio.io/docs/reference/config/networking/v1alpha3/sidecar.html
+layout: partner-component
+generator: protoc-gen-docs
+number_of_entries: 5
+---
+<p><code>Sidecar</code> describes the configuration of the sidecar proxy that mediates
+inbound and outbound communication to the workload it is attached to. By
+default, Istio will program all sidecar proxies in the mesh with the
+necessary configuration required to reach every workload in the mesh, as
+well as accept traffic on all the ports associated with the
+workload. The Sidecar resource provides a way to fine tune the set of
+ports, protocols that the proxy will accept when forwarding traffic to
+and from the workload. In addition, it is possible to restrict the set
+of services that the proxy can reach when forwarding outbound traffic
+from the workload.</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). A Sidecar
+resource in a namespace will apply to one or more workloads in the same
+namespace, selected using the workloadSelector. In the absence of a
+workloadSelector, it will apply to all workloads in the same
+namespace. When determining the Sidecar resource to be applied to a
+workload, preference will be given to the resource with a
+workloadSelector that selects this workload, over a Sidecar resource
+without any workloadSelector.</p>
+
+<p>NOTE: <em><em>Each namespace can have only one Sidecar resource without any
+workload selector</em></em>. The behavior of the system is undefined if more
+than one selector-less Sidecar resources exist in a given namespace. The
+behavior of the system is undefined if two or more Sidecar resources
+with a workload selector select the same workload.</p>
+
+<p>The example below declares a Sidecar resource in the prod-us1 namespace
+that configures the sidecars in the namespace to allow egress traffic to
+public services in the prod-us1, prod-apis, and the istio-system
+namespaces.</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
+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>The example below declares a Sidecar resource in the prod-us1 namespace
+that accepts inbound HTTP traffic on port 9080 and forwards
+it to the attached workload listening on a unix domain socket. In the
+egress direction, in addition to the istio-system namespace, the sidecar
+proxies only HTTP traffic bound for port 9080 for services in the
+prod-us1 namespace.</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
+kind: Sidecar
+metadata:
+  name: default
+  namespace: prod-us1
+spec:
+  ingress:
+  - port:
+      number: 9080
+      protocol: HTTP
+      name: somename
+    defaultEndpoint: unix:///var/run/someuds.sock
+  egress:
+  - hosts:
+    - &quot;istio-system/*&quot;
+  - port:
+      number: 9080
+      protocol: HTTP
+      name: egresshttp
+    hosts:
+    - &quot;prod-us1/*&quot;
+</code></pre>
+
+<h2 id="CaptureMode">CaptureMode</h2>
+<section>
+<p>CaptureMode describes how traffic to a listener is expected to be
+captured. Applicable only when the listener is bound to an IP.</p>
+
+<table class="enum-values">
+<thead>
+<tr>
+<th>Name</th>
+<th>Description</th>
+</tr>
+</thead>
+<tbody>
+<tr id="CaptureMode-DEFAULT">
+<td><code>DEFAULT</code></td>
+<td>
+<p>The default capture mode defined by the environment</p>
+
+</td>
+</tr>
+<tr id="CaptureMode-IPTABLES">
+<td><code>IPTABLES</code></td>
+<td>
+<p>Capture traffic using IPtables redirection</p>
+
+</td>
+</tr>
+<tr id="CaptureMode-NONE">
+<td><code>NONE</code></td>
+<td>
+<p>No traffic capture. When used in egress listener, the application is
+expected to explicitly communicate with the listener port/unix
+domain socket. When used in 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>
+</tr>
+</tbody>
+</table>
+</section>
+<h2 id="IstioEgressListener">IstioEgressListener</h2>
+<section>
+<p>IstioEgressListener specifies the properties of an outbound traffic
+listener on the sidecar proxy attached to a workload.</p>
+
+<table class="message-fields">
+<thead>
+<tr>
+<th>Field</th>
+<th>Type</th>
+<th>Description</th>
+</tr>
+</thead>
+<tbody>
+<tr id="IstioEgressListener-port">
+<td><code>port</code></td>
+<td><code><a href="/docs/reference/config/networking/v1alpha3/gateway.html#Port">Port</a></code></td>
+<td>
+<p>The port associated with the listener. If using unix domain socket,
+use 0 as the port number, with a valid protocol. The port if
+specified, will be used as the default destination port associated
+with the imported hosts. If the port is omitted, Istio will infer the
+listener ports based on the imported hosts. Note that when multiple
+egress listeners are specified, where one or more listeners have
+specific ports while others have no port, the hosts exposed on a
+listener port will be based on the listener with the most specific
+port.</p>
+
+</td>
+</tr>
+<tr id="IstioEgressListener-bind">
+<td><code>bind</code></td>
+<td><code>string</code></td>
+<td>
+<p>The ip or the unix domain socket to which the listener should be bound
+to. Port MUST be specified if bind is not empty. Format: x.x.x.x or
+unix:///path/to/uds or unix://@foobar (Linux abstract namespace). If
+omitted, Istio will autoconfigure the defaults based on imported
+services, the workload to which this configuration is applied to and
+the captureMode. If captureMode is NONE, bind will default to
+127.0.0.1.</p>
+
+</td>
+</tr>
+<tr id="IstioEgressListener-capture_mode">
+<td><code>captureMode</code></td>
+<td><code><a href="#CaptureMode">CaptureMode</a></code></td>
+<td>
+<p>When the bind address is an IP, the captureMode option dictates
+how traffic to the listener is expected to be captured (or not).
+captureMode must be DEFAULT or NONE for unix domain socket binds.</p>
+
+</td>
+</tr>
+<tr id="IstioEgressListener-hosts">
+<td><code>hosts</code></td>
+<td><code>string[]</code></td>
+<td>
+<p>REQUIRED: One or more services/virtualServices exposed by the listener
+in namespace/dnsName format.  Publicly scoped services and
+VirtualServices from remote namespaces corresponding to the specified
+hosts will be imported. 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. In addition, any
+publicly scoped DestinationRule associated with the imported services
+will also be imported.</p>
+
+<p>Set the namespace to * to import a particular service from any
+available namespace (e.g., &ldquo;*/foo.example.com&rdquo;). Set the dnsName field
+to * to import all services from the specified namespace (e.g.,
+&ldquo;prod/*&rdquo;). The services should be specified using FQDN format.</p>
+
+<p>NOTE: Only exported services and configuration artifacts from a
+namespace can be imported. Private services/configuration will not be
+imported. Refer to the scope setting associated with VirtualService,
+DestinationRule, ServiceEntry, etc. for details.</p>
+
+</td>
+</tr>
+</tbody>
+</table>
+</section>
+<h2 id="IstioIngressListener">IstioIngressListener</h2>
+<section>
+<p>IstioIngressListener specifies the properties of an inbound
+traffic listener on the sidecar proxy attached to a workload.</p>
+
+<table class="message-fields">
+<thead>
+<tr>
+<th>Field</th>
+<th>Type</th>
+<th>Description</th>
+</tr>
+</thead>
+<tbody>
+<tr id="IstioIngressListener-port">
+<td><code>port</code></td>
+<td><code><a href="/docs/reference/config/networking/v1alpha3/gateway.html#Port">Port</a></code></td>
+<td>
+<p>REQUIRED. The port associated with the listener. If using
+unix domain socket, use 0 as the port number, with a valid
+protocol.</p>
+
+</td>
+</tr>
+<tr id="IstioIngressListener-bind">
+<td><code>bind</code></td>
+<td><code>string</code></td>
+<td>
+<p>The ip or the unix domain socket to which the listener should be bound
+to. Format: x.x.x.x or unix:///path/to/uds or unix://@foobar (Linux
+abstract namespace). If omitted, Istio will autoconfigure the defaults
+based on imported services and the workload to which this
+configuration is applied to.</p>
+
+</td>
+</tr>
+<tr id="IstioIngressListener-capture_mode">
+<td><code>captureMode</code></td>
+<td><code><a href="#CaptureMode">CaptureMode</a></code></td>
+<td>
+<p>When the bind address is an IP, the captureMode option dictates
+how traffic to the listener is expected to be captured (or not).
+captureMode must be DEFAULT or NONE for unix domain socket binds.</p>
+
+</td>
+</tr>
+<tr id="IstioIngressListener-default_endpoint">
+<td><code>defaultEndpoint</code></td>
+<td><code>string</code></td>
+<td>
+<p>REQUIRED: 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 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>
+
+</td>
+</tr>
+</tbody>
+</table>
+</section>
+<h2 id="Sidecar">Sidecar</h2>
+<section>
+<table class="message-fields">
+<thead>
+<tr>
+<th>Field</th>
+<th>Type</th>
+<th>Description</th>
+</tr>
+</thead>
+<tbody>
+<tr id="Sidecar-workload_selector">
+<td><code>workloadSelector</code></td>
+<td><code><a href="#WorkloadSelector">WorkloadSelector</a></code></td>
+<td>
+<p>Criteria used to select the specific set of pods/VMs on which this
+sidecar configuration should be applied. If omitted, the sidecar
+configuration will be applied to all workloads in the same config
+namespace.</p>
+
+</td>
+</tr>
+<tr id="Sidecar-ingress">
+<td><code>ingress</code></td>
+<td><code><a href="#IstioIngressListener">IstioIngressListener[]</a></code></td>
+<td>
+<p>Ingress specifies the configuration of the sidecar for processing
+inbound traffic to the attached workload. If omitted, Istio will
+autoconfigure the sidecar based on the information about the workload
+obtained from the orchestration platform (e.g., exposed ports, services,
+etc.).</p>
+
+</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 to other services in the
+mesh. If omitted, Istio will autoconfigure the sidecar to be able to
+reach every service in the mesh that is visible to this namespace.</p>
+
+</td>
+</tr>
+</tbody>
+</table>
+</section>
+<h2 id="WorkloadSelector">WorkloadSelector</h2>
+<section>
+<p>WorkloadSelector specifies the criteria used to determine if the Gateway
+or Sidecar resource can be applied to a proxy. The matching criteria
+includes the metadata associated with a proxy, workload 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 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>
+</tr>
+</thead>
+<tbody>
+<tr id="WorkloadSelector-labels">
+<td><code>labels</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 sidecar configuration should be applied. The scope of
+label search is restricted to the configuration namespace in which the
+the resource is present.</p>
+
+</td>
+</tr>
+</tbody>
+</table>
+</section>
--- a/content/docs/reference/config/networking/v1alpha3/virtual-service/index.html
+++ b/content/docs/reference/config/networking/v1alpha3/virtual-service/index.html
--- a/content/docs/reference/config/policy-and-telemetry/istio.policy.v1beta1/index.html
+++ b/content/docs/reference/config/policy-and-telemetry/istio.policy.v1beta1/index.html
@ -1,10 +1,10 @@
 ---
-WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE https://github.com/istio/api REPO
-source_repo: https://github.com/istio/api
+WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE istio REPO
+source_repo: istio
 title: Rules
 description: Describes the rules used to configure Mixer's policy and telemetry features.
 location: https://istio.io/docs/reference/config/policy-and-telemetry/istio.policy.v1beta1.html
-layout: protoc-gen-docs
+layout: partner-component
 generator: protoc-gen-docs
 number_of_entries: 25
 ---
--- a/content/docs/setup/kubernetes/mesh-expansion/index.md
+++ b/content/docs/setup/kubernetes/mesh-expansion/index.md
@ -189,7 +189,7 @@ $ curl productpage.bookinfo.svc.cluster.local:9080
 ## Running services on a mesh expansion machine

 You add VM services to the mesh by configuring a
-[`ServiceEntry`](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry). A service entry lets you manually add
+[`ServiceEntry`](/docs/reference/config/networking/v1alpha3/service-entry/). A service entry lets you manually add
 additional services to Istio's model of the mesh so that other services can find and direct traffic to them. Each
 `ServiceEntry` configuration contains the IP addresses, ports, and labels (where appropriate) of all VMs exposing a
 particular service, as in the following example.
--- a/content/docs/tasks/security/mtls-migration/index.md
+++ b/content/docs/tasks/security/mtls-migration/index.md
@ -133,7 +133,7 @@ $ for from in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sle
 {{< /text >}}

 You can also specify a subset of the clients' request to use `ISTIO_MUTUAL` mutual TLS in
-[`DestinationRule`](/docs/reference/config/istio.networking.v1alpha3/#DestinationRule).
+[`DestinationRule`](/docs/reference/config/networking/v1alpha3/destination-rule/).
 After verifying it works by checking [Grafana to monitor](/docs/tasks/telemetry/using-istio-dashboard/),
 then increase the rollout scope and finally apply to all Istio client services.

--- a/content/docs/tasks/traffic-management/circuit-breaking/index.md
+++ b/content/docs/tasks/traffic-management/circuit-breaking/index.md
@ -37,7 +37,7 @@ configuration by intentionally "tripping" the circuit breaker.

 ## Configuring the circuit breaker

-1.  Create a [destination rule](/docs/reference/config/istio.networking.v1alpha3/#DestinationRule) to apply circuit breaking settings
+1.  Create a [destination rule](/docs/reference/config/networking/v1alpha3/destination-rule/) to apply circuit breaking settings
 when calling the `httpbin` service:

    {{< warning >}}
--- a/content/docs/tasks/traffic-management/egress/index.md
+++ b/content/docs/tasks/traffic-management/egress/index.md
@ -13,7 +13,7 @@ which only handles intra-cluster destinations.
 This task describes how to configure Istio to expose external services to Istio-enabled clients
 in three different ways:

-1. Configure a [service entry](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry).
+1. Configure a [service entry](/docs/reference/config/networking/v1alpha3/service-entry/).
 1. Bypass the Envoy proxy for a specific range of IPs.
 1. Configure the Envoy proxy to pass requests through to external services on ports that are not configured inside the mesh.

--- a/content/docs/tasks/traffic-management/ingress/index.md
+++ b/content/docs/tasks/traffic-management/ingress/index.md
@ -10,7 +10,7 @@ aliases:
 In a Kubernetes environment, the [Kubernetes Ingress Resource](https://kubernetes.io/docs/concepts/services-networking/ingress/)
 is used to specify services that should be exposed outside the cluster.
 In an Istio service mesh, a better approach (which also works in both Kubernetes and other environments) is to use a
-different configuration model, namely [Istio Gateway](/docs/reference/config/istio.networking.v1alpha3/#Gateway).
+different configuration model, namely [Istio Gateway](/docs/reference/config/networking/v1alpha3/gateway/).
 A `Gateway` allows Istio features such as monitoring and route rules to be applied to traffic entering the cluster.

 This task describes how to configure Istio to expose a service outside of the service mesh using an Istio `Gateway`.
@ -128,7 +128,7 @@ Setting the ingress IP depends on the cluster provider:

 ## Configuring ingress using an Istio Gateway

-An ingress [Gateway](/docs/reference/config/istio.networking.v1alpha3/#Gateway) describes a load balancer operating at the edge of the mesh that receives incoming HTTP/TCP connections.
+An ingress [Gateway](/docs/reference/config/networking/v1alpha3/gateway/) describes a load balancer operating at the edge of the mesh that receives incoming HTTP/TCP connections.
 It configures exposed ports, protocols, etc.
 but, unlike [Kubernetes Ingress Resources](https://kubernetes.io/docs/concepts/services-networking/ingress/),
 does not include any traffic routing configuration. Traffic routing for ingress traffic is instead configured
@ -184,11 +184,11 @@ Let's see how you can configure a `Gateway` on port 80 for HTTP traffic.
    EOF
    {{< /text >}}

-    You have now created a [virtual service](/docs/reference/config/istio.networking.v1alpha3/#VirtualService)
+    You have now created a [virtual service](/docs/reference/config/networking/v1alpha3/virtual-service/)
    configuration for the `httpbin` service containing two route rules that allow traffic for paths `/status` and
    `/delay`.

-    The [gateways](/docs/reference/config/istio.networking.v1alpha3/#VirtualService-gateways) list
+    The [gateways](/docs/reference/config/networking/v1alpha3/virtual-service/#VirtualService-gateways) list
    specifies that only requests through your `httpbin-gateway` are allowed.
    All other external requests will be rejected with a 404 response.

--- a/content/docs/tasks/traffic-management/request-timeouts/index.md
+++ b/content/docs/tasks/traffic-management/request-timeouts/index.md
@ -24,7 +24,7 @@ This task shows you how to setup request timeouts in Envoy using Istio.

 ## Request timeouts

-A timeout for http requests can be specified using the *timeout* field of the [route rule](/docs/reference/config/istio.networking.v1alpha3/#HTTPRoute).
+A timeout for http requests can be specified using the *timeout* field of the [route rule](/docs/reference/config/networking/v1alpha3/virtual-service/#HTTPRoute).
 By default, the timeout is 15 seconds, but in this task you override the `reviews` service
 timeout to 1 second.
 To see its effect, however, you also introduce an artificial 2 second delay in calls
--- a/content_zh/about/notes/1.0/index.md
+++ b/content_zh/about/notes/1.0/index.md
@ -12,7 +12,7 @@ icon: notes

 ## 网络

- **使用 Virtual Service 进行 SNI 路由**。[`VirtualService`](/docs/reference/config/istio.networking.v1alpha3/#VirtualService) 中新引入的 TLS 部分可用于根据 SNI 值路由 TLS 流量。名为 TLS/HTTPS 的服务端口可与虚拟服务 TLS 路由一起使用。没有附带虚拟服务的 TLS/HTTPS 端口将被视为不透明 TCP。
+- **使用 Virtual Service 进行 SNI 路由**。[`VirtualService`](/zh/docs/reference/config/istio.networking.v1alpha3/#VirtualService) 中新引入的 TLS 部分可用于根据 SNI 值路由 TLS 流量。名为 TLS/HTTPS 的服务端口可与虚拟服务 TLS 路由一起使用。没有附带虚拟服务的 TLS/HTTPS 端口将被视为不透明 TCP。

 - **流式 gRPC 恢复**。Istio 0.8 导致长时间运行的流 gRPC 连接的周期性终止。这已在 1.0 中修复。

@ -70,4 +70,4 @@ icon: notes

 - 在[多集群部署](/zh/docs/setup/kubernetes/multicluster-install)中，mixer-telemetry 和 mixer-policy 组件不会连接到任何远程集群的 Kubernetes API 端点。这将导致遥测保真度受损，因为与远程集群上的工作负载相关联的一些元数据不完整。

- 当前有 Kubernetes 清单文件可用于独立启用 Citadel 或执行 Citadel 运行状况检查。这些模型还没有通过 Helm 实现。有关详细信息，请参见 [Issue 6922](https://github.com/istio/istio/issues/6922)。
+- 当前有 Kubernetes 清单文件可用于独立启用 Citadel 或执行 Citadel 运行状况检查。这些模型还没有通过 Helm 实现。有关详细信息，请参见 [Issue 6922](https://github.com/istio/istio/issues/6922)。
--- a/content_zh/blog/2018/egress-mongo/index.md
+++ b/content_zh/blog/2018/egress-mongo/index.md
@ -107,7 +107,7 @@ keywords: [traffic-management,egress,tcp,mongo]
 1. 将所有到 `reviews` service 的流量路由到它的 `v3` 版本，以确保 `reviews` service 总是调用 `ratings` service。此外，将所有到 `ratings` service
   的流量路由到使用外部数据库的 `ratings v2版本`。

-   通过添加两个 [virtual service](/docs/reference/config/istio.networking.v1alpha3/#VirtualService) 来为以上两个 service 指定路由。这些 virtual service
+   通过添加两个 [virtual service](/zh/docs/reference/config/istio.networking.v1alpha3/#VirtualService) 来为以上两个 service 指定路由。这些 virtual service
   在 Istio 发布包中有指定。
   ***重要：*** 请确保在运行以下命令之前[应用了默认的 destination rules](/docs/examples/bookinfo/#apply-default-destination-rules)。

@ -1019,4 +1019,4 @@ $ kubectl delete destinationrule egressgateway-for-mongo

 在这篇博文中，我演示了 MongoDB egress 流量控制的各种选项。您可以在 TCP 或 TLS 层面上控制 MongoDB egress 流量。根据您的组织的安全需求，在 TCP 和 TLS 场景下您都可以将流量从 sidecar 代理定向到外部 MongoDB 主机，或者通过一个 egress gateway 进行转发。在后面一种场景中，您还可以决定是否禁用 sidecar 代理到 egress gateway 的双向 TLS 认证。如果您想要通过指定类似 `*.com` 的通配符域名来从 TLS 层面控制 MongoDB 的 egress 流量，并且通过 egress gateway 定向流量时，您必须部署一个使用 SNI 代理的自定义 egress gateway。

-请注意，本博客文章中描述的 MongoDB 配置和注意事项与 TCP/TLS 之上的其他非 HTTP 协议相同。
+请注意，本博客文章中描述的 MongoDB 配置和注意事项与 TCP/TLS 之上的其他非 HTTP 协议相同。
--- a/content_zh/blog/2018/egress-tcp/index.md
+++ b/content_zh/blog/2018/egress-tcp/index.md
@ -163,7 +163,7 @@ keywords: [traffic-management,egress,tcp]

 1. 将发往 _reviews_ 服务的所有流量路由到 _v3_ 版本，这样做是为了确保 _reviews_ 服务始终调用 _ratings_ 服务，此外，将发往 _ratings_ 服务的所有流量路由到使用外部数据库的 _ratings v2-mysql_。

-    通过添加两个[虚拟服务(virtual service)](/docs/reference/config/istio.networking.v1alpha3/#VirtualService)，可以为上述两种服务指定路由。这些虚拟服务在 Istio 发行档案的 `samples/bookinfo/networking/virtual-service-ratings-mysql.yaml` 中指定。
+    通过添加两个[虚拟服务(virtual service)](/zh/docs/reference/config/istio.networking.v1alpha3/#VirtualService)，可以为上述两种服务指定路由。这些虚拟服务在 Istio 发行档案的 `samples/bookinfo/networking/virtual-service-ratings-mysql.yaml` 中指定。
    ***注意：***确保你在完成了[添加默认目标路由](/docs/examples/bookinfo/#apply-default-destination-rules)才执行下面的命令。

    {{< text bash >}}
--- a/content_zh/blog/2018/v1alpha3-routing/index.md
+++ b/content_zh/blog/2018/v1alpha3-routing/index.md
@ -51,7 +51,7 @@ keywords: [traffic-management]

 ### `Gateway`

-[`Gateway`](/docs/reference/config/istio.networking.v1alpha3/#Gateway) 用于为 HTTP / TCP 流量配置负载均衡器，并不管该负载均衡器将在哪里运行。 网格中可以存在任意数量的 Gateway，并且多个不同的 Gateway 实现可以共存。 实际上，通过在配置中指定一组工作负载（Pod）标签，可以将 Gateway 配置绑定到特定的工作负载，从而允许用户通过编写简单的 Gateway Controller 来重用现成的网络设备。
+[`Gateway`](/zh/docs/reference/config/istio.networking.v1alpha3/#Gateway) 用于为 HTTP / TCP 流量配置负载均衡器，并不管该负载均衡器将在哪里运行。 网格中可以存在任意数量的 Gateway，并且多个不同的 Gateway 实现可以共存。 实际上，通过在配置中指定一组工作负载（Pod）标签，可以将 Gateway 配置绑定到特定的工作负载，从而允许用户通过编写简单的 Gateway Controller 来重用现成的网络设备。

 对于入口流量管理，您可能会问： _为什么不直接使用 Kubernetes Ingress API_ ？ 原因是 Ingress API 无法表达 Istio 的路由需求。 Ingress 试图在不同的 HTTP 代理之间取一个公共的交集，因此只能支持最基本的 HTTP 路由，最终导致需要将代理的其他高级功能放入到注解（annotation）中，而注解的方式在多个代理之间是不兼容的，无法移植。

--- a/content_zh/docs/tasks/traffic-management/ingress/index.md
+++ b/content_zh/docs/tasks/traffic-management/ingress/index.md
@ -166,7 +166,7 @@ Ingress [`Gateway`](/zh/docs/reference/config/istio.networking.v1alpha3/#gateway

    在这里，我们为服务创建了一个[虚拟服务](/zh/docs/reference/config/istio.networking.v1alpha3/#virtualservice)配置 `httpbin` ，其中包含两条路由规则，允许路径 `/status` 和 路径的流量 `/delay`。

-    该[网关](/docs/reference/config/istio.networking.v1alpha3/#VirtualService-gateways)列表指定，只有通过我们的要求 `httpbin-gateway` 是允许的。所有其他外部请求将被拒绝，并返回 404 响应。
+    该[网关](/zh/docs/reference/config/istio.networking.v1alpha3/#virtualservice)列表指定，只有通过我们的要求 `httpbin-gateway` 是允许的。所有其他外部请求将被拒绝，并返回 404 响应。

    请注意，在此配置中，来自网格中其他服务的内部请求不受这些规则约束，而是简单地默认为循环路由。要将这些（或其他规则）应用于内部调用，我们可以将特殊值 `mesh` 添加到 `gateways` 的列表中。