From 72f6f1353fb6672558724f3ce2dabb3afe7fc3d4 Mon Sep 17 00:00:00 2001 From: Martin Taillefer Date: Fri, 13 Jul 2018 15:00:52 -0700 Subject: [PATCH] Update reference docs. (#1812) --- content/blog/2018/v1alpha3-routing/index.md | 4 +- .../docs/reference/commands/galley/index.html | 36 +- .../reference/commands/istio_ca/index.html | 2 +- .../reference/commands/istioctl/index.html | 104 +- .../reference/commands/pilot-agent/index.html | 2 +- .../commands/pilot-discovery/index.html | 14 +- .../istio.rbac.v1alpha1/index.html | 101 +- .../istio.networking.v1alpha3/index.html | 23 +- .../config/istio.routing.v1alpha1/index.html | 1837 ----------------- .../adapters/apigee/index.html | 6 +- .../templates/kubernetes/index.html | 62 +- .../blog/2018/v1alpha3-routing/index.md | 2 +- scripts/grab_reference_docs.sh | 31 +- 13 files changed, 118 insertions(+), 2106 deletions(-) rename content/docs/reference/config/{ => authorization}/istio.rbac.v1alpha1/index.html (75%) delete mode 100644 content/docs/reference/config/istio.routing.v1alpha1/index.html diff --git a/content/blog/2018/v1alpha3-routing/index.md b/content/blog/2018/v1alpha3-routing/index.md index f5e6ef3c0f..4d9bdd3c73 100644 --- a/content/blog/2018/v1alpha3-routing/index.md +++ b/content/blog/2018/v1alpha3-routing/index.md @@ -21,9 +21,7 @@ traffic has proven to be woefully insufficient for our needs. To address these, and other concerns, a new traffic management API, a.k.a. `v1alpha3`, is being introduced, which will completely replace the previous API going forward. Although the `v1alpha3` model is fundamentally the same, it is not -backward compatible and will require manual conversion from the old API. A -[conversion tool](/docs/reference/commands/istioctl/#istioctl-experimental-convert-networking-config) -is included in the next few releases of Istio to help with the transition. +backward compatible and will require manual conversion from the old API. To justify this disruption, the `v1alpha3` API has gone through a long and painstaking community review process that has hopefully resulted in a greatly improved API that will stand the test of time. In this article, diff --git a/content/docs/reference/commands/galley/index.html b/content/docs/reference/commands/galley/index.html index ca16d967fc..23ad1114e5 100644 --- a/content/docs/reference/commands/galley/index.html +++ b/content/docs/reference/commands/galley/index.html @@ -21,11 +21,11 @@ number_of_entries: 6 --log_caller <string> -Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] (default ``) +Comma-separated list of scopes for which to include caller information, scopes can be any of [attributes, default, grpcAdapter, mcp, runtime, snapshot] (default ``) --log_output_level <string> -Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:info`) +Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [attributes, default, grpcAdapter, mcp, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:info`) --log_rotate <string> @@ -45,7 +45,7 @@ number_of_entries: 6 --log_stacktrace_level <string> -Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:none`) +Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [attributes, default, grpcAdapter, mcp, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:none`) --log_target <stringArray> @@ -81,11 +81,11 @@ number_of_entries: 6 --log_caller <string> -Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] (default ``) +Comma-separated list of scopes for which to include caller information, scopes can be any of [attributes, default, grpcAdapter, mcp, runtime, snapshot] (default ``) --log_output_level <string> -Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:info`) +Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [attributes, default, grpcAdapter, mcp, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:info`) --log_rotate <string> @@ -105,7 +105,7 @@ number_of_entries: 6 --log_stacktrace_level <string> -Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:none`) +Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [attributes, default, grpcAdapter, mcp, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:none`) --log_target <stringArray> @@ -165,11 +165,11 @@ number_of_entries: 6 --log_caller <string> -Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] (default ``) +Comma-separated list of scopes for which to include caller information, scopes can be any of [attributes, default, grpcAdapter, mcp, runtime, snapshot] (default ``) --log_output_level <string> -Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:info`) +Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [attributes, default, grpcAdapter, mcp, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:info`) --log_rotate <string> @@ -189,7 +189,7 @@ number_of_entries: 6 --log_stacktrace_level <string> -Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:none`) +Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [attributes, default, grpcAdapter, mcp, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:none`) --log_target <stringArray> @@ -237,7 +237,7 @@ number_of_entries: 6 --healthCheckInterval <duration> -Configure how frequently the health check file specified by --healthCheckFile should be updated (default `0s`) +Configure how frequently the health check file specified by --healhCheckFile should be updated (default `0s`) --kubeconfig <string> @@ -249,11 +249,11 @@ number_of_entries: 6 --log_caller <string> -Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] (default ``) +Comma-separated list of scopes for which to include caller information, scopes can be any of [attributes, default, grpcAdapter, mcp, runtime, snapshot] (default ``) --log_output_level <string> -Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:info`) +Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [attributes, default, grpcAdapter, mcp, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:info`) --log_rotate <string> @@ -273,7 +273,7 @@ number_of_entries: 6 --log_stacktrace_level <string> -Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:none`) +Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [attributes, default, grpcAdapter, mcp, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:none`) --log_target <stringArray> @@ -284,6 +284,10 @@ number_of_entries: 6 Name of the mixer webhook entry in the webhook config. (default `mixer.validation.istio.io`) +--monitoringPort <uint> +Port to use for the exposing self-monitoring information (default `9093`) + + --pilot-webhook-name <string> Name of the pilot webhook entry in the webhook config. (default `pilot.validation.istio.io`) @@ -333,12 +337,12 @@ number_of_entries: 6 --log_caller <string> -Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] (default ``) +Comma-separated list of scopes for which to include caller information, scopes can be any of [attributes, default, grpcAdapter, mcp, runtime, snapshot] (default ``) --log_output_level <string> -Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:info`) +Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [attributes, default, grpcAdapter, mcp, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:info`) --log_rotate <string> @@ -363,7 +367,7 @@ number_of_entries: 6 --log_stacktrace_level <string> -Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, attributes, default, grpcAdapter, mcp, rbac, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:none`) +Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [attributes, default, grpcAdapter, mcp, runtime, snapshot] and level can be one of [debug, info, warn, error, none] (default `default:none`) --log_target <stringArray> diff --git a/content/docs/reference/commands/istio_ca/index.html b/content/docs/reference/commands/istio_ca/index.html index 2200097431..918e304161 100644 --- a/content/docs/reference/commands/istio_ca/index.html +++ b/content/docs/reference/commands/istio_ca/index.html @@ -39,7 +39,7 @@ number_of_entries: 4 --grpc-hostname <string> -DEPRECATED, use --grpc-host-identities. (default `istio-ca`) +DEPRECATED, use --grpc-host-identites. (default `istio-ca`) --grpc-port <int> diff --git a/content/docs/reference/commands/istioctl/index.html b/content/docs/reference/commands/istioctl/index.html index cf045df4eb..6c503ae595 100644 --- a/content/docs/reference/commands/istioctl/index.html +++ b/content/docs/reference/commands/istioctl/index.html @@ -2,7 +2,7 @@ title: istioctl description: Istio control interface generator: pkg-collateral-docs -number_of_entries: 26 +number_of_entries: 25 ---

Istio configuration command line utility.

@@ -10,8 +10,6 @@ Istio configuration command line utility.

system.

Available routing and traffic management configuration types:

[virtualservice gateway destinationrule serviceentry httpapispec httpapispecbinding quotaspec quotaspecbinding servicerole servicerolebinding policy]

-

Legacy routing and traffic management configuration types:

-

[routerule egressrule destinationpolicy]

See https://istio.io/docs/reference/ for an overview of Istio routing.

@@ -720,102 +718,6 @@ istioctl delete virtualservice bookinfo
-

istioctl experimental convert-networking-config

-

Converts sets of v1alpha1 configs to v1alpha3 equivalents on a best effort basis. The output should be considered a starting point for your v1alpha3 configs and probably require some minor modification. Warnings will (hopefully) be generated where configs cannot be converted perfectly, or in certain edge cases. The input must be the set of configs that would be in place in an environment at a given time. This allows the command to attempt to create and merge output configs intelligently.Output configs are given the namespace and domain of the first input config so it is recommended that input configs be part of the same namespace and domain.

-
istioctl experimental convert-networking-config [flags]
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FlagsShorthandDescription
--context <string>The name of the kubeconfig context to use (default ``)
--filenames <stringSlice>-fInput filenames (default `[]`)
--istioNamespace <string>-iIstio system namespace (default `istio-system`)
--kubeconfig <string>-cKubernetes configuration file (default ``)
--log_as_jsonWhether to format output as JSON or in plain console-friendly format
--log_caller <string>Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, default, rbac] (default ``)
--log_output_level <string>Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, default, rbac] and level can be one of [debug, info, warn, error, none] (default `default:info`)
--log_rotate <string>The path for the optional rotating log file (default ``)
--log_rotate_max_age <int>The maximum age in days of a log file beyond which the file is rotated (0 indicates no limit) (default `30`)
--log_rotate_max_backups <int>The maximum number of log file backups to keep before older files are deleted (0 indicates no limit) (default `1000`)
--log_rotate_max_size <int>The maximum size in megabytes of a log file beyond which the file is rotated (default `104857600`)
--log_stacktrace_level <string>Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, default, rbac] and level can be one of [debug, info, warn, error, none] (default `default:none`)
--log_target <stringArray>The set of paths where to output the log. This can be any path as well as the special values stdout and stderr (default `[stdout]`)
--namespace <string>-nConfig namespace (default ``)
--output <string>-oOutput filename (default `-`)
--platform <string>-pIstio host platform (default `kube`)
-

Examples

-
istioctl experimental convert-networking-config -f v1alpha1/default-route.yaml -f v1alpha1/header-delay.yaml
-

istioctl experimental metrics

Prints the metrics for the specified service(s) when running in Kubernetes.

@@ -1350,7 +1252,7 @@ run kube-inject over a single file that contains multiple Service, ConfigMap, Deployment, etc. definitions for a complex application. Its best to do this when the resource is initially created.

k8s.io/docs/concepts/workloads/pods/pod-overview/#pod-templates is -updated for Job, DaemonSet, ReplicaSet, and Deployment YAML resource +updated for Job, DaemonSet, ReplicaSet, Pod and Deployment YAML resource documents. Support for additional pod-based resource types can be added as necessary.

The Istio project is continually evolving so the Istio sidecar @@ -1777,7 +1679,7 @@ istioctl kube-inject -f deployment.yaml -o deployment-injected.yaml --injectConf --subset <string> -Filter clusters by substring of Subset field (default ``) +Filter clusters by subtring of Subset field (default ``) diff --git a/content/docs/reference/commands/pilot-agent/index.html b/content/docs/reference/commands/pilot-agent/index.html index 0f4e2df1ee..8c2968c44c 100644 --- a/content/docs/reference/commands/pilot-agent/index.html +++ b/content/docs/reference/commands/pilot-agent/index.html @@ -173,7 +173,7 @@ number_of_entries: 5 --serviceregistry <string> -Select the platform for service registry, options are {Kubernetes, Consul, Eureka, CloudFoundry, Mock, Config} (default `Kubernetes`) +Select the platform for service registry, options are {Kubernetes, Consul, CloudFoundry, Mock, Config} (default `Kubernetes`) --statsdUdpAddress <string> diff --git a/content/docs/reference/commands/pilot-discovery/index.html b/content/docs/reference/commands/pilot-discovery/index.html index af4ec97ee0..c6a365c8ef 100644 --- a/content/docs/reference/commands/pilot-discovery/index.html +++ b/content/docs/reference/commands/pilot-discovery/index.html @@ -124,16 +124,6 @@ number_of_entries: 5 DNS domain suffix (default `cluster.local`) ---eurekaserverInterval <duration> - -Interval (in seconds) for polling the Eureka service registry (default `2s`) - - ---eurekaserverURL <string> - -URL for the Eureka server (default ``) - - --grpcAddr <string> Discovery service grpc address (default `:15010`) @@ -211,7 +201,7 @@ number_of_entries: 5 --plugins <stringSlice> -comma separated list of networking plugins to enable (default `[authn,authz,envoyfilter,health,mixer]`) +comma separated list of networking plugins to enable (default `[authn,authz,health,mixer,envoyfilter]`) --profile @@ -221,7 +211,7 @@ number_of_entries: 5 --registries <stringSlice> -Comma separated list of platform service registries to read from (choose one or more from {Kubernetes, Consul, Eureka, CloudFoundry, Mock, Config}) (default `[Kubernetes]`) +Comma separated list of platform service registries to read from (choose one or more from {Kubernetes, Consul, CloudFoundry, Mock, Config}) (default `[Kubernetes]`) --resync <duration> diff --git a/content/docs/reference/config/istio.rbac.v1alpha1/index.html b/content/docs/reference/config/authorization/istio.rbac.v1alpha1/index.html similarity index 75% rename from content/docs/reference/config/istio.rbac.v1alpha1/index.html rename to content/docs/reference/config/authorization/istio.rbac.v1alpha1/index.html index 554c74829f..3cad4230db 100644 --- a/content/docs/reference/config/istio.rbac.v1alpha1/index.html +++ b/content/docs/reference/config/authorization/istio.rbac.v1alpha1/index.html @@ -1,7 +1,7 @@ --- title: RBAC description: Configuration for Role Based Access Control -location: https://istio.io/docs/reference/config/istio.rbac.v1alpha1.html +location: https://istio.io/docs/reference/config/authorization/istio.rbac.v1alpha1.html layout: protoc-gen-docs generator: protoc-gen-docs number_of_entries: 9 @@ -10,44 +10,23 @@ number_of_entries: 9 objects.

A ServiceRole specification includes a list of rules (permissions). Each rule has -the following standard fields: -* services: a list of services. -* methods: HTTP methods. In the case of gRPC, this field is ignored because the value is always “POST”. -* paths: HTTP paths or gRPC methods. Note that gRPC methods should be - presented in the form of “packageName.serviceName/methodName”.

+the following standard fields:

-

In addition to the standard fields, operators can use custom fields in the “constraints” -section. The name of a custom field must match one of the “properties” in the “action” part -of the “authorization” template (https://github.com/istio/istio/blob/master/mixer/template/authorization/template.proto).

+ -

For example, suppose we define an instance of the “authorization” template, named “requestcontext”.

- -
apiVersion: "config.istio.io/v1alpha1"
-kind: authorization
-metadata:
-  name: requestcontext
-  namespace: istio-system
-spec:
-  subject:
-    user: source.user | ""
-    groups: ""
-    properties:
-      service: source.service | ""
-      namespace: source.namespace | ""
-  action:
-    namespace: destination.namespace | ""
-    service: destination.service | ""
-    method: request.method | ""
-    path: request.path | ""
-    properties:
-      version: request.headers["version"] | ""
-
+

In addition to the standard fields, operators can also use custom keys in the constraints field, +the supported keys are listed in the “constraints and properties” page.

Below is an example of ServiceRole object “product-viewer”, which has “read” (“GET” and “HEAD”) access to “products.svc.cluster.local” service at versions “v1” and “v2”. “path” is not specified, so it applies to any path in the service.

-
apiVersion: "config.istio.io/v1alpha1"
+
apiVersion: "config.istio.io/v1alpha2"
 kind: ServiceRole
 metadata:
   name: products-viewer
@@ -57,24 +36,29 @@ spec:
   - services: ["products.svc.cluster.local"]
     methods: ["GET", "HEAD"]
     constraints:
-    - key: "version"
+    - key: "destination.labels[version]"
       value: ["v1", "v2"]
 

 
-
A ServiceRoleBinding specification includes two parts:
-* “roleRef” refers to a ServiceRole object in the same namespace.
-* A list of “subjects” that are assigned the roles.

+
A ServiceRoleBinding specification includes two parts:

 
-
A subject is represented with a set of “properties”. The name of a property must match one of
-the fields (“user” or “groups” or one of the “properties”) in the “subject” part of the “authorization”
-template (https://github.com/istio/istio/blob/master/mixer/template/authorization/template.proto).

+
    
+
  • The roleRef field that refers to a ServiceRole object in the same namespace.
    • 
+
  • A list of subjects that are assigned the roles.
    • 
+

+
+
In addition to a simple user field, operators can also use custom keys in the properties field,
+the supported keys are listed in the “constraints and properties” page.

 
 
Below is an example of ServiceRoleBinding object “test-binding-products”, which binds two subjects
-to ServiceRole “product-viewer”:
-* User “alice@yahoo.com”
-* “reviews” service in “abc” namespace.

+to ServiceRole “product-viewer”:

 
-
apiVersion: "config.istio.io/v1alpha1"
+
    
+
  • User “alice@yahoo.com”
    • 
+
  • Services in “abc” namespace.
    • 
+

+
+
apiVersion: "config.istio.io/v1alpha2"
 kind: ServiceRoleBinding
 metadata:
   name: test-binding-products
@@ -83,8 +67,7 @@ spec:
   subjects:
   - user: alice@yahoo.com
   - properties:
-      service: "reviews"
-      namespace: "abc"
+      source.namespace: "abc"
   roleRef:
     kind: ServiceRole
     name: "products-viewer"
@@ -146,7 +129,7 @@ If set to [“*”] or not specified, it applies to any method.

 AccessRule.Constraint[]
 
 
Optional. Extra constraints in the ServiceRole specification.
-The above ServiceRole examples shows an example of constraint “version”.

+The above ServiceRole example shows an example of constraint “version”.

 
 
 
@@ -155,9 +138,7 @@ The above ServiceRole examples shows an example of constraint “version&rdq
 
 
AccessRule.Constraint

 

-
Definition of a custom constraint. The key of a custom constraint must match
-one of the “properties” in the “action” part of the “authorization” template
-(https://github.com/istio/istio/blob/master/mixer/template/authorization/template.proto).

+
Definition of a custom constraint. The supported keys are listed in the “constraint and properties” page.

 
 
@@ -202,10 +183,10 @@ existing one, the user should either delete the existing one or change the exist
 
Below is an example of RbacConfig object “istio-rbac-config” which enables Istio RBAC for all
 services in the default namespace.

 
-
apiVersion: "config.istio.io/v1alpha1"
+
apiVersion: "config.istio.io/v1alpha2"
 kind: RbacConfig
 metadata:
-  name: istio-rbac-config
+  name: default
   namespace: istio-system
 spec:
   mode: ON_WITH_INCLUSION
@@ -425,10 +406,8 @@ object.

 
 
Subject

 

-
Subject defines an identity or a group of identities. The identity is either a user or
-a group or identified by a set of “properties”. The name of the “properties” must match
-the “properties” in the “subject” part of the “authorization” template
-(https://github.com/istio/istio/blob/master/mixer/template/authorization/template.proto).

+
Subject defines an identity. The identity is either a user or identified by a set of properties.
+The supported keys in properties are listed in “constraint and properties” page.

 
 

 

@@ -445,14 +424,6 @@ the “properties” in the “subject” part of the “aut
 
-
-
-
-
-
@@ -460,9 +431,7 @@ the “properties” in the “subject” part of the “aut
 
diff --git a/content/docs/reference/config/istio.networking.v1alpha3/index.html b/content/docs/reference/config/istio.networking.v1alpha3/index.html
index c320f497f9..67a4907161 100644
--- a/content/docs/reference/config/istio.networking.v1alpha3/index.html
+++ b/content/docs/reference/config/istio.networking.v1alpha3/index.html
@@ -1172,9 +1172,9 @@ spec:
 
 
 
The following VirtualService forwards traffic arriving at (external)
-port 27017 from “172.17.16.0/24” subnet to internal Mongo server on port
-5555. This rule is not applicable internally in the mesh as the gateway
-list omits the reserved name mesh.

+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 mesh.

 
 
apiVersion: networking.istio.io/v1alpha3
 kind: VirtualService
@@ -1188,7 +1188,6 @@ spec:
   tcp:
   - match:
     - port: 27017
-      sourceSubnet: "172.17.16.0/24"
     route:
     - destination:
         host: mongo.prod.svc.cluster.local
@@ -1860,12 +1859,10 @@ is incomplete.

 

-
+
@@ -3169,12 +3166,10 @@ as well as example.com.

 
 
-
+
diff --git a/content/docs/reference/config/istio.routing.v1alpha1/index.html b/content/docs/reference/config/istio.routing.v1alpha1/index.html
deleted file mode 100644
index 43af62e4e9..0000000000
--- a/content/docs/reference/config/istio.routing.v1alpha1/index.html
+++ /dev/null
@@ -1,1837 +0,0 @@
----
-title: Route Rules v1alpha1 (deprecated)
-description: Configuration affecting traffic routing
-location: https://istio.io/docs/reference/config/istio.routing.v1alpha1.html
-layout: protoc-gen-docs
-generator: protoc-gen-docs
-aliases:
-  - /docs/reference/config/traffic-rules/routing-rules.html
-number_of_entries: 28
----
-
Note: This version of the traffic management API has been deprecated and will
-not be supported after Istio 0.8.

-
-
Configuration affecting traffic routing. Here are a few terms useful to define
-in the context of routing rules.

-
-
Service is a unit of an application with a unique name that other services
-use to refer to the functionality being called. Service instances are
-pods/VMs/containers that implement the service.

-
-
Service versions - In a continuous deployment scenario, for a given service,
-there can be multiple sets of instances running potentially different
-variants of the application binary. These variants are not necessarily
-different API versions. They could be iterative changes to the same service,
-deployed in different environments (prod, staging, dev, etc.). Common
-scenarios where this occurs include A/B testing, canary rollouts, etc. The
-choice of a particular version can be decided based on various criterion
-(headers, url, etc.) and/or by weights assigned to each version.  Each
-service has a default version consisting of all its instances.

-
-
Source - downstream client (browser or another service) calling the
-Envoy proxy/sidecar (typically to reach another service).

-
-
Destination - The remote upstream service to which the Envoy proxy/sidecar is
-talking to, on behalf of the source service. There can be one or more
-service versions for a given service (see the discussion on versions above).
-Envoy would choose the version based on various routing rules.

-
-
Access model - Applications address only the destination service
-without knowledge of individual service versions. The actual choice of
-the version is determined by Envoy, enabling the application code to
-decouple itself from the evolution of dependent services.

-
-
CircuitBreaker

-

-
Circuit breaker configuration for Envoy. The circuit breaker
-implementation is fine-grained in that it tracks the success/failure
-rates of individual hosts in the load balancing pool. Hosts that
-continually return errors for API calls are ejected from the pool for a
-pre-defined period of time.
-See Envoy’s
-circuit breaker
-and outlier detection
-for more details.

-
-

 

 
Optional. The user name/ID that the subject represents.

 
-
groupstring
-
Optional. The group that the subject belongs to.

-
 		
 

 
map<string, string>
 
 
Optional. The set of properties that identify the subject.
-In the above ServiceRoleBinding example, the second subject has two properties:
-    service: “reviews”
-    namespace: “abc”

+The above ServiceRoleBinding example shows an example of property “source.namespace”.

 
 		
 

 

 destinationSubnetstringstring[]
 
-
IPv4 or IPv6 ip address of destination with optional subnet.  E.g.,
-a.b.c.d/xx form or just a.b.c.d. This is only valid when the
-destination service has several IPs and the application explicitly
-specifies a particular IP.

+
IPv4 or IPv6 ip addresses of destination with optional subnet.  E.g.,
+a.b.c.d/xx form or just a.b.c.d.

 
 		
 

 destinationSubnetstringstring[]
 
-
IPv4 or IPv6 ip address of destination with optional subnet.  E.g.,
-a.b.c.d/xx form or just a.b.c.d. This is only valid when the
-destination service has several IPs and the application explicitly
-specifies a particular IP.

+
IPv4 or IPv6 ip addresses of destination with optional subnet.  E.g.,
+a.b.c.d/xx form or just a.b.c.d.

 
 		
 

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
simpleCbCircuitBreaker.SimpleCircuitBreakerPolicy (oneof)
-
customgoogle.protobuf.Any (oneof)
-
(– For proxies that support custom circuit breaker policies. –)

-
-

-

-
CircuitBreaker.SimpleCircuitBreakerPolicy

-

-
A simple circuit breaker can be set based on a number of criteria such as
-connection and request limits. For example, the following destination
-policy sets a limit of 100 connections to “reviews” service version
-“v1” backends.

-
-
metadata:
-  name: reviews-cb-policy
-  namespace: default
-spec:
-  destination:
-    name: reviews
-    labels:
-      version: v1
-  circuitBreaker:
-    simpleCb:
-      maxConnections: 100
-

-
-
The following destination policy sets a limit of 100 connections and
-1000 concurrent requests, with no more than 10 req/connection to
-“reviews” service version “v1” backends. In addition, it configures
-hosts to be scanned every 5 mins, such that any host that fails 7
-consecutive times with 5XX error code will be ejected for 15 minutes.

-
-
metadata:
-  name: reviews-cb-policy
-  namespace: default
-spec:
-  destination:
-    name: reviews
-    labels:
-      version: v1
-  circuitBreaker:
-    simpleCb:
-      maxConnections: 100
-      httpMaxRequests: 1000
-      httpMaxRequestsPerConnection: 10
-      httpConsecutiveErrors: 7
-      sleepWindow: 15m
-      httpDetectionInterval: 5m
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
maxConnectionsint32
-
Maximum number of connections to a backend.

-
-
httpMaxPendingRequestsint32
-
Maximum number of pending requests to a backend. Default 1024

-
-
httpMaxRequestsint32
-
Maximum number of requests to a backend. Default 1024

-
-
sleepWindowgoogle.protobuf.Duration
-
Minimum time the circuit will be open. format: 1h/1m/1s/1ms. MUST
-BE >=1ms. Default is 30s.

-
-
httpConsecutiveErrorsint32
-
Number of 5XX errors before circuit is opened. Defaults to 5.

-
-
httpDetectionIntervalgoogle.protobuf.Duration
-
Time interval between ejection sweep analysis. format:
-1h/1m/1s/1ms. MUST BE >=1ms. Default is 10s.

-
-
httpMaxRequestsPerConnectionint32
-
Maximum number of requests per connection to a backend. Setting this
-parameter to 1 disables keep alive.

-
-
httpMaxEjectionPercentint32
-
Maximum % of hosts in the load balancing pool for the destination
-service that can be ejected by the circuit breaker. Defaults to
-10%.

-
-
httpMaxRetriesint32
-
Maximum number of retries that can be outstanding to all hosts in a
-cluster at a given time. Defaults to 3.

-
-

-

-
CorsPolicy

-

-
Describes the Cross-Origin Resource Sharing (CORS) policy, for a given
-service. Refer to
-https://developer.mozilla.org/en-US/docs/Web/HTTP/AccesscontrolCORS
-for further details about cross origin resource sharing. For example,
-the following rule restricts cross origin requests to those originating
-from example.com domain using HTTP POST/GET, and sets the
-Access-Control-Allow-Credentials header to false. In addition, it only exposes
-X-Foo-bar header and sets an expiry period of 1 day.

-
-
metadata:
-  name: my-rule
-  namespace: default
-spec:
-  destination:
-    name: ratings
-  route:
-  - labels:
-      version: v1
-  corsPolicy:
-    allowOrigin:
-    - example.com
-    allowMethods:
-    - POST
-    - GET
-    allowCredentials: false
-    allowHeaders:
-    - X-Foo-Bar
-    maxAge: "1d"
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
allowOriginstring[]
-
The list of origins that are allowed to perform CORS requests. The content will
-be serialized into the Access-Control-Allow-Origin header. Wildcard * will allow
-all origins.

-
-
allowMethodsstring[]
-
List of HTTP methods allowed to access the resource. The content will
-be serialized into the Access-Control-Allow-Methods header.

-
-
allowHeadersstring[]
-
List of HTTP headers that can be used when requesting the
-resource. Serialized to Access-Control-Allow-Methods header.

-
-
exposeHeadersstring[]
-
A white list of HTTP headers that the browsers are allowed to
-access. Serialized into Access-Control-Expose-Headers header.

-
-
maxAgegoogle.protobuf.Duration
-
Specifies how long the the results of a preflight request can be
-cached. Translates to the Access-Control-Max-Age header.

-
-
allowCredentialsgoogle.protobuf.BoolValue
-
Indicates whether the caller is allowed to send the actual request
-(not the preflight) using credentials. Translates to
-Access-Control-Allow-Credentials header.

-
-

-

-
DestinationPolicy

-

-
DestinationPolicy defines client/caller-side policies that determine how
-to handle traffic bound to a particular destination service. The policy
-specifies configuration for load balancing and circuit breakers. For
-example, a simple load balancing policy for the ratings service would
-look as follows:

-
-
metadata:
-  name: ratings-lb-policy
-  namespace: default # optional (default is "default")
-spec:
-  destination:
-    name: ratings
-  loadBalancing:
-    name: ROUND_ROBIN
-

-
-
The FQDN of the destination service is composed from the destination name and meta namespace fields, along with
-a platform-specific domain suffix
-(e.g. on Kubernetes, “reviews” + “default” + “svc.cluster.local” -> “reviews.default.svc.cluster.local”).

-
-
A destination policy can be restricted to a particular version of a
-service or applied to all versions. It can also be restricted to calls from
-a particular source. For example, the following load balancing policy
-applies to version v1 of the ratings service running in the prod
-environment but only when called from version v2 of the reviews service:

-
-
metadata:
-  name: ratings-lb-policy
-  namespace: default
-spec:
-  source:
-    name: reviews
-    labels:
-      version: v2
-  destination:
-    name: ratings
-    labels:
-      env: prod
-      version: v1
-  loadBalancing:
-    name: ROUND_ROBIN
-

-
-
Note: Destination policies will be applied only if the corresponding
-tagged instances are explicitly routed to. In other words, for every
-destination policy defined, at least one route rule must refer to the
-service version indicated in the destination policy.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
destinationIstioService
-
Optional: Destination uniquely identifies the destination service associated
-with this policy.

-
-
sourceIstioService
-
Optional: Source uniquely identifies the source service associated
-with this policy.

-
-
loadBalancingLoadBalancing
-
Load balancing policy.

-
-
circuitBreakerCircuitBreaker
-
Circuit breaker policy.

-
-
customgoogle.protobuf.Any
-
(– Other custom policy implementations –)

-
-

-

-
DestinationWeight

-

-
Each routing rule is associated with one or more service versions (see
-glossary in beginning of document). Weights associated with the version
-determine the proportion of traffic it receives. For example, the
-following rule will route 25% of traffic for the “reviews” service to
-instances with the “v2” tag and the remaining traffic (i.e., 75%) to
-“v1”.

-
-
metadata:
-  name: my-rule
-  namespace: default
-spec:
-  destination:
-    name: reviews
-  route:
-  - labels:
-      version: v2
-    weight: 25
-  - labels:
-      version: v1
-    weight: 75
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
destinationIstioService
-
Sometimes required. Optional destination uniquely identifies the destination service. If not
-specified, the value is inherited from the parent route rule.

-
-
labelsmap<string, string>
-
Sometimes required. Service version identifier for the destination service.
-(– N.B. The map is used instead of pstruct due to lack of serialization support
-in golang protobuf library (see https://github.com/golang/protobuf/pull/208) –)

-
-
weightint32
-
REQUIRED. The proportion of traffic to be forwarded to the service
-version. (0-100). Sum of weights across destinations SHOULD BE ==
-100. If there is only destination in a rule, the weight value is
-assumed to be 100. When using multiple weights, either destination or labels must be
-specified.

-
-

-

-
EgressRule

-

-
Egress rules describe the properties of a service outside Istio. When transparent proxying
-is used, egress rules signify a white listed set of external services that microserves in the mesh
-are allowed to access. A subset of routing rules and all destination policies can be applied
-on the service targeted by an egress rule. TCP services and HTTP-based services can be expressed
-by an egress rule. The destination of an egress rule for HTTP-based services must be an IP or a domain name,
-optionally with a wildcard prefix  (e.g., *.foo.com). For TCP based services, the destination of an
-egress rule must be an IP or a block of IPs in CIDR notation.

-
-
If TLS origination from the sidecar is desired, the protocol
-associated with the service port must be marked as HTTPS, and the service is expected to
-be accessed over HTTP (e.g., http://gmail.com:443). The sidecar will automatically upgrade
-the connection to TLS when initiating a connection with the external service.

-
-
For example, the following egress rule describes the set of services hosted under the *.foo.com domain

-
-
kind: EgressRule
-metadata:
-  name: foo-egress-rule
-spec:
-  destination:
-    service: *.foo.com
-  ports:
-    - port: 80
-      protocol: http
-    - port: 443
-      protocol: https
-

-
-
The following egress rule describes the set of services accessed by a block of IPs

-
-
kind: EgressRule
-metadata:
-  name: bar-egress-rule
-spec:
-  destination:
-    service: 92.198.174.192/27
-  ports:
-    - port: 111
-      protocol: tcp
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
destinationIstioService
-
REQUIRED: A domain name, optionally with a wildcard prefix, or an IP, or a block of IPs
-associated with the external service.
-ONLY the “service” field of “destination” will be taken into consideration. Name,
-namespace, domain and labels are ignored. Routing rules and destination policies that
-refer to these external services must have identical specification for the destination
-as the corresponding egress rule.

-
-
The “service” field of “destination” for HTTP-based services must be an IP or a domain name,
-optionally with a wildcard prefix. Wildcard domain specifications must conform to format
-allowed by Envoy’s Virtual Host specification, such as “.foo.com” or “-bar.foo.com”.
-The character ‘’ in a domain specification indicates a non-empty string. Hence, a wildcard
-domain of form “-bar.foo.com” will match “baz-bar.foo.com” but not “-bar.foo.com”.

-
-
The “service” field of “destination” for TCP services must be an IP or a block of IPs in CIDR notation.

-
-
portsEgressRule.Port[]
-
REQUIRED: list of ports on which the external service is available.

-
-
useEgressProxybool
-
Forward all the external traffic through a dedicated egress proxy. It is used in some scenarios
-where there is a requirement that all the external traffic goes through special dedicated nodes/pods.
-These dedicated egress nodes could then be more closely monitored for security vulnerabilities.

-
-
The default is false, i.e. the sidecar forwards external traffic directly to the external service.

-
-

-

-
EgressRule.Port

-

-
Port describes the properties of a specific TCP port of an external service.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
portint32
-
A valid non-negative integer port number.

-
-
protocolstring
-
The protocol to communicate with the external services.
-MUST BE one of HTTP|HTTPS|GRPC|HTTP2|TCP|MONGO.

-
-

-

-
HTTPFaultInjection

-

-
HTTPFaultInjection can be used to specify one or more faults to inject
-while forwarding http requests to the destination specified in the route
-rule.  Fault specification is part of a route rule. Faults include
-aborting the Http request from downstream service, and/or delaying
-proxying of requests. A fault rule MUST HAVE delay or abort or both.

-
-
Note: Delay and abort faults are independent of one another, even if
-both are specified simultaneously.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
delayHTTPFaultInjection.Delay
-
Delay requests before forwarding, emulating various failures such as
-network issues, overloaded upstream service, etc.

-
-
abortHTTPFaultInjection.Abort
-
Abort Http request attempts and return error codes back to downstream
-service, giving the impression that the upstream service is faulty.

-
-

-

-
HTTPFaultInjection.Abort

-

-
Abort specification is used to prematurely abort a request with a
-pre-specified error code. The following example will return an HTTP
-400 error code for 10% of the requests to the “ratings” service “v1”.

-
-
metadata:
-  name: my-rule
-spec:
-  destination:
-    name: reviews
-  route:
-  - labels:
-      version: v1
-  httpFault:
-    abort:
-      percent: 10
-      httpStatus: 400
-

-
-
The httpStatus field is used to indicate the HTTP status code to
-return to the caller. The optional percent field, a value between 0
-and 100, is used to only abort a certain percentage of requests. If
-not specified, all requests are aborted.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
percentfloat
-
percentage of requests to be aborted with the error code provided (0-100).

-
-
grpcStatusstring (oneof)
-
http2Errorstring (oneof)
-
httpStatusint32 (oneof)
-
REQUIRED. HTTP status code to use to abort the Http request.

-
-
overrideHeaderNamestring
-
(– Specify abort code as part of Http request.
-TODO: The semantics and syntax of the headers is undefined. –)

-
-

-

-
HTTPFaultInjection.Delay

-

-
Delay specification is used to inject latency into the request
-forwarding path. The following example will introduce a 5 second delay
-in 10% of the requests to the “v1” version of the “reviews”
-service.

-
-
metadata:
-  name: my-rule
-spec:
-  destination:
-    name: reviews
-  route:
-  - labels:
-      version: v1
-  httpFault:
-    delay:
-      percent: 10
-      fixedDelay: 5s
-

-
-
The fixedDelay field is used to indicate the amount of delay in
-seconds. An optional percent field, a value between 0 and 100, can
-be used to only delay a certain percentage of requests. If left
-unspecified, all request will be delayed.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
percentfloat
-
percentage of requests on which the delay will be injected (0-100)

-
-
fixedDelaygoogle.protobuf.Duration (oneof)
-
REQUIRED. Add a fixed delay before forwarding the request. Format: 1h/1m/1s/1ms. MUST be >=1ms.

-
-
exponentialDelaygoogle.protobuf.Duration (oneof)
-
(– Add a delay (based on an exponential function) before forwarding
-the request. mean delay needed to derive the exponential delay
-values –)

-
-
overrideHeaderNamestring
-
(– Specify delay duration as part of Http request.
-TODO: The semantics and syntax of the headers is undefined. –)

-
-

-

-
HTTPRedirect

-

-
HTTPRedirect can be used to send a 302 redirect response to the caller,
-where the Authority/Host and the URI in the response can be swapped with
-the specified values. For example, the following route rule redirects
-requests for /v1/getProductRatings API on the ratings service to
-/v1/bookRatings provided by the bookratings service.

-
-
metadata:
-  name: my-rule
-  namespace: default
-spec:
-  destination:
-    name: ratings
-  match:
-    request:
-      headers:
-        uri: /v1/getProductRatings
-  redirect:
-    uri: /v1/bookRatings
-    authority: bookratings.default.svc.cluster.local
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
uristring
-
On a redirect, overwrite the Path portion of the URL with this
-value. Note that the entire path will be replaced, irrespective of the
-request URI being matched as an exact path or prefix.

-
-
authoritystring
-
On a redirect, overwrite the Authority/Host portion of the URL with
-this value

-
-

-

-
HTTPRetry

-

-
Describes the retry policy to use when a HTTP request fails. For
-example, the following rule sets the maximum number of retries to 3 when
-calling ratings:v1 service, with a 2s timeout per retry attempt.

-
-
metadata:
-  name: my-rule
-  namespace: default
-spec:
-  destination:
-    name: ratings
-  route:
-  - labels:
-      version: v1
-  httpReqRetries:
-    simpleRetry:
-      attempts: 3
-      perTryTimeout: 2s
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
simpleRetryHTTPRetry.SimpleRetryPolicy (oneof)
-
customgoogle.protobuf.Any (oneof)
-
(– For proxies that support custom retry policies –)

-
-

-

-
HTTPRetry.SimpleRetryPolicy

-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
attemptsint32
-
REQUIRED. Number of retries for a given request. The interval
-between retries will be determined automatically (25ms+). Actual
-number of retries attempted depends on the httpReqTimeout.

-
-
perTryTimeoutgoogle.protobuf.Duration
-
Timeout per retry attempt for a given request. format: 1h/1m/1s/1ms. MUST BE >=1ms.

-
-
overrideHeaderNamestring
-
(– Downstream Service could specify retry attempts via Http header to
-Envoy, if Envoy supports such a feature. –)

-
-

-

-
HTTPRewrite

-

-
HTTPRewrite can be used to rewrite specific parts of a HTTP request
-before forwarding the request to the destination. Rewrite primitive can
-be used only with the DestinationWeights. The following example
-demonstrates how to rewrite the URL prefix for api call (/ratings) to
-ratings service before making the actual API call.

-
-
metadata:
-  name: my-rule
-  namespace: default
-spec:
-  destination:
-    name: ratings
-  match:
-    request:
-      headers:
-        uri:
-          prefix: /ratings
-  rewrite:
-    uri: /v1/bookRatings
-  route:
-  - labels:
-      version: v1
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
uristring
-
rewrite the Path (or the prefix) portion of the URI with this
-value. If the original URI was matched based on prefix, the value
-provided in this field will replace the corresponding matched prefix.

-
-
authoritystring
-
rewrite the Authority/Host header with this value.

-
-

-

-
HTTPTimeout

-

-
Describes HTTP request timeout. For example, the following rule sets a
-10 second timeout for calls to the ratings:v1 service

-
-
metadata:
-  name: my-rule
-  namespace: default
-spec:
-  destination:
-    name: ratings
-  route:
-  - labels:
-      version: v1
-  httpReqTimeout:
-    simpleTimeout:
-      timeout: 10s
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
simpleTimeoutHTTPTimeout.SimpleTimeoutPolicy (oneof)
-
customgoogle.protobuf.Any (oneof)
-
(– For proxies that support custom timeout policies –)

-
-

-

-
HTTPTimeout.SimpleTimeoutPolicy

-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
timeoutgoogle.protobuf.Duration
-
REQUIRED. Timeout for a HTTP request. Includes retries as well.  Default
-15s. format: 1h/1m/1s/1ms. MUST BE >=1ms. It is possible to control
-timeout per request by supplying the timeout value via
-x-envoy-upstream-rq-timeout-ms HTTP header.

-
-
overrideHeaderNamestring
-
(– Downstream service could specify timeout via Http header to
-Envoy, if Envoy supports such a feature. –)

-
-

-

-
IngressRule

-

-
Ingress rules are routing rules applied to the ingress proxy pool. The
-ingress proxies serve as the receiving edge proxy for the entire mesh, but
-can also be addressed from inside the mesh.  Each ingress rule defines a
-destination service and port. Rules that do not resolve to a service or a
-port in the mesh should be ignored.

-
-
The routing rules for the destination service are applied at the ingress
-proxy. That means the routing rule match conditions are composed and its
-actions are enforced. The traffic splitting for the destination service is
-also effective.

-
-
WARNING: This API is experimental and under active development

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
portint32
-
REQUIRED: Port on which the ingress proxy listens and applies the rule.

-
-
tlsSecretstring
-
Optional TLS secret path to apply server-side TLS context on the port.
-It is up to the underlying secret store to interpret the path to the secret.

-
-
precedenceint32
-
RECOMMENDED. Precedence is used to disambiguate the order of application
-of rules. A higher number takes priority. If not specified, the value is
-assumed to be 0.  The order of application for rules with the same
-precedence is unspecified.

-
-
matchMatchCondition
-
Match conditions to be satisfied for the ingress rule to be
-activated.

-
-
destinationIstioService
-
REQUIRED: Destination uniquely identifies the destination service.

-
-
Note: The ingress rule destination specification represents all version
-of the service and therefore the IstioService’s labels field MUST be empty.

-
-
destinationPortint32 (oneof)
-
Identifies the destination service port by value

-
-
destinationPortNamestring (oneof)
-
Identifies the destination service port by name

-
-

-

-
IstioService

-

-
IstioService identifies a service and optionally service version.
-The FQDN of the service is composed from the name, namespace, and implementation-specific domain suffix
-(e.g. on Kubernetes, “reviews” + “default” + “svc.cluster.local” -> “reviews.default.svc.cluster.local”).

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
namestring
-
The short name of the service such as “foo”.

-
-
namespacestring
-
Optional namespace of the service. Defaults to value of metadata namespace field.

-
-
domainstring
-
Domain suffix used to construct the service FQDN in implementations that support such specification.

-
-
servicestring
-
The service FQDN.

-
-
labelsmap<string, string>
-
Optional one or more labels that uniquely identify the service version.

-
-
Note: When used for a RouteRule destination, labels MUST be empty.

-
-

-

-
L4FaultInjection

-

-
(– Faults can be injected into the connections from downstream by the
-Envoy, for testing the failure recovery capabilities of downstream
-services.  Faults include aborting the connection from downstream
-service, delaying proxying of connection to the destination
-service, and throttling the bandwidth of the connection (either
-end). Bandwidth throttling for failure testing should not be confused
-with the rate limiting policy enforcement provided by the Mixer
-component. L4 fault injection is not supported at the moment. –)

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
throttleL4FaultInjection.Throttle
-
Unlike Http services, we have very little context for raw Tcp|Udp
-connections. We could throttle bandwidth of the connections (slow down
-the connection) and/or abruptly reset (terminate) the Tcp connection
-after it has been established.
-We first throttle (if set) and then terminate the connection.

-
-
terminateL4FaultInjection.Terminate
-

-

-
L4FaultInjection.Terminate

-

-
Abruptly reset (terminate) the Tcp connection after it has been
-established, emulating remote server crash or link failure.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
percentfloat
-
percentage of established Tcp connections to be terminated/reset

-
-
terminateAfterPeriodgoogle.protobuf.Duration
-
TODO: see if it makes sense to create a generic Duration type to
-express time interval related configs.

-
-

-

-
L4FaultInjection.Throttle

-

-
Bandwidth throttling for Tcp and Udp connections

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
percentfloat
-
percentage of connections to throttle.

-
-
downstreamLimitBpsint64
-
bandwidth limit in “bits” per second between downstream and Envoy

-
-
upstreamLimitBpsint64
-
bandwidth limits in “bits” per second between Envoy and upstream

-
-
throttleAfterPeriodgoogle.protobuf.Duration (oneof)
-
Wait a while after the connection is established, before
-starting bandwidth throttling. This would allow us to inject fault
-after the application protocol (e.g., MySQL) has had time to
-establish sessions/whatever handshake necessary.

-
-
throttleAfterBytesdouble (oneof)
-
Alternatively, we could wait for a certain number of bytes to be
-transferred to upstream before throttling the bandwidth.

-
-
throttleForPeriodgoogle.protobuf.Duration
-
Stop throttling after the given duration. If not set, the connection
-will be throttled for its lifetime.

-
-

-

-
L4MatchAttributes

-

-
(– L4 connection match attributes. Note that L4 connection matching
-support is incomplete. –)

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
sourceSubnetstring[]
-
IPv4 or IPv6 ip address with optional subnet. E.g., a.b.c.d/xx form or
-just a.b.c.d

-
-
destinationSubnetstring[]
-
IPv4 or IPv6 ip address of destination with optional subnet.
-E.g., a.b.c.d/xx form or just a.b.c.d. This is only valid when the destination
-service has several IPs and the application explicitly specifies a particular IP.

-
-

-

-
LoadBalancing

-

-
Load balancing policy to use when forwarding traffic. These policies
-directly correlate to load balancer
-types
-supported by Envoy. Example,

-
-
metadata:
-  name: reviews-lb-policy
-  namespace: default
-spec:
-  destination:
-    name: reviews
-  loadBalancing:
-    name: RANDOM
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
nameLoadBalancing.SimpleLBPolicy (oneof)
-
Load balancing policy name (as defined in SimpleLBPolicy below)

-
-
customgoogle.protobuf.Any (oneof)
-
(– Custom LB policy implementations –)

-
-

-

-
LoadBalancing.SimpleLBPolicy

-

-
Load balancing algorithms supported by Envoy.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
NameDescription
ROUND_ROBIN
-
Simple round robin policy.

-
-
LEAST_CONN
-
The least request load balancer uses an O(1) algorithm which selects
-two random healthy hosts and picks the host which has fewer active
-requests.

-
-
RANDOM
-
The random load balancer selects a random healthy host. The random
-load balancer generally performs better than round robin if no health
-checking policy is configured.

-
-

-

-
MatchCondition

-

-
Match condition specifies a set of criterion to be met in order for the
-route rule to be applied to the connection or HTTP request. The
-condition provides distinct set of conditions for each protocol with the
-intention that conditions apply only to the service ports that match the
-protocol. For example, the following route rule restricts the rule to
-match only requests originating from “reviews:v2”, accessing ratings
-service where the URL path starts with /ratings/v2/ and the request
-contains a “cookie” with value “user=jason”,

-
-
metadata:
-  name: my-rule
-  namespace: default
-spec:
-  destination:
-    name: ratings
-  match:
-    source:
-      name: reviews
-      labels:
-        version: v2
-    request:
-      headers:
-        cookie:
-          regex: "^(.*?;)?(user=jason)(;.*)?"
-        uri:
-          prefix: "/ratings/v2/"
-

-
-
MatchCondition CANNOT be empty. At least one source or
-request header must be specified.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
sourceIstioService
-
Identifies the service initiating a connection or a request.

-
-
tcpL4MatchAttributes
-
(– Set of layer 4 match conditions based on the IP ranges –)

-
-
udpL4MatchAttributes
-
(– Set of layer 4 match conditions based on the IP ranges –)

-
-
requestMatchRequest
-
Attributes of an HTTP request to match.

-
-

-

-
MatchRequest

-

-
MatchRequest specifies the attributes of an HTTP request to be used for matching a request.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
headersmap<string, StringMatch>
-
Set of HTTP match conditions based on HTTP/1.1, HTTP/2, GRPC request
-metadata, such as uri, scheme, authority.  The header keys must be
-lowercase and use hyphen as the separator, e.g. x-request-id.

-
-
Header values are case-sensitive and formatted as follows:

-
-
exact: “value” or just “value” for exact string match

-
-
prefix: “value” for prefix-based match

-
-
regex: “value” for ECMAscript style regex-based match

-
-
Note 1: The keys uri, scheme, method, and authority correspond
-to URI, protocol scheme (e.g., HTTP, HTTPS), HTTP method
-(e.g., GET, POST), and the HTTP Host header respectively.

-
-
Note 2: uri can be used to perform URL matches.
-For all HTTP headers including uri, exact, prefix and ECMA style
-regular expression matches are supported.

-
-

-

-
RouteRule

-

-
Route rule provides a custom routing policy based on the source and
-destination service versions and connection/request metadata.  The rule
-must provide a set of conditions for each protocol (TCP, UDP, HTTP) that
-the destination service exposes on its ports.

-
-
The rule applies only to the ports on the destination service for which
-it provides protocol-specific match condition, e.g. if the rule does not
-specify TCP condition, the rule does not apply to TCP traffic towards
-the destination service.

-
-
For example, a simple rule to send 100% of incoming traffic for a
-“reviews” service to version “v1” can be specified as follows:

-
-
metadata:
-  name: my-rule
-  namespace: default # optional (default is "default")
-spec:
-  destination:
-    name: reviews
-    namespace: my-namespace # optional (default is metadata namespace field)
-  route:
-  - labels:
-      version: v1
-    weight: 100
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
destinationIstioService
-
REQUIRED: Destination uniquely identifies the destination associated
-with this routing rule. This field is applicable for hostname-based
-resolution for HTTP traffic as well as IP-based resolution for
-TCP/UDP traffic.

-
-
Note: The route rule destination specification represents all version
-of the service and therefore the IstioService’s labels field MUST be empty.

-
-
precedenceint32
-
RECOMMENDED. Precedence is used to disambiguate the order of
-application of rules for the same destination service. A higher number
-takes priority. If not specified, the value is assumed to be 0.  The
-order of application for rules with the same precedence is
-unspecified.

-
-
matchMatchCondition
-
Match conditions to be satisfied for the route rule to be
-activated. If match is omitted, the route rule applies only to HTTP
-traffic.

-
-
routeDestinationWeight[]
-
REQUIRED (route|redirect). A routing rule can either redirect traffic or
-forward traffic. The forwarding target can be one of several versions
-of a service (see glossary in beginning of document). Weights
-associated with the service version determine the proportion of
-traffic it receives.

-
-
redirectHTTPRedirect
-
REQUIRED (route|redirect). A routing rule can either redirect traffic or
-forward traffic. The redirect primitive can be used to send a HTTP 302
-redirect to a different URI or Authority.

-
-
rewriteHTTPRewrite
-
Rewrite HTTP URIs and Authority headers. Rewrite cannot be used with
-Redirect primitive. Rewrite will be performed before forwarding.

-
-
websocketUpgradebool
-
Indicates that a HTTP/1.1 client connection to this particular route
-should be allowed (and expected) to upgrade to a WebSocket connection.
-The default is false. Envoy expects the first request to this route
-to contain the WebSocket upgrade headers. Otherwise, the request
-will be rejected.

-
-
httpReqTimeoutHTTPTimeout
-
Timeout policy for HTTP requests.

-
-
httpReqRetriesHTTPRetry
-
Retry policy for HTTP requests.

-
-
httpFaultHTTPFaultInjection
-
Fault injection policy to apply on HTTP traffic

-
-
l4FaultL4FaultInjection
-
(– L4 fault injection policy applies to Tcp/Udp (not HTTP) traffic –)

-
-
mirrorIstioService
-
Mirror HTTP traffic to a another destination in addition to forwarding
-the requests to the intended destination. Mirrored traffic is on best
-effort basis where Envoy will not wait for the mirrored cluster to
-respond before returning the response from the original destination.
-Statistics will be generated for the mirrored destination.

-
-
corsPolicyCorsPolicy
-
Cross-Origin Resource Sharing policy (CORS). Refer to
-https://developer.mozilla.org/en-US/docs/Web/HTTP/AccesscontrolCORS for
-further details about cross origin resource sharing.

-
-
appendHeadersmap<string, string>
-
Additional HTTP headers to add before forwarding a request to the
-destination service.

-
-

-

-
StringMatch

-

-
Describes how to match a given string in HTTP headers. Match is case-sensitive.

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
exactstring (oneof)
-
exact string match

-
-
prefixstring (oneof)
-
prefix-based match

-
-
regexstring (oneof)
-
ECMAscript style regex-based match

-
-

-

diff --git a/content/docs/reference/config/policy-and-telemetry/adapters/apigee/index.html b/content/docs/reference/config/policy-and-telemetry/adapters/apigee/index.html
index 1a0e2c0d41..1ec95ed5be 100644
--- a/content/docs/reference/config/policy-and-telemetry/adapters/apigee/index.html
+++ b/content/docs/reference/config/policy-and-telemetry/adapters/apigee/index.html
@@ -30,7 +30,7 @@ spec:
   temp_dir: "/tmp/apigee-istio"
   client_timeout: 30s
   products:
-    refresh_rate: 60s
+    refresh_rate: 2m
   analytics:
     legacy_endpoint: false
     file_limit: 1024
@@ -122,7 +122,7 @@ Optional. Default: “/tmp/apigee-istio”.

 google.protobuf.Duration
 
 
The timeout to be used for adapter requests to Apigee servers.
-Optional. Default: “30s”.

+Optional. Default: “30s” (30 seconds).

 
 
 
@@ -206,7 +206,7 @@ Optional. Default: 1024.

 google.protobuf.Duration
 
 
The rate at which the list of products is refreshed from Apigee.
-Optional. Default: “60s”.

+Optional. Default: “2m” (2 minutes).

 
 
 
diff --git a/content/docs/reference/config/policy-and-telemetry/templates/kubernetes/index.html b/content/docs/reference/config/policy-and-telemetry/templates/kubernetes/index.html
index 2aca1a15ed..3159bcfa84 100644
--- a/content/docs/reference/config/policy-and-telemetry/templates/kubernetes/index.html
+++ b/content/docs/reference/config/policy-and-telemetry/templates/kubernetes/index.html
@@ -4,7 +4,7 @@ description: A template that is used to control the production of Kubernetes-spe
 location: https://istio.io/docs/reference/config/policy-and-telemetry/templates/kubernetes.html
 layout: protoc-gen-docs
 generator: protoc-gen-docs
-number_of_entries: 3
+number_of_entries: 2
 ---
 
The kubernetes template holds data that controls the production of Kubernetes-specific
 attributes.

@@ -41,7 +41,7 @@ spec:
 

 
OutputTemplate refers to the output from the adapter. It is used inside the attribute_binding section of the config
 to assign values to the generated attributes using the $out.<field name of the OutputTemplate> syntax.
-Next ID: 31

+Next ID: 33

 
 
@@ -52,9 +52,18 @@ Next ID: 31

+
+
+
+
+
-
+
-
+
+
+
+
+
+
-
+
-
+
-
+
-
+

 
 
 
 
sourcePodUidstring
+
Refers to the source.uid for a pod. This is for TCP use cases where the attribute is not present.
+attributebindings can refer to this field using $out.sourcepod_uid

+
+

 

 sourcePodIpistio.policy.v1beta1.IPAddressistio.policy.v1beta1.IPAddress
 
 
Refers to source pod ip address. attributebindings can refer to this field using $out.sourcepod_ip

 
@@ -94,7 +103,7 @@ Next ID: 31

 

 

 sourceHostIpistio.policy.v1beta1.IPAddressistio.policy.v1beta1.IPAddress
 
 
Refers to source pod host ip address. attributebindings can refer to this field using $out.sourcehost_ip

 
@@ -130,11 +139,20 @@ Next ID: 31

 		
 
Refers to the (controlling) owner of the source pod. Attributebindings can refer to this field using $out.sourceowner

 
+
destinationPodUidstring
+
Refers to the destination.uid for a pod. This is for TCP use cases where the attribute is not present.
+attributebindings can refer to this field using $out.destinationpod_uid

+
 		
 

 

 destinationPodIpistio.policy.v1beta1.IPAddressistio.policy.v1beta1.IPAddress
 
 
Refers to destination pod ip address. attributebindings can refer to this field using $out.destinationpod_ip

 
@@ -182,7 +200,7 @@ Next ID: 31

 

 

 destinationHostIpistio.policy.v1beta1.IPAddressistio.policy.v1beta1.IPAddress
 
 
Refers to destination pod host ip address. attributebindings can refer to this field using $out.destinationhost_ip

 
@@ -250,7 +268,7 @@ Next ID: 8

 

 

 sourceIpistio.policy.v1beta1.IPAddressistio.policy.v1beta1.IPAddress
 
 
Source pod’s ip.

 
@@ -266,7 +284,7 @@ Next ID: 8

 

 

 destinationIpistio.policy.v1beta1.IPAddressistio.policy.v1beta1.IPAddress
 
 
Destination pod’s ip.

 
@@ -283,31 +301,3 @@ Next ID: 8

 

 

 

-
istio.policy.v1beta1.IPAddress

-

-
An instance field of type IPAddress denotes that the expression for the field must evalaute to
-ValueType.IP_ADDRESS

-
-
Objects of type IPAddress are also passed to the adapters during request-time for the instance fields of
-type IPAddress

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
FieldTypeDescription
valuebytes
-
IPAddress encoded as bytes.

-
-

-

diff --git a/content_zh/blog/2018/v1alpha3-routing/index.md b/content_zh/blog/2018/v1alpha3-routing/index.md
index 184b7ecbe9..be6b30f4d0 100644
--- a/content_zh/blog/2018/v1alpha3-routing/index.md
+++ b/content_zh/blog/2018/v1alpha3-routing/index.md
@@ -12,7 +12,7 @@ keywords: [traffic-management]
 
 虽然目前 API 的功能已被证明是 Istio 非常引人注目的一部分，但用户的反馈也表明，这个 API 确实有一些缺点，尤其是在使用它来管理包含数千个服务的非常大的应用程序，以及使用 HTTP 以外的协议时。 此外，使用 Kubernetes Ingress 资源来配置外部流量的方式已被证明不能满足需求。
 
-为了解决上述缺陷和其他的一些问题，Istio 引入了新的流量管理 API v1alpha3，新版本的 API 将完全取代之前的 API。 尽管 v1alpha3 和之前的模型在本质上是基本相同的，但它并不向后兼容的，基于旧API的模型需要进行手动转换。 Istio 接下来的几个版本中提供一个[转换工具](/docs/reference/commands/istioctl/#istioctl-experimental-convert-networking-config)来协助新旧模型的升级。
+为了解决上述缺陷和其他的一些问题，Istio 引入了新的流量管理 API v1alpha3，新版本的 API 将完全取代之前的 API。 尽管 v1alpha3 和之前的模型在本质上是基本相同的，但它并不向后兼容的，基于旧API的模型需要进行手动转换。
 
 为了证明该非兼容升级的必要性，v1alpha3 API 经历了漫长而艰苦的社区评估过程，以希望新的API能够大幅改进，并经得起时间考验。 在本文中，我们将介绍新的配置模型，并试图解释影响这次变化的一些动机和设计原则。
 
diff --git a/scripts/grab_reference_docs.sh b/scripts/grab_reference_docs.sh
index 1776ebba2f..14c85526f2 100755
--- a/scripts/grab_reference_docs.sh
+++ b/scripts/grab_reference_docs.sh
@@ -20,6 +20,8 @@ export GOPATH=$(mktemp -d)
 WORK_DIR=${GOPATH}/src/istio.io
 COMMAND_DIR=$ISTIO_BASE/content/docs/reference/commands
 
+echo $WORK_DIR
+
 # Get the source code
 mkdir -p ${WORK_DIR}
 pushd $WORK_DIR
@@ -56,10 +58,6 @@ locate_file() {
 
 # Given the path and name to an Istio command, builds the command and then
 # runs it to extract its command-line docs
-#
-# TODO: Even though this CDs into the source tree we've extracted, it's not actually
-# using that as input sources since imports are resolved through $GOPATH and such.
-# I'm not clear what voodoo is needed so I'm leaving this as-is for the time being
 get_command_doc() {
     COMMAND_PATH=$1
     COMMAND=$2
@@ -73,9 +71,22 @@ get_command_doc() {
     popd
 }
 
-# # First delete all the current generated files so that any stale files are removed
+# delete all the current generated files so that any stale files are removed
 find content/docs/reference -name '*.html' -type f|xargs rm 2>/dev/null
 
+get_command_doc ${WORK_DIR}/istio/mixer/cmd/mixc mixc
+get_command_doc ${WORK_DIR}/istio/mixer/cmd/mixs mixs
+get_command_doc ${WORK_DIR}/istio/istioctl/cmd/istioctl istioctl
+get_command_doc ${WORK_DIR}/istio/pilot/cmd/pilot-agent pilot-agent
+get_command_doc ${WORK_DIR}/istio/pilot/cmd/pilot-discovery pilot-discovery
+get_command_doc ${WORK_DIR}/istio/pilot/cmd/sidecar-injector sidecar-injector
+get_command_doc ${WORK_DIR}/istio/security/cmd/istio_ca istio_ca
+get_command_doc ${WORK_DIR}/istio/security/cmd/node_agent node_agent
+get_command_doc ${WORK_DIR}/istio/galley/cmd/galley galley
+
+# delete the vendor dir so we don't get .pb.html out of there
+rm -fr $WORK_DIR/istio/vendor
+
 for f in `find $WORK_DIR/istio -type f -name '*.pb.html'`
 do
     echo "processing $f"
@@ -94,16 +105,6 @@ do
     locate_file ${f}
 done
 
-get_command_doc ${WORK_DIR}/istio/mixer/cmd/mixc mixc
-get_command_doc ${WORK_DIR}/istio/mixer/cmd/mixs mixs
-get_command_doc ${WORK_DIR}/istio/istioctl/cmd/istioctl istioctl
-get_command_doc ${WORK_DIR}/istio/pilot/cmd/pilot-agent pilot-agent
-get_command_doc ${WORK_DIR}/istio/pilot/cmd/pilot-discovery pilot-discovery
-get_command_doc ${WORK_DIR}/istio/pilot/cmd/sidecar-injector sidecar-injector
-get_command_doc ${WORK_DIR}/istio/security/cmd/istio_ca istio_ca
-get_command_doc ${WORK_DIR}/istio/security/cmd/node_agent node_agent
-get_command_doc ${WORK_DIR}/istio/galley/cmd/galley galley
-
 # Copy all the example files over into the examples directory
 # cp $WORK_DIR/istio/Makefile examples/Makefile