templatestringA go-style template string (https://golang.org/pkg/fmt/#hdr-Printing) +
A go-style template string (https://golang.org/pkg/fmt/#hdr-Printing) defining how to combine the args for a particular message into a log line. Required.
@@ -175,10 +175,10 @@string[]A list of strings specifying the resource identifiers that were the cause -of message generation. A “path” here is a (NAMESPACE\/)?RESOURCETYPE/NAME +of message generation. A “path” here is a (NAMESPACE/)?RESOURCETYPE/NAME tuple that uniquely identifies a particular resource. There doesn’t seem to be a single concept for this, but this is intuitively taken from -https://kubernetes.io/docs/reference/using-api/api-concepts/#standard-api-terminology +https://kubernetes.io/docs/reference/using-api/api-concepts/#standard-api-terminology At least one is required.
The trust domain aliases represent the aliases of trust_domain.
For example, if we have
trustDomain: td1
trustDomainAliases: ["td2", "td3"]
Any service with the identity td1/ns/foo/sa/a-service-account, td2/ns/foo/sa/a-service-account,
or td3/ns/foo/sa/a-service-account will be treated the same in the Istio mesh.
* - All Namespaces
. - Current Namespace
~ - No Namespace
If not set the system will use “*” as the default value which implies that services are exported to all namespaces.
-All namespaces is a reasonable default for implementations that don’t
need to restrict access or visibility of services across namespace
boundaries. If that requirement is present it is generally good practice to
@@ -361,7 +356,6 @@
For further discussion see the reference documentation for ServiceEntry,
Sidecar, and Gateway.
The default value for the VirtualService.export_to field. Has the same
syntax as default_service_export_to.
If not set the system will use “*” as the default value which implies that virtual services are exported to all namespaces
@@ -391,7 +384,6 @@The default value for the DestinationRule.export_to field. Has the same
syntax as default_service_export_to.
If not set the system will use “*” as the default value which implies that destination rules are exported to all namespaces
@@ -409,7 +401,6 @@The precise semantics of this processing are documented on each resource type.
@@ -463,18 +454,14 @@inbound|<port>|<port-name>|<service-FQDN>.
For example inbound|7443|grpc-reviews|reviews.prod.svc.cluster.local. This can be used to override that pattern.
-
A Pattern can be composed of various pre-defined variables. The following variables are supported.
-%SERVICE% - Will be substituted with name of the service.%SERVICE_FQDN% - Will be substituted with FQDN of the service.%SERVICE_PORT% - Will be substituted with port of the service.%SERVICE_PORT_NAME% - Will be substituted with port name of the service.Following are some examples of supported patterns for reviews:
-%SERVICE_FQDN%_%SERVICE_PORT% will use reviews.prod.svc.cluster.local_7443 as the stats name.%SERVICE% will use reviews.prod as the stats name.outbound|<port>|<subsetname>|<service-FQDN>.
For example outbound|8080|v2|reviews.prod.svc.cluster.local. This can be used to override that pattern.
-
A Pattern can be composed of various pre-defined variables. The following variables are supported.
-%SERVICE% - Will be substituted with name of the service.%SERVICE_FQDN% - Will be substituted with FQDN of the service.%SERVICE_PORT_NAME% - Will be substituted with port name of the service.%SUBSET_NAME% - Will be substituted with subset.Following are some examples of supported patterns for reviews:
-%SERVICE_FQDN%_%SERVICE_PORT% will use reviews.prod.svc.cluster.local_7443 as the stats name.%SERVICE% will use reviews.prod as the stats name.env: prod and region: us-east1
-2. The namespace has label app equal to cassandra or spark.
-
+The following example selects any namespace that matches either below:
+env: prod and region: us-east1app equal to cassandra or spark.discoverySelectors:
- matchLabels:
env: prod
@@ -593,7 +577,6 @@ MeshConfig
- cassandra
- spark
Refer to the kubernetes selector docs for additional detail on selector semantics.
@@ -625,7 +608,7 @@Configure the default HTTP retry policy. The default number of retry attempts is set at 2 for these errors: - “connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes”. +“connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes”. Setting the number of attempts to 0 disables retry policy globally. This setting can be overriden on a per-host basis using the Virtual Service API. @@ -760,9 +743,9 @@
string (oneof)The SPIFFE bundle endpoint URL that complies to: -https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE_Trust_Domain_and_Bundle.md#the-spiffe-trust-domain-and-bundle +https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE_Trust_Domain_and_Bundle.md#the-spiffe-trust-domain-and-bundle The endpoint should support authentication based on Web PKI: -https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE_Trust_Domain_and_Bundle.md#521-web-pki +https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE_Trust_Domain_and_Bundle.md#521-web-pki The certificate is retrieved from the endpoint.
ClientTLSSettingsUse the tls_settings to specify the tls mode to use. -Regarding tls_settings: -- DISABLE MODE is legitimate for the case Istiod is making the request via an Envoy sidecar. -DISABLE MODE can also be used for testing -- TLS MUTUAL MODE be on by default. If the CA certificates +Regarding tls_settings:
+Holds the name references to the providers that will be used by default in other Istio configuration resources if the provider is not specified.
-These names must match a provider defined in extension_providers that is
one of the supported tracing providers.
There are some common scenarios when this can be useful:
-By default Istio will consider kubernetes.default.svc (i.e. the API Server) as well as all services in the kube-system namespace to be cluster-local, unless explicitly overridden here.
@@ -1297,8 +1278,8 @@boolIf true, the body sent to the external authorization service in the gRPC authorization request is set with raw bytes -in the raw_body field (https://github.com/envoyproxy/envoy/blame/cffb095d59d7935abda12b9509bcd136808367bb/api/envoy/service/auth/v3/attribute_context.proto#L153). -Otherwise, it will be filled with UTF-8 string in the body field (https://github.com/envoyproxy/envoy/blame/cffb095d59d7935abda12b9509bcd136808367bb/api/envoy/service/auth/v3/attribute_context.proto#L147). +in the raw_body field (https://github.com/envoyproxy/envoy/blame/cffb095d59d7935abda12b9509bcd136808367bb/api/envoy/service/auth/v3/attribute_context.proto#L153). +Otherwise, it will be filled with UTF-8 string in the body field (https://github.com/envoyproxy/envoy/blame/cffb095d59d7935abda12b9509bcd136808367bb/api/envoy/service/auth/v3/attribute_context.proto#L147). This field only works with the envoy_ext_authz_grpc provider and has no effect for the envoy_ext_authz_http provider.
[<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “my-ext-authz.foo.svc.cluster.local” or “bar/my-ext-authz.example.com”.
string[]List of client request headers that should be included in the authorization request sent to the authorization service. -Note that in addition to the headers specified here following headers are included by default: -1. Host, Method, Path and Content-Length are automatically sent. -2. Content-Length will be set to 0 and the request will not have a message body. However, the authorization +Note that in addition to the headers specified here following headers are included by default:
+Exact, prefix and suffix matches are supported (similar to the authorization policy rule syntax except the presence match -https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule): -- Exact match: “abc” will match on value “abc”. -- Prefix match: “abc*” will match on value “abc” and “abcd”. -- Suffix match: “*abc” will match on value “abc” and “xabc”.
+https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule): +Exact, prefix and suffix matches are supported (similar to the authorization policy rule syntax except the presence match -https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule): -- Exact match: “abc” will match on value “abc”. -- Prefix match: “abc*” will match on value “abc” and “abcd”. -- Suffix match: “*abc” will match on value “abc” and “xabc”.
+https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule): +Exact, prefix and suffix matches are supported (similar to the authorization policy rule syntax except the presence match -https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule): -- Exact match: “abc” will match on value “abc”. -- Prefix match: “abc*” will match on value “abc” and “abcd”. -- Suffix match: “*abc” will match on value “abc” and “xabc”.
+https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule): +Exact, prefix and suffix matches are supported (similar to the authorization policy rule syntax except the presence match -https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule): -- Exact match: “abc” will match on value “abc”. -- Prefix match: “abc*” will match on value “abc” and “abcd”. -- Suffix match: “*abc” will match on value “abc” and “xabc”.
+https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule): +[<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “my-ext-authz.foo.svc.cluster.local” or “bar/my-ext-authz.example.com”.
[<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “zipkin.default.svc.cluster.local” or “bar/zipkin.example.com”.
@@ -1693,7 +1677,6 @@[<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “lightstep.default.svc.cluster.local” or “bar/lightstep.example.com”.
@@ -1760,7 +1743,6 @@[<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “datadog.default.svc.cluster.local” or “bar/datadog.example.com”.
@@ -1816,7 +1798,6 @@[<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “skywalking.default.svc.cluster.local” or “bar/skywalking.example.com”.
@@ -1852,7 +1833,6 @@Defines configuration for Stackdriver.
-WARNING: Stackdriver tracing uses OpenCensus configuration under the hood and, as a result, cannot be used alongside any OpenCensus provider configuration. This is due to a limitation in the implementation of OpenCensus driver in Envoy.
@@ -1896,13 +1876,11 @@Defines configuration for an OpenCensus tracer writing to an OpenCensus backend.
-WARNING: OpenCensusAgentTracingProviders should be used with extreme care. Configuration of OpenCensus providers CANNOT be changed during the course of proxy’s lifetime due to a limitation in the implementation of OpenCensus driver in Envoy. This means only a single provider configuration may be used for OpenCensus at any given time for a proxy or group of proxies AND that any change to the provider configuration MUST be accompanied by a restart of all proxies that will use that configuration.
-NOTE: Stackdriver tracing uses OpenCensus configuraiton under the hood and, as a result, cannot be used alongside OpenCensus provider configuration.
@@ -1924,7 +1902,6 @@[<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “ocagent.default.svc.cluster.local” or “bar/ocagent.example.com”.
@@ -2040,7 +2017,6 @@[<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “envoy-als.foo.svc.cluster.local” or “bar/envoy-als.example.com”.
@@ -2064,9 +2040,11 @@stringOptional. The friendly name of the access log. -Defaults: -- “http_envoy_accesslog” -- “listener_envoy_accesslog”
+Defaults: +[<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “envoy-als.foo.svc.cluster.local” or “bar/envoy-als.example.com”.
stringOptional. The friendly name of the access log. -Defaults: -- “tcp_envoy_accesslog” -- “listener_envoy_accesslog”
+Defaults: +[<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “envoy-als.foo.svc.cluster.local” or “bar/envoy-als.example.com”.
stringOptional. The friendly name of the access log. -Defaults: -- “otel_envoy_accesslog”
+Defaults: +Collection of tag names and tag expressions to include in the log entry. Conflicts are resolved by the tag name by overriding previously supplied values.
-Example: - labels: - path: request.url_path - foo: request.headers[‘x-foo’]
+labels: +path: request.url_path +foo: request.headers[‘x-foo’]Textual format for the envoy access logs. Envoy command operators may be used in the format. The format string documentation provides more information.
- -NOTE: Istio will insert a newline (‘\n’) on all formats (if missing).
- +NOTE: Istio will insert a newline (’\n’) on all formats (if missing).
Example: text: "%LOCAL_REPLY_BODY%:%RESPONSE_CODE%:path=%REQ(:path)%"
FILTER_STATE or DYNAMIC_METADATA).
Use labels: {} for default envoy JSON log format.
-
Example:
-labels:
status: "%RESPONSE_CODE%"
message: "%LOCAL_REPLY_BODY%"
@@ -2385,9 +2360,7 @@ Me
(see: format dictionaries). Nested JSON is
supported for some command operators (e.g. FILTER_STATE or DYNAMIC_METADATA).
Alias to attributes filed in Open Telemetry
-
Example:
-
labels:
status: "%RESPONSE_CODE%"
message: "%LOCAL_REPLY_BODY%"
@@ -2578,24 +2551,19 @@ ProxyConfig
ProxyConfig defines variables for individual Envoy instances. This can be configured on a per-workload basis
as well as by the mesh-wide defaults.
To set the mesh wide defaults, configure the defaultConfig section of meshConfig. For example:
-
meshConfig:
defaultConfig:
discoveryAddress: istiod:15012
-
This can also be configured on a per-workload basis by configuring the proxy.istio.io/config annotation on the pod. For example:
-
annotations:
proxy.istio.io/config: |
discoveryAddress: istiod:15012
-
If both are configured, the two are merged with per field semantics; the field set in annotation will fully replace the field from mesh config defaults.
This is different than a deep merge provided by protobuf.
For example, "tracing": { "sampling": 5 } would completely override a setting configuring a tracing provider
such as "tracing": { "zipkin": { "address": "..." } }.
-
Note: fields in ProxyConfig are not dynamically configured; changes will require restart of workloads to take effect.
@@ -2640,7 +2608,6 @@ ProxyConfig
--service-cluster flag in Envoy. In a typical Envoy deployment, the
service-cluster flag is used to identify the caller, for
source-based routing scenarios.
-
Since Istio does not assign a local service/service version to each
Envoy instance, the name is same for all of them. However, the
source/caller’s identity (e.g., IP address) is encoded in the
@@ -2947,7 +2914,6 @@
ProxyConfig
sidecar.istio.io/statsInclusionSuffixes). For example, to enable stats
for circuit breaker, retry, and upstream connections, you can specify stats
matcher as follow:
-
proxyStatsMatcher:
inclusionRegexps:
- .*circuit_breakers.*
@@ -2955,7 +2921,6 @@ ProxyConfig
- upstream_rq_retry
- upstream_cx
-
Note including more Envoy stats might increase number of time series
collected by prometheus significantly. Care needs to be taken on Prometheus
resource provision and configuration to reduce cardinality.
@@ -3341,9 +3306,7 @@ MeshNetworks
MeshNetworks (config map) provides information about the set of networks
inside a mesh and how to route to endpoints in each network. For example
-
MeshNetworks(file/config map):
-
networks:
network1:
endpoints:
@@ -3389,24 +3352,23 @@ Network.NetworkEndpoints
NetworkEndpoints describes how the network associated with an endpoint
should be inferred. An endpoint will be assigned to a network based on
the following rules:
-
-Implicitly: If the registry explicitly provides information about
+
-
+
Implicitly: If the registry explicitly provides information about
the network to which the endpoint belongs to. In some cases, its
possible to indicate the network associated with the endpoint by
-adding the ISTIO_META_NETWORK environment variable to the sidecar.
-
-Explicitly:
-
+adding the ISTIO_META_NETWORK environment variable to the sidecar.
+
+
+Explicitly:
a. By matching the registry name with one of the “fromRegistry”
- in the mesh config. A “from_registry” can only be assigned to a
- single network.
-
+in the mesh config. A “from_registry” can only be assigned to a
+single network.
b. By matching the IP against one of the CIDR ranges in a mesh
- config network. The CIDR ranges must not overlap and be assigned to
- a single network.
-
+config network. The CIDR ranges must not overlap and be assigned to
+a single network.
+
+
(2) will override (1) if both are present.
diff --git a/content/en/docs/reference/config/istio.operator.v1alpha1/index.html b/content/en/docs/reference/config/istio.operator.v1alpha1/index.html
index 65502923c5988..f1c5f2147174f 100644
--- a/content/en/docs/reference/config/istio.operator.v1alpha1/index.html
+++ b/content/en/docs/reference/config/istio.operator.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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: IstioOperator Options
description: Configuration affecting Istio control plane installation version and shape.
location: https://istio.io/docs/reference/config/istio.operator.v1alpha1.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
weight: 20
number_of_entries: 74
@@ -21,7 +21,6 @@ IstioOperatorSpec
The spec is a used to define a customization of the default profile values that are supplied with each Istio release.
Because the spec is a customization API, specifying an empty IstioOperatorSpec results in a default Istio
component values.
-
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
@@ -53,12 +52,10 @@ IstioOperatorSpec
string
Path or name for the profile e.g.
-
- minimal (looks in profiles dir for a file called minimal.yaml)
- /tmp/istio/install/values/custom/custom-install.yaml (local file path)
-
default profile is used if this field is unset.
@@ -71,7 +68,6 @@ IstioOperatorSpec
string
Path for the install package. e.g.
-
- /tmp/istio-installer/nightly (local file path)
@@ -224,7 +220,6 @@ InstallStatus
Status
Overall status of all components controlled by the operator.
-
- If all components have status
NONE, overall status is NONE.
- If all components are
HEALTHY, overall status is HEALTHY.
@@ -3770,7 +3765,6 @@ google.protobuf.Value
null, a number, a string, a boolean, a recursive struct value, or a
list of values. A producer of value is expected to set one of that
variants, absence of any variant indicates an error.
-
The JSON representation for Value is JSON value.
@@ -3872,7 +3866,7 @@ k8s.io.api.core.v1.Volume
name of the volume.
Must be a DNS_LABEL and unique within the pod.
-More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
+More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
@@ -3950,7 +3944,7 @@ k8s.io.api.core.v1.VolumeMount
string
Path within the volume from which the container’s volume should be mounted.
-Defaults to “” (volume’s root).
+Defaults to "" (volume’s root).
+optional
@@ -3979,7 +3973,7 @@ k8s.io.api.core.v1.VolumeMount
Expanded path within the volume from which the container’s volume should be mounted.
Behaves similarly to SubPath but environment variable references $(VAR_NAME) are expanded using the container’s environment.
-Defaults to “” (volume’s root).
+Defaults to "" (volume’s root).
SubPathExpr and SubPath are mutually exclusive.
+optional
diff --git a/content/en/docs/reference/config/labels/index.html b/content/en/docs/reference/config/labels/index.html
index 2bf14acebd388..f23adff55a40e 100644
--- a/content/en/docs/reference/config/labels/index.html
+++ b/content/en/docs/reference/config/labels/index.html
@@ -1,6 +1,6 @@
---
-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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Resource Labels
description: Resource labels used by Istio.
location: https://istio.io/docs/reference/config/labels/
diff --git a/content/en/docs/reference/config/meta/v1beta1/istio-status/index.html b/content/en/docs/reference/config/meta/v1beta1/istio-status/index.html
index 84ddda9a154e9..26571416221c2 100644
--- a/content/en/docs/reference/config/meta/v1beta1/istio-status/index.html
+++ b/content/en/docs/reference/config/meta/v1beta1/istio-status/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Istio Status
description: Common status field for all istio collections.
location: https://istio.io/docs/reference/config/meta/v1beta1/istio-status.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
number_of_entries: 2
---
@@ -25,7 +25,7 @@ IstioStatus
IstioCondition[]
Current service state of pod.
-More info: https://istio.io/docs/reference/config/config-status/
+More info: https://istio.io/docs/reference/config/config-status/
+optional
+patchMergeKey=type
+patchStrategy=merge
@@ -55,7 +55,7 @@ IstioStatus
Resource Generation to which the Reconciled Condition refers.
When this value is not equal to the object’s metadata generation, reconciled condition calculation for the current
-generation is still in progress. See https://istio.io/latest/docs/reference/config/config-status/ for more info.
+generation is still in progress. See https://istio.io/latest/docs/reference/config/config-status/ for more info.
+optional
diff --git a/content/en/docs/reference/config/networking/destination-rule/index.html b/content/en/docs/reference/config/networking/destination-rule/index.html
index 1cd74cc056b48..fbd76d8218180 100644
--- a/content/en/docs/reference/config/networking/destination-rule/index.html
+++ b/content/en/docs/reference/config/networking/destination-rule/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Destination Rule
description: Configuration affecting load balancing, outlier detection, etc.
location: https://istio.io/docs/reference/config/networking/destination-rule.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.DestinationRule
aliases: [/docs/reference/config/networking/v1alpha3/destination-rule]
@@ -16,10 +16,8 @@
detection settings to detect and evict unhealthy hosts from the load
balancing pool. For example, a simple load balancing policy for the
ratings service would look as follows:
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -30,11 +28,8 @@
loadBalancer:
simple: LEAST_REQUEST
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -45,19 +40,15 @@
loadBalancer:
simple: LEAST_REQUEST
-
{{}}
{{}}
-
Version specific policies can be specified by defining a named
subset and overriding the settings specified at the service level. The
following rule uses a round robin load balancing policy for all traffic
going to a subset named testversion that is composed of endpoints (e.g.,
pods) with labels (version:v3).
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -75,11 +66,8 @@
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -97,21 +85,16 @@
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
{{}}
-
Note: Policies specified for subsets will not take effect until
a route rule explicitly sends traffic to this subset.
-
Traffic policies can be customized to specific ports as well. The
following rule uses the least connection load balancing policy for all
traffic to port 80, while uses a round robin load balancing setting for
traffic to the port 9080.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -129,11 +112,8 @@
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -151,17 +131,13 @@
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
{{}}
-
Destination Rules can be customized to specific workloads as well.
The following example shows how a destination rule can be applied to a
specific workload using the workloadSelector configuration.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -181,10 +157,8 @@
credentialName: client-credential
mode: MUTUAL
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -204,7 +178,6 @@
credentialName: client-credential
mode: MUTUAL
-
{{}}
{{}}
@@ -232,7 +205,6 @@ DestinationRule
Kubernetes services, Consul services, etc.) and from the hosts
declared by ServiceEntries. Rules defined for
services that do not exist in the service registry will be ignored.
-
Note for Kubernetes users: When short names are used (e.g. “reviews”
instead of “reviews.default.svc.cluster.local”), Istio will interpret
the short name based on the namespace of the rule, not the service. A
@@ -241,7 +213,6 @@
DestinationRule
the actual namespace associated with the reviews service. To avoid
potential misconfigurations, it is recommended to always use fully
qualified domain names over short names.
-
Note that the host field applies to both HTTP and TCP services.
@@ -284,10 +255,8 @@ DestinationRule
other namespaces. This feature provides a mechanism for service owners
and mesh administrators to control the visibility of destination rules
across namespace boundaries.
-
If no namespaces are specified then the destination rule is exported to all
namespaces by default.
-
The value “.” is reserved and defines an export to the same namespace that
the destination rule is declared in. Similarly, the value “*” is reserved and
defines an export to all namespaces.
@@ -302,13 +271,13 @@ DestinationRule
WorkloadSelector
Criteria used to select the specific set of pods/VMs on which this
- DestinationRule configuration should be applied. If specified, the DestinationRule
- configuration will be applied only to the workload instances matching the workload selector
- label in the same namespace. Workload selectors do not apply across namespace boundaries.
- If omitted, the DestinationRule falls back to its default behavior.
- For example, if specific sidecars need to have egress TLS settings for services outside
- of the mesh, instead of every sidecar in the mesh needing to have the
- configuration (which is the default behaviour), a workload selector can be specified.
+DestinationRule configuration should be applied. If specified, the DestinationRule
+configuration will be applied only to the workload instances matching the workload selector
+label in the same namespace. Workload selectors do not apply across namespace boundaries.
+If omitted, the DestinationRule falls back to its default behavior.
+For example, if specific sidecars need to have egress TLS settings for services outside
+of the mesh, instead of every sidecar in the mesh needing to have the
+configuration (which is the default behaviour), a workload selector can be specified.
@@ -418,10 +387,8 @@ Subset
uses a round robin load balancing policy for all traffic going to a
subset named testversion that is composed of endpoints (e.g., pods) with
labels (version:v3).
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -439,11 +406,8 @@ Subset
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -461,13 +425,10 @@ Subset
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
{{}}
-
Note: Policies specified for subsets will not take effect until
a route rule explicitly sends traffic to this subset.
-
One or more labels are typically required to identify the subset destination,
however, when the corresponding DestinationRule represents a host that
supports multiple SNI hosts (e.g., an egress gateway), a subset without labels
@@ -531,13 +492,10 @@
LoadBalancerSettings
load balancing
documentation
for more details.
-
For example, the following rule uses a round robin load balancing policy
for all traffic going to the ratings service.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -548,11 +506,8 @@ LoadBalancerSettings
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -563,17 +518,13 @@ LoadBalancerSettings
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
{{}}
-
The following example sets up sticky sessions for the ratings service
hashing-based load balancer for the same ratings service using the
the User cookie as the hash key.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -587,11 +538,8 @@ LoadBalancerSettings
name: user
ttl: 0s
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -605,7 +553,6 @@ LoadBalancerSettings
name: user
ttl: 0s
-
{{}}
{{}}
@@ -674,13 +621,10 @@ ConnectionPoolSettings
breaker
for more details. Connection pool settings can be applied at the TCP
level as well as at HTTP level.
-
For example, the following rule sets a limit of 100 connections to redis
service called myredissrv with a connect timeout of 30ms
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -696,11 +640,8 @@ ConnectionPoolSettings
time: 7200s
interval: 75s
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -716,7 +657,6 @@ ConnectionPoolSettings
time: 7200s
interval: 75s
-
{{}}
{{}}
@@ -766,16 +706,13 @@ OutlierDetection
consecutive errors metric. See Envoy’s outlier
detection
for more details.
-
The following rule sets a connection pool size of 100 HTTP1 connections
with no more than 10 req/connection to the “reviews” service. In addition,
it sets a limit of 1000 concurrent HTTP2 requests and configures upstream
hosts to be scanned every 5 mins so that any host that fails 7 consecutive
times with a 502, 503, or 504 error code will be ejected for 15 minutes.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -794,11 +731,8 @@ OutlierDetection
interval: 5m
baseEjectionTime: 15m
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -817,7 +751,6 @@ OutlierDetection
interval: 5m
baseEjectionTime: 15m
-
{{}}
{{}}
@@ -872,7 +805,6 @@ OutlierDetection
an opaque TCP connection, connect timeouts and connection error/failure
events qualify as a gateway error.
This feature is disabled by default or when set to the value 0.
-
Note that consecutive_gateway_errors and consecutive_5xx_errors can be
used separately or together. Because the errors counted by
consecutive_gateway_errors are also included in consecutive_5xx_errors,
@@ -894,7 +826,6 @@
OutlierDetection
timeouts, connection error/failure and request failure events qualify as a
5xx error.
This feature defaults to 5 but can be disabled by setting the value to 0.
-
Note that consecutive_gateway_errors and consecutive_5xx_errors can be
used separately or together. Because the errors counted by
consecutive_gateway_errors are also included in consecutive_5xx_errors,
@@ -971,13 +902,10 @@
ClientTLSSettings
SSL/TLS related settings for upstream connections. See Envoy’s TLS
context
for more details. These settings are common to both HTTP and TCP upstreams.
-
For example, the following rule configures a client to use mutual TLS
for connections to upstream database cluster.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -991,11 +919,8 @@ ClientTLSSettings
privateKey: /etc/certs/client_private_key.pem
caCertificates: /etc/certs/rootcacerts.pem
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -1009,16 +934,12 @@ ClientTLSSettings
privateKey: /etc/certs/client_private_key.pem
caCertificates: /etc/certs/rootcacerts.pem
-
{{}}
{{}}
-
The following rule configures a client to use TLS when talking to a
foreign service whose domain matches *.foo.com.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -1029,11 +950,8 @@ ClientTLSSettings
tls:
mode: SIMPLE
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -1044,16 +962,12 @@ ClientTLSSettings
tls:
mode: SIMPLE
-
{{}}
{{}}
-
The following rule configures a client to use Istio mutual TLS when talking
to rating services.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -1064,11 +978,8 @@ ClientTLSSettings
tls:
mode: ISTIO_MUTUAL
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -1079,7 +990,6 @@ ClientTLSSettings
tls:
mode: ISTIO_MUTUAL
-
{{}}
{{}}
@@ -1160,7 +1070,6 @@ ClientTLSSettings
ca.crt key for CA certificates is also supported.
Only one of client certificates and CA certificate
or credentialName can be specified.
-
NOTE: This field is applicable at sidecars only if
DestinationRule has a workloadSelector specified.
Otherwise the field will be applicable only at gateways, and
@@ -1214,7 +1123,6 @@
ClientTLSSettings
but no verification is desired for a specific host. If enabled with or
without VerifyCertAtClient enabled, verification of the CA signature and
SAN will be skipped.
-
InsecureSkipVerify is false by default.
VerifyCertAtClient is false by default in Istio version 1.9 but will
be true by default in a later version where, going forward, it will be
@@ -1237,7 +1145,6 @@
LocalityLoadBalancerSetting
{region}/{zone}/{sub-zone} form. For additional detail refer to
Locality Weight
The following example shows how to setup locality weights mesh-wide.
-
Given a mesh with workloads and their service deployed to “us-west/zone1/”
and “us-west/zone2/”. This example specifies that when traffic accessing a
service originates from workloads in “us-west/zone1/”, 80% of the traffic
@@ -1245,7 +1152,6 @@ LocalityLoadBalancerSetting
remaining 20% will go to endpoints in “us-west/zone2/”. This setup is
intended to favor routing traffic to endpoints in the same locality.
A similar setting is specified for traffic originating in “us-west/zone2/”.
-
distribute:
- from: us-west/zone1/*
to:
@@ -1256,25 +1162,21 @@ LocalityLoadBalancerSetting
"us-west/zone1/*": 20
"us-west/zone2/*": 80
-
If the goal of the operator is not to distribute load across zones and
regions but rather to restrict the regionality of failover to meet other
operational requirements an operator can set a ‘failover’ policy instead of
a ‘distribute’ policy.
-
The following example sets up a locality failover policy for regions.
Assume a service resides in zones within us-east, us-west & eu-west
this example specifies that when endpoints within us-east become unhealthy
traffic should failover to endpoints in any zone or sub-zone within eu-west
and similarly us-west should failover to us-east.
-
failover:
- from: us-east
to: eu-west
- from: us-west
to: us-east
-
Locality load balancing settings.
@@ -1322,19 +1224,15 @@ LocalityLoadBalancerSetting
failoverPriority is an ordered list of labels used to sort endpoints to do priority based load balancing.
This is to support traffic failover across different groups of endpoints.
Suppose there are total N labels specified:
-
- Endpoints matching all N labels with the client proxy have priority P(0) i.e. the highest priority.
- Endpoints matching the first N-1 labels with the client proxy have priority P(1) i.e. second highest priority.
- By extension of this logic, endpoints matching only the first label with the client proxy has priority P(N-1) i.e. second lowest priority.
- All the other endpoints have priority P(N) i.e. lowest priority.
-
Note: For a label to be considered for match, the previous labels must match, i.e. nth label would be considered matched only if first n-1 labels match.
-
It can be any label specified on both client and server workloads.
The following labels which have special semantic meaning are also supported:
-
topology.istio.io/network is used to match the network metadata of an endpoint, which can be specified by pod/namespace label topology.istio.io/network, sidecar env ISTIO_META_NETWORK or MeshNetworks.topology.istio.io/cluster is used to match the clusterID of an endpoint, which can be specified by pod label topology.istio.io/cluster or pod env ISTIO_META_CLUSTER_ID.LocalityLoadBalancerSetting
topology.kubernetes.io/zone is used to match the zone metadata of an endpoint, which maps to Kubernetes node label topology.kubernetes.io/zone or the deprecated label failure-domain.beta.kubernetes.io/zone.topology.istio.io/subzone is used to match the subzone metadata of an endpoint, which maps to Istio node label topology.istio.io/subzone.
-
The below topology config indicates the following priority levels:
-
failoverPriority:
- "topology.istio.io/network"
- "topology.kubernetes.io/region"
- "topology.kubernetes.io/zone"
- "topology.istio.io/subzone"
-
- endpoints match same [network, region, zone, subzone] label with the client proxy have the highest priority.
- endpoints have same [network, region, zone] label but different [subzone] label with the client proxy have the second highest priority.
@@ -1359,7 +1254,6 @@ LocalityLoadBalancerSetting
- endpoints have same [network] but different [region] labels with the client proxy have the fourth highest priority.
- all the other endpoints have the same lowest priority.
-
Optional: only one of distribute, failover or failoverPriority can be set.
And it should be used together with OutlierDetection to detect unhealthy endpoints, otherwise has no effect.
@@ -1474,8 +1368,8 @@ TrafficPolicy.TunnelSettings
Specifies which protocol to use for tunneling the downstream connection.
Supported protocols are:
- CONNECT - uses HTTP CONNECT;
- POST - uses HTTP POST.
+CONNECT - uses HTTP CONNECT;
+POST - uses HTTP POST.
CONNECT is used by default if not specified.
HTTP version for upstream requests is determined by the service protocol defined for the proxy.
@@ -1803,7 +1697,7 @@ ConnectionPoolSettings.HTTPSettings
Maximum number of requests that will be queued while waiting for
a ready connection pool connection. Default 1024.
-Refer to https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/circuit_breaking
+Refer to https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/circuit_breaking
under which conditions a new connection is created for HTTP2.
Please note that this is applicable to both HTTP/1.1 and HTTP2.
@@ -1952,14 +1846,11 @@ ConnectionPoolSettings.
LocalityLoadBalancerSetting.Distribute
Describes how traffic originating in the ‘from’ zone or sub-zone is
-distributed over a set of ‘to’ zones. Syntax for specifying a zone is
+distributed over a set of ’to’ zones. Syntax for specifying a zone is
{region}/{zone}/{sub-zone} and terminal wildcards are allowed on any
segment of the specification. Examples:
-
* - matches all localities
-
us-west/* - all zones and sub-zones within the us-west region
-
us-west/zone-1/* - all sub-zones within us-west/zone-1
@@ -2048,7 +1939,6 @@ LocalityLoadBalancerSetting.Failov
google.protobuf.UInt32Value
Wrapper message for uint32.
-
The JSON representation for UInt32Value is JSON number.
diff --git a/content/en/docs/reference/config/networking/envoy-filter/index.html b/content/en/docs/reference/config/networking/envoy-filter/index.html
index d3233aa08a7be..8702b50a32691 100644
--- a/content/en/docs/reference/config/networking/envoy-filter/index.html
+++ b/content/en/docs/reference/config/networking/envoy-filter/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Envoy Filter
description: Customizing Envoy configuration generated by Istio.
location: https://istio.io/docs/reference/config/networking/envoy-filter.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.EnvoyFilter
aliases: [/docs/reference/config/networking/v1alpha3/envoy-filter]
@@ -22,7 +22,6 @@
in the config root
namespace,
followed by all matching EnvoyFilters in the workload’s namespace.
-
NOTE 1: Some aspects of this API are deeply tied to the internal
implementation in Istio networking subsystem as well as Envoy’s XDS
API. While the EnvoyFilter API by itself will maintain backward
@@ -30,25 +29,21 @@
mechanism should be carefully monitored across Istio proxy version
upgrades, to ensure that deprecated fields are removed and replaced
appropriately.
-
NOTE 2: When multiple EnvoyFilters are bound to the same
workload in a given namespace, all patches will be processed
sequentially in order of creation time. The behavior is undefined
if multiple EnvoyFilter configurations conflict with each other.
-
NOTE 3: To apply an EnvoyFilter resource to all workloads
(sidecars and gateways) in the system, define the resource in the
config root
namespace,
without a workloadSelector.
-
The example below declares a global default EnvoyFilter resource in
the root namespace called istio-config, that adds a custom
protocol filter on all sidecars in the system, for outbound port
9307. The filter should be added before the terminating tcp_proxy
filter to take effect. In addition, it sets a 30s idle timeout for
all HTTP connections in both gateways and sidecars.
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -88,14 +83,12 @@
common_http_protocol_options:
idle_timeout: 30s
-
The following example enables Envoy’s Lua filter for all inbound
HTTP calls arriving at service port 8080 of the reviews service pod
with labels “app: reviews”, in the bookinfo namespace. The lua
filter calls out to an external service internal.org.net:8888 that
requires a special cluster definition in envoy. The cluster is also
added to the sidecar as part of this configuration.
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -159,12 +152,10 @@
address: "internal.org.net"
port_value: 8888
-
The following example overwrites certain fields (HTTP idle timeout
and X-Forward-For trusted hops) in the HTTP connection manager in a
listener on the ingress gateway in istio-system namespace for the
SNI host app.example.com:
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -192,11 +183,9 @@
common_http_protocol_options:
idle_timeout: 30s
-
The following example inserts an attributegen filter
that produces istio_operationId attribute which is consumed
by the istio.stats filter. filterClass: STATS encodes this dependency.
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -237,9 +226,7 @@
code:
local: { inline_string: "envoy.wasm.attributegen" }
-
The following example inserts an http ext_authz filter in the myns namespace.
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -264,12 +251,10 @@
- key: foo
value: myauth.acme # required by local ext auth server.
-
A workload in the myns namespace needs to access a different ext_auth server
that does not accept initial metadata. Since proto merge cannot remove fields, the
following configuration uses the REPLACE operation. If you do not need to inherit
fields, REPLACE is preferred over MERGE.
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -293,9 +278,7 @@
envoy_grpc:
cluster_name: acme-ext-authz-alt
-
The following example deploys a Wasm extension for all inbound sidecar HTTP requests.
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -348,12 +331,10 @@
ads: {}
type_urls: ["type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm"]
-
The following example adds a Wasm service extension for all proxies using a locally available Wasm file.
The singleton Wasm extension is used to maintain a shared state between workers executing Wasm filters.
For example, a local rate limit extension would rely on a singleton to limit requests across all workers.
As another example, an authorization Wasm extension can use a singleton to maintain a database of accounts.
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -437,14 +418,11 @@ EnvoyFilter
Patch sets in the root namespace are applied before the patch sets in the
workload namespace. Patches within a patch set are processed in the order
that they appear in the configPatches list.
-
The default value for priority is 0 and the range is [ min-int32, max-int32 ].
A patch set with a negative priority is processed before the default. A patch
set with a positive priority is processed after the default.
-
It is recommended to start with priority values that are multiples of 10
to leave room for further insertion.
-
Patch sets are sorted in the following ascending key order:
priority, creation time, fully qualified resource name.
@@ -1041,9 +1019,7 @@ EnvoyFilter.ListenerMatch.Fi
chain match. This value will be compared against the
transport protocol of a new connection, when it’s detected by
the tls_inspector listener filter.
-
Accepted values include:
-
raw_buffer - default, used when no transport protocol is detected.tls - set when TLS protocol is detected by the TLS inspector.EnvoyFilter.ListenerMatch.Fi
filter chain match. This value will be compared against the
application protocols of a new connection, when it’s detected
by one of the listener filters such as the http_inspector.
-
Accepted values include: h2, http/1.1, http/1.0
diff --git a/content/en/docs/reference/config/networking/gateway/index.html b/content/en/docs/reference/config/networking/gateway/index.html
index 1e6bb5f1e47f3..658f0c5b6e271 100644
--- a/content/en/docs/reference/config/networking/gateway/index.html
+++ b/content/en/docs/reference/config/networking/gateway/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Gateway
description: Configuration affecting edge load balancer.
location: https://istio.io/docs/reference/config/networking/gateway.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.Gateway
aliases: [/docs/reference/config/networking/v1alpha3/gateway]
@@ -14,18 +14,14 @@
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.
-
For example, the following Gateway configuration sets up a proxy to act
as a load balancer exposing port 80 and 9080 (http), 443 (https),
9443(https) and port 2379 (TCP) for ingress. The gateway will be
-applied to the proxy running on a pod with labels app:
-my-gateway-controller. While Istio will configure the proxy to listen
+applied to the proxy running on a pod with labels app: my-gateway-controller. 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.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@@ -77,11 +73,8 @@
hosts:
- "*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
@@ -133,14 +126,11 @@
hosts:
- "*"
-
{{}}
{{}}
-
The Gateway specification above describes the L4-L6 properties of a load
balancer. A VirtualService can then be bound to a gateway to control
the forwarding of traffic arriving at a particular host or gateway port.
-
For example, the following VirtualService splits traffic for
https://uk.bookinfo.com/reviews, https://eu.bookinfo.com/reviews,
http://uk.bookinfo.com:9080/reviews,
@@ -151,10 +141,8 @@
requests to the “reviews.prod.svc.cluster.local” service. This rule is
applicable across ports 443, 9080. Note that http://uk.bookinfo.com
gets redirected to https://uk.bookinfo.com (i.e. 80 redirects to 443).
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -191,11 +179,8 @@
host: reviews.qa.svc.cluster.local
weight: 20
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -232,18 +217,14 @@
host: reviews.qa.svc.cluster.local
weight: 20
-
{{}}
{{}}
-
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 mesh.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -263,11 +244,8 @@
port:
number: 5555
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -287,19 +265,15 @@
port:
number: 5555
-
{{}}
{{}}
-
It is possible to restrict the set of virtual services that can bind to
a gateway server using the namespace/hostname syntax in the hosts field.
For example, the following Gateway allows any virtual service in the ns1
namespace to bind to it, while restricting only the virtual service with
foo.bar.com host in the ns2 namespace to bind to it.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@@ -317,11 +291,8 @@
- "ns1/*"
- "ns2/foo.bar.com"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
@@ -339,7 +310,6 @@
- "ns1/*"
- "ns2/foo.bar.com"
-
{{}}
{{}}
@@ -398,10 +368,8 @@ Server
Server describes the properties of the proxy on a given load balancer
port. For example,
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@@ -417,11 +385,8 @@ Server
hosts:
- "*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
@@ -437,15 +402,11 @@ Server
hosts:
- "*"
-
{{}}
{{}}
-
Another example
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@@ -461,11 +422,8 @@ Server
hosts:
- "*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
@@ -481,15 +439,11 @@ Server
hosts:
- "*"
-
{{}}
{{}}
-
The following is an example of TLS configuration for port 443
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@@ -508,11 +462,8 @@ Server
mode: SIMPLE
credentialName: tls-cert
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
@@ -531,7 +482,6 @@ Server
mode: SIMPLE
credentialName: tls-cert
-
{{}}
{{}}
@@ -587,14 +537,12 @@ Server
a wildcard character in the left-most component (e.g., prod/*.example.com).
Set the dnsName to * to select all VirtualService hosts from the
specified namespace (e.g.,prod/*).
-
The namespace can be set to * or ., representing any or the current
namespace, respectively. For example, */foo.example.com selects the
service from any available namespace while ./foo.example.com only selects
the service from the namespace of the sidecar. The default, if no namespace/
is specified, is */, that is, select services from any namespace.
Any associated DestinationRule in the selected namespace will also be used.
-
A VirtualService must be bound to the gateway and 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’s hosts. For
@@ -602,7 +550,6 @@
Server
VirtualService with hosts dev.example.com or prod.example.com will
match. However, a VirtualService with host example.com or
newexample.com will not match.
-
NOTE: Only virtual services exported to the gateway’s namespace
(e.g., exportTo value of *) can be referenced.
Private configurations (e.g., exportTo set to .) will not be
@@ -789,8 +736,7 @@
ServerTLSSettings
For gateways running on Kubernetes, the name of the secret that
holds the TLS certs including the CA certificates. Applicable
only on Kubernetes. The secret (of type generic) should
-contain the following keys and values: key:
-<privateKey> and cert: <serverCert>. For mutual TLS,
+contain the following keys and values: key: <privateKey> and cert: <serverCert>. For mutual TLS,
cacert: <CACertificate> can be provided in the same secret or
a separate secret named <secret>-cacert.
Secret of type tls for server certificates along with
diff --git a/content/en/docs/reference/config/networking/proxy-config/index.html b/content/en/docs/reference/config/networking/proxy-config/index.html
index 1fa1ec799ca63..fb934b2343c19 100644
--- a/content/en/docs/reference/config/networking/proxy-config/index.html
+++ b/content/en/docs/reference/config/networking/proxy-config/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: ProxyConfig
description: Provides configuration for individual workloads.
location: https://istio.io/docs/reference/config/networking/proxy-config.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1beta1.ProxyConfig
aliases: [/docs/reference/config/networking/v1beta1/proxy-config]
@@ -13,18 +13,13 @@
ProxyConfig exposes proxy level configuration options. ProxyConfig can be configured on a per-workload basis,
a per-namespace basis, or mesh-wide. ProxyConfig is not a required resource; there are default values in place, which are documented
inline with each field.
-
NOTE: fields in ProxyConfig are not dynamically configured - changes will require restart of workloads to take effect.
-
For any namespace, including the root configuration namespace, it is only valid
to have a single workload selector-less ProxyConfig resource.
-
For resources with a workload selector, it is only valid to have one resource selecting
any given workload.
-
For mesh level configuration, put the resource in the root configuration namespace for
your Istio installation without a workload selector:
-
apiVersion: networking.istio.io/v1beta1
kind: ProxyConfig
metadata:
@@ -35,9 +30,7 @@
image:
imageType: distroless
-
For namespace level configuration, put the resource in the desired namespace without a workload selector:
-
apiVersion: networking.istio.io/v1beta1
kind: ProxyConfig
metadata:
@@ -46,9 +39,7 @@
spec:
concurrency: 0
-
For workload level configuration, set the selector field on the ProxyConfig resource:
-
apiVersion: networking.istio.io/v1beta1
kind: ProxyConfig
metadata:
@@ -62,7 +53,6 @@
image:
imageType: debug
-
If a ProxyConfig CR is defined that matches a workload it will merge with its proxy.istio.io/config annotation if present,
with the CR taking precedence over the annotation for overlapping fields. Similarly, if a mesh wide ProxyConfig CR is defined and
meshConfig.DefaultConfig is set, the two resources will be merged with the CR taking precedence for overlapping fields.
diff --git a/content/en/docs/reference/config/networking/service-entry/index.html b/content/en/docs/reference/config/networking/service-entry/index.html
index ba591ec4ca918..47838f01e29a7 100644
--- a/content/en/docs/reference/config/networking/service-entry/index.html
+++ b/content/en/docs/reference/config/networking/service-entry/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Service Entry
description: Configuration affecting service registry.
location: https://istio.io/docs/reference/config/networking/service-entry.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.ServiceEntry
aliases: [/docs/reference/config/networking/v1alpha3/service-entry]
@@ -25,14 +25,11 @@
service allows for migration of services from VMs to Kubernetes
without having to change the existing DNS names associated with the
services.
-
The following example declares a few external APIs accessed by internal
applications over HTTPS. The sidecar inspects the SNI value in the
ClientHello message to route to the appropriate external service.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -49,11 +46,8 @@
protocol: TLS
resolution: DNS
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -70,18 +64,14 @@
protocol: TLS
resolution: DNS
-
{{}}
{{}}
-
The following configuration adds a set of MongoDB instances running on
unmanaged VMs to Istio’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.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -101,11 +91,8 @@
- address: 2.2.2.2
- address: 3.3.3.3
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -125,15 +112,11 @@
- address: 2.2.2.2
- address: 3.3.3.3
-
{{}}
{{}}
-
and the associated DestinationRule
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -147,11 +130,8 @@
privateKey: /etc/certs/client_private_key.pem
caCertificates: /etc/certs/rootcacerts.pem
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -165,17 +145,13 @@
privateKey: /etc/certs/client_private_key.pem
caCertificates: /etc/certs/rootcacerts.pem
-
{{}}
{{}}
-
The following example uses a combination of service entry and TLS
routing in a virtual service to steer traffic based on the SNI value to
an internal egress firewall.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -191,11 +167,8 @@
protocol: TLS
resolution: NONE
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -211,15 +184,11 @@
protocol: TLS
resolution: NONE
-
{{}}
{{}}
-
And the associated VirtualService to route based on the SNI value.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -237,11 +206,8 @@
- destination:
host: internal-egress-firewall.ns1.svc.cluster.local
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -259,25 +225,20 @@
- destination:
host: internal-egress-firewall.ns1.svc.cluster.local
-
{{}}
{{}}
-
The virtual service with TLS match serves to override the default SNI
match. In the absence of a virtual service, traffic will be forwarded to
the wikipedia domains.
-
The following example demonstrates the use of a dedicated egress gateway
through which all external service traffic is forwarded.
-The ‘exportTo’ field allows for control over the visibility of a service
+The ’exportTo’ 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 “.”, so that it cannot be used by other
namespaces.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -295,11 +256,8 @@
protocol: HTTP
resolution: DNS
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -317,15 +275,11 @@
protocol: HTTP
resolution: DNS
-
{{}}
{{}}
-
Define a gateway to handle all egress traffic.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@@ -342,11 +296,8 @@
hosts:
- "*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
@@ -363,20 +314,16 @@
hosts:
- "*"
-
{{}}
{{}}
-
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.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -406,11 +353,8 @@
- destination:
host: example.com
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -440,18 +384,14 @@
- destination:
host: example.com
-
{{}}
{{}}
-
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 NONE.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -466,11 +406,8 @@
protocol: HTTP
resolution: NONE
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -485,17 +422,13 @@
protocol: HTTP
resolution: NONE
-
{{}}
{{}}
-
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.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -512,11 +445,8 @@
endpoints:
- address: unix:///var/run/example/socket
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -533,10 +463,8 @@
endpoints:
- address: unix:///var/run/example/socket
-
{{}}
{{}}
-
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
@@ -544,10 +472,8 @@
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
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -572,11 +498,8 @@
ports:
http: 7080
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -601,22 +524,17 @@
ports:
http: 7080
-
{{}}
{{}}
-
With HTTP_PROXY=http://localhost/, calls from the application to
http://foo.bar.com will be load balanced across the three domains
specified above. In other words, a call to http://foo.bar.com/baz would
be translated to http://uk.foo.bar.com/baz.
-
The following example illustrates the usage of a ServiceEntry
containing a subject alternate name
whose format conforms to the SPIFFE standard:
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -637,11 +555,8 @@
subjectAltNames:
- "spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -662,10 +577,8 @@
subjectAltNames:
- "spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account"
-
{{}}
{{}}
-
The following example demonstrates the use of ServiceEntry with a
workloadSelector to handle the migration of a service
details.bookinfo.com from VMs to Kubernetes. The service has two
@@ -677,10 +590,8 @@
details-legacy service account. The sidecar receives HTTP traffic
on port 80 (wrapped in istio mutual TLS) and forwards it to the
application on the localhost on the same port.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
@@ -703,11 +614,8 @@
app: details
instance-id: vm2
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: WorkloadEntry
metadata:
@@ -730,18 +638,14 @@
app: details
instance-id: vm2
-
{{}}
{{}}
-
Assuming there is also a Kubernetes deployment with pod labels
app: details using the same service account details, the
following service entry declares a service spanning both VMs and
Kubernetes:
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -759,11 +663,8 @@
labels:
app: details
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -781,7 +682,6 @@
labels:
app: details
-
{{}}
{{}}
@@ -806,18 +706,15 @@ ServiceEntry
The hosts associated with the ServiceEntry. Could be a DNS
name with wildcard prefix.
-
- The hosts field is used to select matching hosts in VirtualServices and DestinationRules.
- For HTTP traffic the HTTP Host/Authority header will be matched against the hosts field.
- For HTTPs or TLS traffic containing Server Name Indication (SNI), the SNI value
will be matched against the hosts field.
-
NOTE 1: When resolution is set to type DNS and no endpoints
are specified, the host field will be used as the DNS name of the
endpoint to route traffic to.
-
NOTE 2: If the hostname matches with the name of a service
from another service registry such as Kubernetes that also
supplies its own set of endpoints, the ServiceEntry will be
@@ -825,7 +722,6 @@
ServiceEntry
service. Properties in the service entry will be added to the
Kubernetes service if applicable. Currently, the only the
following additional properties will be considered by istiod:
-
- subjectAltNames: In addition to verifying the SANs of the
service accounts associated with the pods of the service, the
@@ -937,14 +833,11 @@
ServiceEntry
other namespaces. This feature provides a mechanism for service owners
and mesh administrators to control the visibility of services across
namespace boundaries.
-
If no namespaces are specified then the service is exported to all
namespaces by default.
-
The value “.” is reserved and defines an export to the same namespace that
the service is declared in. Similarly the value “*” is reserved and
defines an export to all namespaces.
-
For a Kubernetes Service, the equivalent effect can be achieved by setting
the annotation “networking.istio.io/exportTo” to a comma-separated list
of namespace names.
@@ -960,7 +853,6 @@ ServiceEntry
If specified, the proxy will verify that the server certificate’s
subject alternate name matches one of the specified values.
-
NOTE: When using the workloadEntry with workloadSelectors, the
service account specified in the workloadEntry will also be used
to derive the additional subject alternate names that should be
diff --git a/content/en/docs/reference/config/networking/sidecar/index.html b/content/en/docs/reference/config/networking/sidecar/index.html
index 7e0bc14945ff0..c7d665925616e 100644
--- a/content/en/docs/reference/config/networking/sidecar/index.html
+++ b/content/en/docs/reference/config/networking/sidecar/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Sidecar
description: Configuration affecting network reachability of a sidecar.
location: https://istio.io/docs/reference/config/networking/sidecar.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.Sidecar
aliases: [/docs/reference/config/networking/v1alpha3/sidecar]
@@ -20,7 +20,6 @@
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 workload instances.
-
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
configuration in a namespace will apply to one or more workload instances in the same
@@ -30,7 +29,6 @@
workload instance, preference will be given to the resource with a
workloadSelector that selects this workload instance, over a Sidecar configuration
without any workloadSelector.
-
NOTE 1: Each namespace can have only one Sidecar
configuration without any workloadSelector that specifies the
default for all pods in that namespace. It is recommended to use
@@ -39,22 +37,18 @@
configurations exist in a given namespace. The behavior of the
system is undefined if two or more Sidecar configurations with a
workloadSelector select the same workload instance.
-
NOTE 2: A Sidecar configuration in the MeshConfig
root namespace
will be applied by default to all namespaces without a Sidecar
configuration. This global default Sidecar configuration should not have
any workloadSelector.
-
The example below declares a global default Sidecar configuration
in the root namespace called istio-config, that configures
sidecars in all namespaces to allow egress traffic only to other
workloads in the same namespace as well as to services in the
istio-system namespace.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
@@ -66,11 +60,8 @@
- "./*"
- "istio-system/*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
@@ -82,19 +73,15 @@
- "./*"
- "istio-system/*"
-
{{}}
{{}}
-
The example below declares a Sidecar configuration in the
prod-us1 namespace that overrides the global default defined
above, and configures the sidecars in the namespace to allow egress
traffic to public services in the prod-us1, prod-apis, and the
istio-system namespaces.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
@@ -107,11 +94,8 @@
- "prod-apis/*"
- "istio-system/*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
@@ -124,10 +108,8 @@
- "prod-apis/*"
- "istio-system/*"
-
{{}}
{{}}
-
The following example declares a Sidecar configuration in the
prod-us1 namespace for all pods with labels app: ratings
belonging to the ratings.prod-us1 service. The workload accepts
@@ -136,10 +118,8 @@
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.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
@@ -165,11 +145,8 @@
- hosts:
- "istio-system/*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
@@ -195,10 +172,8 @@
- hosts:
- "istio-system/*"
-
{{}}
{{}}
-
If the workload is deployed without IPTables-based traffic capture,
the Sidecar configuration is the only way to configure the ports
on the proxy attached to the workload instance. The following
@@ -213,10 +188,8 @@
the application to communicate with a backing MySQL database on
127.0.0.1:3306, that then gets proxied to the externally hosted
MySQL service at mysql.foo.com:3306.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
@@ -243,11 +216,8 @@
hosts:
- "*/mysql.foo.com"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
@@ -274,15 +244,11 @@
hosts:
- "*/mysql.foo.com"
-
{{}}
{{}}
-
And the associated service entry for routing to mysql.foo.com:3306
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -298,11 +264,8 @@
location: MESH_EXTERNAL
resolution: DNS
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -318,10 +281,8 @@
location: MESH_EXTERNAL
resolution: DNS
-
{{}}
{{}}
-
It is also possible to mix and match traffic capture modes in a single
proxy. For example, consider a setup where internal services are on the
192.168.0.0/16 subnet. So, IP tables are setup on the VM to capture all
@@ -330,14 +291,11 @@
traffic. The following Sidecar configuration allows the VM to expose a
listener on 172.16.1.32:80 (the VM’s IP) for traffic arriving from the
172.16.0.0/16 subnet.
-
NOTE: The ISTIO_META_INTERCEPTION_MODE metadata on the
proxy in the VM should contain REDIRECT or TPROXY as its value,
implying that IP tables based traffic capture is active.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
@@ -364,11 +322,8 @@
hosts:
- "*/*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
@@ -395,10 +350,8 @@
hosts:
- "*/*"
-
{{}}
{{}}
-
The following example declares a Sidecar configuration in the
prod-us1 namespace for all pods with labels app: ratings
belonging to the ratings.prod-us1 service. The service accepts
@@ -411,10 +364,8 @@
ports.
In this example, the mTLS mode is disabled on PORT 80.
This feature is currently experimental.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
@@ -435,11 +386,8 @@
privateKey: "/etc/certs/privatekey.pem"
serverCertificate: "/etc/certs/servercert.pem"
-
{{}}
-
{{}}
-
apiVersion: v1
kind: Service
metadata:
@@ -455,11 +403,8 @@
selector:
app: ratings
-
{{}}
-
{{}}
-
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
@@ -475,7 +420,6 @@
80:
mode: DISABLE
-
{{}}
{{}}
@@ -721,12 +665,10 @@ IstioEgressListener
(e.g., a Kubernetes or cloud foundry service) or a service specified
using a ServiceEntry or VirtualService configuration. Any
associated DestinationRule in the same namespace will also be used.
-
The dnsName should be specified using FQDN format, optionally including
a wildcard character in the left-most component (e.g., prod/*.example.com).
Set the dnsName to * to select all services from the specified namespace
(e.g., prod/*).
-
The namespace can be set to *, ., or ~, representing any, the current,
or no namespace, respectively. For example, */foo.example.com selects the
service from any available namespace while ./foo.example.com only selects
@@ -735,7 +677,6 @@
IstioEgressListener
mesh that is exported to the sidecar’s namespace. The value ~/* can be used
to completely trim the configuration for sidecars that simply receive traffic
and respond, but make no outbound connections of their own.
-
NOTE: Only services and configuration artifacts exported to the sidecar’s
namespace (e.g., exportTo value of *) can be referenced.
Private configurations (e.g., exportTo set to .) will
diff --git a/content/en/docs/reference/config/networking/virtual-service/index.html b/content/en/docs/reference/config/networking/virtual-service/index.html
index a9106ff481a16..f6ce3a61a4b84 100644
--- a/content/en/docs/reference/config/networking/virtual-service/index.html
+++ b/content/en/docs/reference/config/networking/virtual-service/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Virtual Service
description: Configuration affecting label/content routing, sni routing, etc.
location: https://istio.io/docs/reference/config/networking/virtual-service.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.VirtualService
aliases: [/docs/reference/config/networking/v1alpha3/virtual-service]
@@ -12,11 +12,9 @@
---
Configuration affecting traffic routing. Here are a few terms useful to define
in the context of traffic routing.
-
Service a unit of application behavior bound to a unique name in a
service registry. Services consist of multiple network endpoints
implemented by workload instances running on pods, containers, VMs etc.
-
Service versions (a.k.a. subsets) - In a continuous deployment
scenario, for a given service, there can be distinct subsets of
instances running different variants of the application binary. These
@@ -27,34 +25,26 @@
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 - A downstream client calling a service.
-
Host - The address used by a client when attempting to connect to a
service.
-
Access model - Applications address only the destination service
(Host) without knowledge of individual service versions (subsets). The
actual choice of the version is determined by the proxy/sidecar, enabling the
application code to decouple itself from the evolution of dependent
services.
-
A VirtualService defines a set of traffic routing rules to apply when a host is
addressed. Each routing rule defines matching criteria for traffic of a specific
protocol. If the traffic is matched, then it is sent to a named destination service
(or subset/version of it) defined in the registry.
-
The source of traffic can also be matched in a routing rule. This allows routing
to be customized for specific client contexts.
-
The following example on Kubernetes, routes all HTTP traffic by default to
pods of the reviews service with label “version: v1”. In addition,
HTTP requests with path starting with /wpcatalog/ or /consumercatalog/ will
be rewritten to /newcatalog and sent to pods with label “version: v2”.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -81,11 +71,8 @@
host: reviews.prod.svc.cluster.local
subset: v1
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -112,17 +99,13 @@
host: reviews.prod.svc.cluster.local
subset: v1
-
{{}}
{{}}
-
A subset/version of a route destination is identified with a reference
to a named service subset which must be declared in a corresponding
DestinationRule.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -137,11 +120,8 @@
labels:
version: v2
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -156,7 +136,6 @@
labels:
version: v2
-
{{}}
{{}}
@@ -183,7 +162,6 @@ VirtualService
platform, short-names can also be used instead of a FQDN (i.e. has no
dots in the name). In such a scenario, the FQDN of the host would be
derived based on the underlying platform.
-
A single VirtualService can be used to describe all the traffic
properties of the corresponding hosts, including those for multiple
HTTP and TCP ports. Alternatively, the traffic properties of a host
@@ -191,7 +169,6 @@
VirtualService
caveats. Refer to the
Operations Guide
for details.
-
Note for Kubernetes users: When short names are used (e.g. “reviews”
instead of “reviews.default.svc.cluster.local”), Istio will interpret
the short name based on the namespace of the rule, not the service. A
@@ -200,12 +177,10 @@
VirtualService
the actual namespace associated with the reviews service. To avoid
potential misconfigurations, it is recommended to always use fully
qualified domain names over short names.
-
The hosts field applies to both HTTP and TCP services. Service inside
the mesh, i.e., those found in the service registry, must always be
referred to using their alphanumeric names. IP addresses are allowed
only for services defined via the Gateway.
-
Note: It must be empty for a delegate VirtualService.
@@ -258,10 +233,10 @@ VirtualService
An ordered list of route rule for non-terminated TLS & HTTPS
traffic. Routing is typically performed using the SNI value presented
by the ClientHello message. TLS routes will be applied to platform
-service ports named ‘https-’, ‘tls-’, unterminated gateway ports using
+service ports named ‘https-’, ’tls-’, unterminated gateway ports using
HTTPS/TLS protocols (i.e. with “passthrough” TLS mode) and service
entry ports using HTTPS/TLS protocols. The first rule matching an
-incoming request is used. NOTE: Traffic ‘https-’ or ‘tls-’ ports
+incoming request is used. NOTE: Traffic ‘https-’ or ’tls-’ ports
without associated virtual service will be treated as opaque TCP
traffic.
@@ -292,10 +267,8 @@ VirtualService
other namespaces. This feature provides a mechanism for service owners
and mesh administrators to control the visibility of virtual services
across namespace boundaries.
-
If no namespaces are specified then the virtual service is exported to all
namespaces by default.
-
The value “.” is reserved and defines an export to the same namespace that
the virtual service is declared in. Similarly the value “*” is reserved and
defines an export to all namespaces.
@@ -317,7 +290,6 @@ Destination
in the platform’s service registry (e.g., Kubernetes services, Consul
services), as well as services declared through the
ServiceEntry resource.
-
Note for Kubernetes users: When short names are used (e.g. “reviews”
instead of “reviews.default.svc.cluster.local”), Istio will interpret
the short name based on the namespace of the rule, not the service. A
@@ -326,14 +298,11 @@
Destination
actual namespace associated with the reviews service. To avoid potential
misconfigurations, it is recommended to always use fully qualified
domain names over short names.
-
The following Kubernetes example routes all traffic by default to pods
of the reviews service with label “version: v1” (i.e., subset v1), and
some to subset v2, in a Kubernetes environment.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -359,11 +328,8 @@ Destination
host: reviews # interpreted as reviews.foo.svc.cluster.local
subset: v1
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -389,15 +355,11 @@ Destination
host: reviews # interpreted as reviews.foo.svc.cluster.local
subset: v1
-
{{}}
{{}}
-
And the associated DestinationRule
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -413,11 +375,8 @@ Destination
labels:
version: v2
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -433,10 +392,8 @@ Destination
labels:
version: v2
-
{{}}
{{}}
-
The following VirtualService sets a timeout of 5s for all calls to
productpage.prod.svc.cluster.local service in Kubernetes. Notice that
there are no subsets defined in this rule. Istio will fetch all
@@ -446,10 +403,8 @@
Destination
qualified domain name of the productpage service,
productpage.prod.svc.cluster.local. Therefore the rule’s namespace does
not have an impact in resolving the name of the productpage service.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -464,11 +419,8 @@ Destination
- destination:
host: productpage.prod.svc.cluster.local
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -483,19 +435,15 @@ Destination
- destination:
host: productpage.prod.svc.cluster.local
-
{{}}
{{}}
-
To control routing for traffic bound to services outside the mesh, external
services must first be added to Istio’s internal service registry using the
ServiceEntry resource. VirtualServices can then be defined to control traffic
bound to these external services. For example, the following rules define a
Service for wikipedia.org and set a timeout of 5s for HTTP requests.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -523,11 +471,8 @@ Destination
- destination:
host: wikipedia.org
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -555,7 +500,6 @@ Destination
- destination:
host: wikipedia.org
-
{{}}
{{}}
@@ -578,7 +522,6 @@ Destination
Kubernetes services, Consul services, etc.) and from the hosts
declared by ServiceEntry. Traffic forwarded to
destinations that are not found in either of the two, will be dropped.
-
Note for Kubernetes users: When short names are used (e.g. “reviews”
instead of “reviews.default.svc.cluster.local”), Istio will interpret
the short name based on the namespace of the rule, not the service. A
@@ -700,7 +643,6 @@
HTTPRoute
A HTTP rule can either return a direct_response, redirect or forward (default) traffic.
Direct Response is used to specify a fixed response that should
be sent to clients.
-
It can be set only when Route and Redirect are empty.
@@ -714,13 +656,10 @@ HTTPRoute
Delegate is used to specify the particular VirtualService which
can be used to define delegate HTTPRoute.
-
It can be set only when Route and Redirect are empty, and the route
rules of the delegate VirtualService will be merged with that in the
current one.
-
NOTE:
-
- Only one level delegation is supported.
- The delegate’s HTTPMatchRequest must be a strict subset of the root’s,
@@ -840,7 +779,6 @@
Delegate
Describes the delegate VirtualService.
The following routing rules forward the traffic to /productpage by a delegate VirtualService named productpage,
forward the traffic to /reviews by a delegate VirtualService named reviews.
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -864,7 +802,6 @@ Delegate
name: reviews
namespace: nsB
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -882,7 +819,6 @@ Delegate
- destination:
host: productpage.nsA.svc.cluster.local
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -940,10 +876,8 @@ Headers
to requests that are routed to any reviews service destination.
It also removes the foo response header, but only from responses
coming from the v1 subset (version) of the reviews service.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -970,11 +904,8 @@ Headers
- foo
weight: 75
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -1001,7 +932,6 @@ Headers
- foo
weight: 75
-
{{}}
{{}}
@@ -1048,10 +978,8 @@ TLSRoute
traffic (TLS/HTTPS) The following routing rule forwards unterminated TLS
traffic arriving at port 443 of gateway called “mygateway” to internal
services in the mesh based on the SNI value.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -1077,11 +1005,8 @@ TLSRoute
- destination:
host: reviews.prod.svc.cluster.local
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -1107,7 +1032,6 @@ TLSRoute
- destination:
host: reviews.prod.svc.cluster.local
-
{{}}
{{}}
@@ -1154,10 +1078,8 @@ TCPRoute
Describes match conditions and actions for routing TCP traffic. The
following routing rule forwards traffic arriving at port 27017 for
mongo.prod.svc.cluster.local to another Mongo server on port 5555.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -1174,11 +1096,8 @@ TCPRoute
port:
number: 5555
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -1195,7 +1114,6 @@ TCPRoute
port:
number: 5555
-
{{}}
{{}}
@@ -1244,10 +1162,8 @@ HTTPMatchRequest
restricts the rule to match only requests where the URL path
starts with /ratings/v2/ and the request contains a custom end-user header
with value jason.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -1267,11 +1183,8 @@ HTTPMatchRequest
- destination:
host: ratings.prod.svc.cluster.local
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -1291,10 +1204,8 @@ HTTPMatchRequest
- destination:
host: ratings.prod.svc.cluster.local
-
{{}}
{{}}
-
HTTPMatchRequest CANNOT be empty.
Note: No regex string match can be set when delegate VirtualService is specified.
@@ -1327,15 +1238,17 @@ HTTPMatchRequest
URI to match
values are case-sensitive and formatted as follows:
-
-exact: "value" for exact string match
prefix: "value" for prefix-based match
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
-
+
exact: "value" for exact string match
+
+-
+
prefix: "value" for prefix-based match
+
+-
+
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
+
-
Note: Case-insensitive matching could be enabled via the
ignore_uri_case flag.
@@ -1350,13 +1263,16 @@ HTTPMatchRequest
URI Scheme
values are case-sensitive and formatted as follows:
-
-exact: "value" for exact string match
prefix: "value" for prefix-based match
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
-
+
exact: "value" for exact string match
+
+-
+
prefix: "value" for prefix-based match
+
+-
+
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
+
@@ -1370,13 +1286,16 @@ HTTPMatchRequest
HTTP Method
values are case-sensitive and formatted as follows:
-
-exact: "value" for exact string match
prefix: "value" for prefix-based match
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
-
+
exact: "value" for exact string match
+
+-
+
prefix: "value" for prefix-based match
+
+-
+
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
+
@@ -1390,13 +1309,16 @@ HTTPMatchRequest
HTTP Authority
values are case-sensitive and formatted as follows:
-
-exact: "value" for exact string match
prefix: "value" for prefix-based match
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
-
+
exact: "value" for exact string match
+
+-
+
prefix: "value" for prefix-based match
+
+-
+
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
+
@@ -1410,17 +1332,18 @@ HTTPMatchRequest
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" for exact string match
prefix: "value" for prefix-based match
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
-
+
exact: "value" for exact string match
+
+-
+
prefix: "value" for prefix-based match
+
+-
+
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
+
-
If the value is empty and only the name of header is specfied, presence of the header is checked.
Note: The keys uri, scheme, method, and authority will be ignored.
@@ -1474,21 +1397,22 @@ HTTPMatchRequest
map<string, StringMatch>
Query parameters for matching.
-
Ex:
-
-For a query parameter like “?key=true”, the map key would be “key” and
-the string match could be defined as exact: "true".
For a query parameter like “?key”, the map key would be “key” and the
-string match could be defined as exact: "".
For a query parameter like “?key=123”, the map key would be “key” and the
+
-
+
For a query parameter like “?key=true”, the map key would be “key” and
+the string match could be defined as exact: "true".
+
+-
+
For a query parameter like “?key”, the map key would be “key” and the
+string match could be defined as exact: "".
+
+-
+
For a query parameter like “?key=123”, the map key would be “key” and the
string match could be defined as regex: "\d+$". Note that this
-configuration will only match values like “123” but not “a123” or “123a”.
+configuration will only match values like “123” but not “a123” or “123a”.
+
-
Note: prefix matching is currently not supported.
@@ -1501,7 +1425,6 @@ HTTPMatchRequest
bool
Flag to specify whether the URI matching should be case-insensitive.
-
Note: The case will be ignored only in the case of exact and prefix
URI matches.
@@ -1540,10 +1463,10 @@ HTTPMatchRequest
string
The human readable prefix to use when emitting statistics for this route.
-The statistics are generated with prefix route..
+The statistics are generated with prefix route.<stat_prefix>.
This should be set for highly critical routes that one wishes to get “per-route” statistics on.
-This prefix is only for proxy-level statistics (envoy*) and not service-level (istio*) statistics.
-Refer to https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-field-config-route-v3-route-stat-prefix
+This prefix is only for proxy-level statistics (envoy_) and not service-level (istio_) statistics.
+Refer to https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-field-config-route-v3-route-stat-prefix
for statistics that are generated when this is configured.
@@ -1562,10 +1485,8 @@ HTTPRouteDestination
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”.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -1584,11 +1505,8 @@ HTTPRouteDestination
subset: v1
weight: 75
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -1607,15 +1525,11 @@ HTTPRouteDestination
subset: v1
weight: 75
-
{{}}
{{}}
-
And the associated DestinationRule
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -1630,11 +1544,8 @@ HTTPRouteDestination
labels:
version: v2
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -1649,17 +1560,13 @@ HTTPRouteDestination
labels:
version: v2
-
{{}}
{{}}
-
Traffic can also be split across two entirely different services without
having to define new subsets. For example, the following rule forwards 25% of
traffic to reviews.com to dev.reviews.com
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -1676,11 +1583,8 @@ HTTPRouteDestination
host: reviews.com
weight: 75
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -1697,7 +1601,6 @@ HTTPRouteDestination
host: reviews.com
weight: 75
-
{{}}
{{}}
@@ -1979,10 +1882,8 @@ HTTPRedirect
the specified values. For example, the following rule redirects
requests for /v1/getProductRatings API on the ratings service to
/v1/bookRatings provided by the bookratings service.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -1999,11 +1900,8 @@ HTTPRedirect
authority: newratings.default.svc.cluster.local
...
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2020,7 +1918,6 @@ HTTPRedirect
authority: newratings.default.svc.cluster.local
...
-
{{}}
{{}}
@@ -2074,9 +1971,11 @@ HTTPRedirect
derivePortRedirectPortSelection (oneof)
-On a redirect, dynamically set the port:
-* FROM_PROTOCOL_DEFAULT: automatically set to 80 for HTTP and 443 for HTTPS.
-* FROM_REQUEST_PORT: automatically use the port of the request.
+On a redirect, dynamically set the port:
+
+- FROM_PROTOCOL_DEFAULT: automatically set to 80 for HTTP and 443 for HTTPS.
+- FROM_REQUEST_PORT: automatically use the port of the request.
+
@@ -2117,10 +2016,8 @@ HTTPDirectResponse
HTTPDirectResponse can be used to send a fixed response to clients.
For example, the following rule returns a fixed 503 status with a body
to requests for /v1/getProductRatings API.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -2138,11 +2035,8 @@ HTTPDirectResponse
string: "unknown error"
...
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2160,16 +2054,12 @@ HTTPDirectResponse
string: "unknown error"
...
-
{{}}
{{}}
-
It is also possible to specify a binary response body.
This is mostly useful for non text-based protocols such as gRPC.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -2187,11 +2077,8 @@ HTTPDirectResponse
bytes: "dW5rbm93biBlcnJvcg==" # "unknown error" in base64
...
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2209,17 +2096,13 @@ HTTPDirectResponse
bytes: "dW5rbm93biBlcnJvcg==" # "unknown error" in base64
...
-
{{}}
{{}}
-
It is good practice to add headers in the HTTPRoute
as well as the direct_response, for example to specify
the returned Content-Type.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -2241,11 +2124,8 @@ HTTPDirectResponse
content-type: "appliation/json"
...
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2267,7 +2147,6 @@ HTTPDirectResponse
content-type: "text/plain"
...
-
{{}}
{{}}
@@ -2351,10 +2230,8 @@ HTTPRewrite
be used only with HTTPRouteDestination. The following example
demonstrates how to rewrite the URL prefix for api call (/ratings) to
ratings service before making the actual API call.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -2373,11 +2250,8 @@ HTTPRewrite
host: ratings.prod.svc.cluster.local
subset: v1
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2396,7 +2270,6 @@ HTTPRewrite
host: ratings.prod.svc.cluster.local
subset: v1
-
{{}}
{{}}
@@ -2478,7 +2351,7 @@ StringMatch
regexstring (oneof)
-RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
+RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
@@ -2495,10 +2368,8 @@ HTTPRetry
calling ratings:v1 service, with a 2s timeout per retry attempt.
A retry will be attempted if there is a connect-failure, refused_stream
or when the upstream server responds with Service Unavailable(503).
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -2516,11 +2387,8 @@ HTTPRetry
perTryTimeout: 2s
retryOn: connect-failure,refused-stream,503
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2538,7 +2406,6 @@ HTTPRetry
perTryTimeout: 2s
retryOn: gateway-error,connect-failure,refused-stream
-
{{}}
{{}}
@@ -2620,10 +2487,8 @@ CorsPolicy
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.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -2647,11 +2512,8 @@ CorsPolicy
- X-Foo-Bar
maxAge: "24h"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2675,7 +2537,6 @@ CorsPolicy
- X-Foo-Bar
maxAge: "24h"
-
{{}}
{{}}
@@ -2773,7 +2634,6 @@ HTTPFaultInjection
Fault specification is part of a VirtualService rule. Faults include
aborting the Http request from downstream service, and/or delaying
proxying of requests. A fault rule MUST HAVE delay or abort or both.
-
Note: Delay and abort faults are independent of one another, even if
both are specified simultaneously.
@@ -2926,10 +2786,8 @@ HTTPFaultInjection.Delay
forwarding path. The following example will introduce a 5 second delay
in 1 out of every 1000 requests to the “v1” version of the “reviews”
service from all pods with label env: prod
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -2951,11 +2809,8 @@ HTTPFaultInjection.Delay
value: 0.1
fixedDelay: 5s
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2977,10 +2832,8 @@ HTTPFaultInjection.Delay
value: 0.1
fixedDelay: 5s
-
{{}}
{{}}
-
The fixedDelay field is used to indicate the amount of delay in seconds.
The optional percentage field can be used to only delay a certain
percentage of requests. If left unspecified, all request will be delayed.
@@ -3039,10 +2892,8 @@ 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 1 out of every 1000 requests to the “ratings” service “v1”.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -3061,11 +2912,8 @@ HTTPFaultInjection.Abort
value: 0.1
httpStatus: 400
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -3084,10 +2932,8 @@ HTTPFaultInjection.Abort
value: 0.1
httpStatus: 400
-
{{}}
{{}}
-
The httpStatus field is used to indicate the HTTP status code to
return to the caller. The optional percentage field can be used to only
abort a certain percentage of requests. If not specified, all requests are
@@ -3119,7 +2965,7 @@
HTTPFaultInjection.Abort
string (oneof)
GRPC status code to use to abort the request. The supported
-codes are documented in https://github.com/grpc/grpc/blob/master/doc/statuscodes.md
+codes are documented in https://github.com/grpc/grpc/blob/master/doc/statuscodes.md
Note: If you want to return the status “Unavailable”, then you should
specify the code as UNAVAILABLE(all caps), but not 14.
@@ -3145,7 +2991,6 @@ HTTPFaultInjection.Abort
google.protobuf.UInt32Value
Wrapper message for uint32.
-
The JSON representation for UInt32Value is JSON number.
diff --git a/content/en/docs/reference/config/networking/workload-entry/index.html b/content/en/docs/reference/config/networking/workload-entry/index.html
index 1c0a579a84359..2d3c4ca405267 100644
--- a/content/en/docs/reference/config/networking/workload-entry/index.html
+++ b/content/en/docs/reference/config/networking/workload-entry/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Workload Entry
description: Configuration affecting VMs onboarded into the mesh.
location: https://istio.io/docs/reference/config/networking/workload-entry.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.WorkloadEntry
aliases: [/docs/reference/config/networking/v1alpha3/workload-entry]
@@ -19,12 +19,10 @@
ServiceEntry object can select multiple workload entries as well
as Kubernetes pods based on the label selector specified in the
service entry.
-
When a workload connects to istiod, the status field in the
custom resource will be updated to indicate the health of the
workload along with other details, similar to how Kubernetes
updates the status of a pod.
-
The following example declares a workload entry representing a VM
for the details.bookinfo.com service. This VM has sidecar
installed and bootstrapped using the details-legacy service
@@ -32,10 +30,8 @@
mesh. The HTTP traffic to this service is wrapped in Istio mutual
TLS and sent to sidecars on VMs on target port 8080, that in turn
forward it to the application on localhost on the same port.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
@@ -51,11 +47,8 @@
app: details-legacy
instance-id: vm1
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: WorkloadEntry
metadata:
@@ -71,15 +64,11 @@
app: details-legacy
instance-id: vm1
-
{{}}
{{}}
-
and the associated service entry
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -98,11 +87,8 @@
labels:
app: details-legacy
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -121,19 +107,15 @@
labels:
app: details-legacy
-
{{}}
{{}}
-
The following example declares the same VM workload using
its fully qualified DNS name. The service entry’s resolution
mode should be changed to DNS to indicate that the client-side
sidecars should dynamically resolve the DNS name at runtime before
forwarding the request.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
@@ -149,11 +131,8 @@
app: details-legacy
instance-id: vm1
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: WorkloadEntry
metadata:
@@ -169,15 +148,11 @@
app: details-legacy
instance-id: vm1
-
{{}}
{{}}
-
and the associated service entry
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -196,11 +171,8 @@
labels:
app: details-legacy
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -219,7 +191,6 @@
labels:
app: details-legacy
-
{{}}
{{}}
@@ -265,9 +236,7 @@ WorkloadEntry
the targetPort and endpoint’s port map are not specified, traffic
to a service port will be forwarded to one of the endpoints on
the same port.
-
NOTE 1: Do not use for unix:// addresses.
-
NOTE 2: endpoint port map takes precedence over targetPort.
diff --git a/content/en/docs/reference/config/networking/workload-group/index.html b/content/en/docs/reference/config/networking/workload-group/index.html
index 6797e88414615..726587170d3e1 100644
--- a/content/en/docs/reference/config/networking/workload-group/index.html
+++ b/content/en/docs/reference/config/networking/workload-group/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Workload Group
description: Describes a collection of workload instances.
location: https://istio.io/docs/reference/config/networking/workload-group.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.WorkloadGroup
aliases: [/docs/reference/config/networking/v1alpha3/workload-group]
@@ -16,17 +16,14 @@
be used with non-k8s workloads like Virtual Machines, and is meant to mimic
the existing sidecar injection and deployment specification model used for
Kubernetes workloads to bootstrap Istio proxies.
-
The following example declares a workload group representing a collection
of workloads that will be registered under reviews in namespace
bookinfo. The set of labels will be associated with each workload
instance during the bootstrap process, and the ports 3550 and 8080
will be associated with the workload group and use service account default.
app.kubernetes.io/version is just an arbitrary example of a label.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
@@ -57,7 +54,6 @@
- name: Lit-Header
value: Im-The-Best
-
{{}}
{{}}
diff --git a/content/en/docs/reference/config/proxy_extensions/wasm-plugin/index.html b/content/en/docs/reference/config/proxy_extensions/wasm-plugin/index.html
index b7e5be6495b9c..5d855fe276649 100644
--- a/content/en/docs/reference/config/proxy_extensions/wasm-plugin/index.html
+++ b/content/en/docs/reference/config/proxy_extensions/wasm-plugin/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Wasm Plugin
description: Extend the functionality provided by the Istio proxy through WebAssembly filters.
location: https://istio.io/docs/reference/config/proxy_extensions/wasm-plugin.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.extensions.v1alpha1.WasmPlugin
aliases: [/docs/reference/config/extensions/v1alpha1/wasm-plugin]
@@ -12,18 +12,14 @@
---
WasmPlugins provides a mechanism to extend the functionality provided by
the Istio proxy through WebAssembly filters.
-
Order of execution (as part of Envoy’s filter chain) is determined by
phase and priority settings, allowing the configuration of complex
interactions between user-supplied WasmPlugins and Istio’s internal
filters.
-
Examples:
-
AuthN Filter deployed to ingress-gateway that implements an OpenID flow
and populates the Authorization header with a JWT to be consumed by
Istio AuthN.
-
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
@@ -40,9 +36,7 @@
openid_server: authn
openid_realm: ingress
-
This is the same as the last example, but using an OCI image.
-
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
@@ -60,9 +54,7 @@
openid_server: authn
openid_realm: ingress
-
This is the same as the last example, but using VmConfig to configure environment variables in the VM.
-
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
@@ -86,9 +78,7 @@
- name: TRUST_DOMAIN
value: "cluster.local"
-
This is also the same as the last example, but the Wasm module is pulled via https and updated for each time when this plugin resource is changed.
-
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
@@ -111,7 +101,6 @@
- name: TRUST_DOMAIN
value: "cluster.local"
-
And a more complex example that deploys three WasmPlugins and orders them
using phase and priority. The (hypothetical) setup is that the
openid-connect filter performs an OpenID Connect flow to authenticate the
@@ -123,10 +112,8 @@
acl-check filter writes this token to a header. Finally, the check-header
filter verifies the token in that header and makes sure that the token’s
contents (the permitted ‘function’) matches its plugin configuration.
-
The resulting filter chain looks like this:
-> openid-connect -> istio.authn -> acl-check -> check-header -> router
-
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
@@ -144,7 +131,6 @@
openid_server: authn
openid_realm: ingress
-
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
@@ -163,7 +149,6 @@
acl_server: some_server
set_header: authz_complete
-
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
diff --git a/content/en/docs/reference/config/security/authorization-policy/index.html b/content/en/docs/reference/config/security/authorization-policy/index.html
index 27d4181081ff6..536249a09fa01 100644
--- a/content/en/docs/reference/config/security/authorization-policy/index.html
+++ b/content/en/docs/reference/config/security/authorization-policy/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Authorization Policy
description: Configuration for access control on workloads.
location: https://istio.io/docs/reference/config/security/authorization-policy.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.security.v1beta1.AuthorizationPolicy
weight: 20
@@ -12,11 +12,9 @@
number_of_entries: 9
---
Istio Authorization Policy enables access control on workloads in the mesh.
-
Authorization policy supports CUSTOM, DENY and ALLOW actions for access control. When CUSTOM, DENY and ALLOW actions
are used for a workload at the same time, the CUSTOM action is evaluated first, then the DENY action, and finally the ALLOW action.
The evaluation is determined by the following rules:
-
- If there are any CUSTOM policies that match the request, evaluate and deny the request if the evaluation result is deny.
- If there are any DENY policies that match the request, deny the request.
@@ -24,39 +22,28 @@
- If any of the ALLOW policies match the request, allow the request.
- Deny the request.
-
Istio Authorization Policy also supports the AUDIT action to decide whether to log requests.
AUDIT policies do not affect whether requests are allowed or denied to the workload.
Requests will be allowed or denied based solely on CUSTOM, DENY and ALLOW actions.
-
A request will be internally marked that it should be audited if there is an AUDIT policy on the workload that matches the request.
A separate plugin must be configured and enabled to actually fulfill the audit decision and complete the audit behavior.
The request will not be audited if there are no such supporting plugins enabled.
Currently, the only supported plugin is the Stackdriver plugin.
-
Here is an example of Istio Authorization Policy:
-
It sets the action to “ALLOW” to create an allow policy. The default action is “ALLOW”
but it is useful to be explicit in the policy.
-
It allows requests from:
-
- service account “cluster.local/ns/default/sa/sleep” or
- namespace “test”
-
to access the workload with:
-
- “GET” method at paths of prefix “/info” or,
- “POST” method at path “/data”.
-
-when the request has a valid JWT token issued by “https://accounts.google.com”.
-
+when the request has a valid JWT token issued by “https://accounts.google.com”.
Any other requests will be denied.
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -81,11 +68,9 @@
- key: request.auth.claims[iss]
values: ["https://accounts.google.com"]
-
The following is another example that sets action to “DENY” to create a deny policy.
It denies requests from the “dev” namespace to the “POST” method on all workloads
in the “foo” namespace.
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -101,10 +86,8 @@
- operation:
methods: ["POST"]
-
The following authorization policy sets the action to “AUDIT”. It will audit any GET requests to the path with the
prefix “/user/profile”.
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -121,21 +104,16 @@
methods: ["GET"]
paths: ["/user/profile/*"]
-
Authorization Policy scope (target) is determined by “metadata/namespace” and
an optional “selector”.
-
- “metadata/namespace” tells which namespace the policy applies. If set to root
namespace, the policy applies to all namespaces in a mesh.
- workload “selector” can be used to further restrict where a policy applies.
-
For example,
-
The following authorization policy applies to all workloads in namespace foo. It allows nothing and effectively denies
all requests to workloads in namespace foo.
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -144,9 +122,7 @@
spec:
{}
-
The following authorization policy allows all requests to workloads in namespace foo.
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -156,10 +132,8 @@
rules:
- {}
-
The following authorization policy applies to workloads containing label “app: httpbin” in namespace bar. It allows
nothing and effectively denies all requests to the selected workloads.
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -170,10 +144,8 @@
matchLabels:
app: httpbin
-
The following authorization policy applies to workloads containing label “version: v1” in all namespaces in the mesh.
(Assuming the root namespace is configured to “istio-system”).
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -206,7 +178,6 @@ AuthorizationPolicy
Optional. The selector decides where to apply the authorization policy. The selector will match with workloads
in the same namespace as the authorization policy. If the authorization policy is in the root namespace, the selector
will additionally match with workloads in all namespaces.
-
If not set, the selector will match all workloads.
@@ -219,7 +190,6 @@ AuthorizationPolicy
Rule[]
Optional. A list of rules to match the request. A match occurs when at least one rule matches the request.
-
If not set, the match will never occur. This is equivalent to setting a default of deny for the target workloads if
the action is ALLOW.
@@ -258,9 +228,7 @@ Rule
Rule matches requests from a list of sources that perform a list of operations subject to a
list of conditions. A match occurs when at least one source, one operation and all conditions
matches the request. An empty rule is always matched.
-
Any string field in the rule supports Exact, Prefix, Suffix and Presence match:
-
- Exact match: “abc” will match on value “abc”.
- Prefix match: “abc*” will match on value “abc” and “abcd”.
@@ -283,7 +251,6 @@ Rule
From[]
Optional. from specifies the source of a request.
-
If not set, any source is allowed.
@@ -296,7 +263,6 @@ Rule
To[]
Optional. to specifies the operation of a request.
-
If not set, any operation is allowed.
@@ -309,7 +275,6 @@ Rule
Condition[]
Optional. when specifies a list of additional conditions of a request.
-
If not set, any condition is allowed.
@@ -324,10 +289,8 @@ Source
Source specifies the source identities of a request. Fields in the source are
ANDed together.
-
For example, the following source matches if the principal is “admin” or “dev”
and the namespace is “prod” or “test” and the ip is not “1.2.3.4”.
-
principals: ["admin", "dev"]
namespaces: ["prod", "test"]
notIpBlocks: ["1.2.3.4"]
@@ -350,7 +313,6 @@ Source
Optional. A list of peer identities derived from the peer certificate. The peer identity is in the format of
"<TRUST_DOMAIN>/ns/<NAMESPACE>/sa/<SERVICE_ACCOUNT>", for example, "cluster.local/ns/default/sa/productpage".
This field requires mTLS enabled and is the same as the source.principal attribute.
-
If not set, any principal is allowed.
@@ -376,7 +338,6 @@ Source
Optional. A list of request identities derived from the JWT. The request identity is in the format of
"<ISS>/<SUB>", for example, "example.com/sub-1". This field requires request authentication enabled and is the
same as the request.auth.principal attribute.
-
If not set, any request principal is allowed.
@@ -401,7 +362,6 @@ Source
Optional. A list of namespaces derived from the peer certificate.
This field requires mTLS enabled and is the same as the source.namespace attribute.
-
If not set, any namespace is allowed.
@@ -426,7 +386,6 @@ Source
Optional. A list of IP blocks, populated from the source address of the IP packet. Single IP (e.g. “1.2.3.4”) and
CIDR (e.g. “1.2.3.0/24”) are supported. This is the same as the source.ip attribute.
-
If not set, any IP is allowed.
@@ -455,7 +414,6 @@ Source
Configuring Gateway Network Topology.
Single IP (e.g. “1.2.3.4”) and CIDR (e.g. “1.2.3.0/24”) are supported.
This is the same as the remote.ip attribute.
-
If not set, any IP is allowed.
@@ -481,10 +439,8 @@ Operation
Operation specifies the operations of a request. Fields in the operation are
ANDed together.
-
For example, the following operation matches if the host has suffix “.example.com”
and the method is “GET” or “HEAD” and the path doesn’t have prefix “/admin”.
-
hosts: ["*.example.com"]
methods: ["GET", "HEAD"]
notPaths: ["/admin*"]
@@ -507,7 +463,6 @@ Operation
Optional. A list of hosts as specified in the HTTP request. The match is case-insensitive.
See the security best practices for
recommended usage of this field.
-
If not set, any host is allowed. Must be used only with HTTP.
@@ -531,7 +486,6 @@ Operation
string[]
Optional. A list of ports as specified in the connection.
-
If not set, any port is allowed.
@@ -556,7 +510,6 @@ Operation
Optional. A list of methods as specified in the HTTP request.
For gRPC service, this will always be “POST”.
-
If not set, any method is allowed. Must be used only with HTTP.
@@ -582,7 +535,6 @@ Operation
Optional. A list of paths as specified in the HTTP request. See the Authorization Policy Normalization
for details of the path normalization.
For gRPC service, this will be the fully-qualified name in the form of “/package.service/method”.
-
If not set, any path is allowed. Must be used only with HTTP.
@@ -784,12 +736,9 @@ AuthorizationPolicy.Action
the extension by specifying the name of the provider.
One example use case of the extension is to integrate with a custom external authorization system to delegate
the authorization decision to it.
-
Note: The CUSTOM action is currently an alpha feature and is subject to breaking changes in later versions.
-
The following authorization policy applies to an ingress gateway and delegates the authorization check to a named extension
“my-custom-authz” if the request path has prefix “/admin/”.
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
diff --git a/content/en/docs/reference/config/security/jwt/index.html b/content/en/docs/reference/config/security/jwt/index.html
index b40e1998f099d..ded4f6c0a2def 100644
--- a/content/en/docs/reference/config/security/jwt/index.html
+++ b/content/en/docs/reference/config/security/jwt/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: JWTRule
description: Configuration to validate JWT.
location: https://istio.io/docs/reference/config/security/jwt.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.security.v1beta1.JWTRule
aliases: [/docs/reference/config/security/v1beta1/jwt]
@@ -16,23 +16,18 @@ JWTRule
RFC 7519. See OAuth 2.0 and
OIDC 1.0 for how this is used in the whole
authentication flow.
-
Examples:
-
Spec for a JWT that is issued by https://example.com, with the audience claims must be either
bookstore_android.apps.example.com or bookstore_web.apps.example.com.
The token should be presented at the Authorization header (default). The JSON Web Key Set (JWKS)
will be discovered following OpenID Connect protocol.
-
issuer: https://example.com
audiences:
- bookstore_android.apps.example.com
bookstore_web.apps.example.com
-
This example specifies a token in a non-default location (x-goog-iap-jwt-assertion header). It also
defines the URI to fetch JWKS explicitly.
-
issuer: https://example.com
jwksUri: https://example.com/.secret/jwks.json
fromHeaders:
@@ -56,9 +51,8 @@ JWTRule
Identifies the issuer that issued the JWT. See
issuer
A JWT with different iss claim will be rejected.
-
-Example: https://foobar.auth0.com
-Example: 1234567-compute@developer.gserviceaccount.com
+Example: https://foobar.auth0.com
+Example: 1234567-compute@developer.gserviceaccount.com
@@ -73,11 +67,8 @@ JWTRule
audiences.
that are allowed to access. A JWT containing any of these
audiences will be accepted.
-
The service name will be accepted if audiences is empty.
-
Example:
-
audiences:
- bookstore_android.apps.example.com
bookstore_web.apps.example.com
@@ -94,15 +85,12 @@ JWTRule
URL of the provider’s public key set to validate signature of the
JWT. See OpenID Discovery.
-
Optional if the key set document can either (a) be retrieved from
OpenID
Discovery of
the issuer or (b) inferred from the email domain of the issuer (e.g. a
Google service account).
-
Example: https://www.googleapis.com/oauth2/v1/certs
-
Note: Only one of jwksUri and jwks should be used.
@@ -115,8 +103,7 @@ JWTRule
string
JSON Web Key Set of public keys to validate signature of the JWT.
-See https://auth0.com/docs/jwks.
-
+See https://auth0.com/docs/jwks.
Note: Only one of jwksUri and jwks should be used.
@@ -129,13 +116,11 @@ JWTRule
JWTHeader[]
List of header locations from which JWT is expected. For example, below is the location spec
-if JWT is expected to be found in x-jwt-assertion header, and have “Bearer ” prefix:
-
+if JWT is expected to be found in x-jwt-assertion header, and have “Bearer " prefix:
fromHeaders:
- name: x-jwt-assertion
prefix: "Bearer "
-
Note: Requests with multiple tokens (at different locations) are not supported, the output principal of
such requests is undefined.
@@ -150,11 +135,9 @@ JWTRule
List of query parameters from which JWT is expected. For example, if JWT is provided via query
parameter my_token (e.g /path?my_token=), the config is:
-
fromParams:
- "my_token"
-
Note: Requests with multiple tokens (at different locations) are not supported, the output principal of
such requests is undefined.
@@ -220,7 +203,7 @@ JWTHeader
string
The prefix that should be stripped before decoding the token.
-For example, for “Authorization: Bearer ”, prefix=“Bearer ” with a space at the end.
+For example, for “Authorization: Bearer ”, prefix=“Bearer " with a space at the end.
If the header doesn’t have this exact prefix, it is considered invalid.
diff --git a/content/en/docs/reference/config/security/peer_authentication/index.html b/content/en/docs/reference/config/security/peer_authentication/index.html
index bc294237e6ce4..7f7cfc272dde4 100644
--- a/content/en/docs/reference/config/security/peer_authentication/index.html
+++ b/content/en/docs/reference/config/security/peer_authentication/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: PeerAuthentication
description: Peer authentication configuration for workloads.
location: https://istio.io/docs/reference/config/security/peer_authentication.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.security.v1beta1.PeerAuthentication
aliases: [/docs/reference/config/security/v1beta1/peer_authentication]
@@ -13,11 +13,8 @@
PeerAuthentication
PeerAuthentication defines how traffic will be tunneled (or not) to the sidecar.
-
Examples:
-
Policy to allow mTLS traffic for all workloads under namespace foo:
-
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
@@ -27,12 +24,9 @@ PeerAuthentication
mtls:
mode: STRICT
-
For mesh level, put the policy in root-namespace according to your Istio installation.
-
Policies to allow both mTLS & plaintext traffic for all workloads under namespace foo, but
require mTLS for workload finance.
-
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
@@ -54,10 +48,8 @@ PeerAuthentication
mtls:
mode: STRICT
-
Policy to allow mTLS strict for all workloads, but leave port 8080 to
plaintext:
-
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
@@ -73,10 +65,8 @@ PeerAuthentication
8080:
mode: DISABLE
-
Policy to inherit mTLS mode from namespace (or mesh) settings, and overwrite
settings for port 8080
-
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
diff --git a/content/en/docs/reference/config/security/request_authentication/index.html b/content/en/docs/reference/config/security/request_authentication/index.html
index ce1720e4f7a9b..2e568fba5c633 100644
--- a/content/en/docs/reference/config/security/request_authentication/index.html
+++ b/content/en/docs/reference/config/security/request_authentication/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: RequestAuthentication
description: Request authentication configuration for workloads.
location: https://istio.io/docs/reference/config/security/request_authentication.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.security.v1beta1.RequestAuthentication
aliases: [/docs/reference/config/security/v1beta1/request_authentication]
@@ -18,11 +18,9 @@ RequestAuthentication
will be accepted but will not have any authenticated identity. To restrict access to authenticated
requests only, this should be accompanied by an authorization rule.
Examples:
-
- Require JWT for all request for workloads that have label
app:httpbin
-
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
@@ -50,13 +48,11 @@ RequestAuthentication
- source:
requestPrincipals: ["*"]
-
- A policy in the root namespace (“istio-system” by default) applies to workloads in all namespaces
in a mesh. The following policy makes all workloads only accept requests that contain a
valid JWT token.
-
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
@@ -78,13 +74,11 @@ RequestAuthentication
- source:
requestPrincipals: ["*"]
-
- The next example shows how to set a different JWT requirement for a different
host. The RequestAuthentication
declares it can accept JWTs issued by either issuer-foo or issuer-bar (the public key set is implicitly
set from the OpenID Connect spec).
-
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
@@ -121,13 +115,11 @@ RequestAuthentication
- operation:
hosts: ["another-host.com"]
-
- You can fine tune the authorization policy to set different requirement per path. For example,
to require JWT on all paths, except /healthz, the same
RequestAuthentication can be used, but the
authorization policy could be:
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -145,24 +137,19 @@ RequestAuthentication
- operation:
paths: ["/healthz"]
-
[Experimental] Routing based on derived metadata
is now supported. A prefix ‘@’ is used to denote a match against internal metadata instead of the headers in the request.
Currently this feature is only supported for the following metadata:
-
request.auth.claims.{claim-name}[.{sub-claim}]* which are extracted from validated JWT tokens. The claim name
currently does not support the . character. Examples: request.auth.claims.sub and request.auth.claims.name.givenName.
-
The use of matches against JWT claim metadata is only supported in Gateways. The following example shows:
-
- RequestAuthentication to decode and validate a JWT. This also makes the
@request.auth.claims available for use in the VirtualService.
- AuthorizationPolicy to check for valid principals in the request. This makes the JWT required for the request.
- VirtualService to route the request based on the “sub” claim.
-
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
@@ -233,7 +220,6 @@ RequestAuthentication
Optional. The selector decides where to apply the request authentication policy. The selector will match with workloads
in the same namespace as the request authentication policy. If the request authentication policy is in the root namespace,
the selector will additionally match with workloads in all namespaces.
-
If not set, the selector will match all workloads.
diff --git a/content/en/docs/reference/config/telemetry/index.html b/content/en/docs/reference/config/telemetry/index.html
index d56375ebdf4c5..6e94084fc21a2 100644
--- a/content/en/docs/reference/config/telemetry/index.html
+++ b/content/en/docs/reference/config/telemetry/index.html
@@ -1,38 +1,30 @@
---
-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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Telemetry
description: Telemetry configuration for workloads.
location: https://istio.io/docs/reference/config/telemetry.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.telemetry.v1alpha1.Telemetry
aliases: [/docs/reference/config/telemetry/v1alpha1/telemetry]
number_of_entries: 18
---
Telemetry defines how the telemetry is generated for workloads within a mesh.
-
For mesh level configuration, put the resource in root configuration
namespace for your Istio installation without a workload selector.
-
For any namespace, including the root configuration namespace, it is only
valid to have a single workload selector-less Telemetry resource.
-
For resources with a workload selector, it is only valid to have one resource
selecting any given workload.
-
The hierarchy of Telemetry configuration is as follows:
-
- Workload-specific configuration
- Namespace-specific configuration
- Root namespace configuration
-
Examples:
-
Policy to enable random sampling for 10% of traffic:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -43,10 +35,8 @@
tracing:
- randomSamplingPercentage: 10.00
-
Policy to disable trace reporting for the “foo” workload (note: tracing
context will still be propagated):
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -59,9 +49,7 @@
tracing:
- disableSpanReporting: true
-
Policy to select the alternate zipkin provider for trace reporting:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -76,9 +64,7 @@
- name: "zipkin-alternate"
randomSamplingPercentage: 10.00
-
Policy to add a custom tag from a literal value:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -93,9 +79,7 @@
literal:
value: "foo"
-
Policy to disable server-side metrics for Stackdriver for an entire mesh:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -112,9 +96,7 @@
mode: SERVER
disabled: true
-
Policy to add dimensions to all Prometheus metrics for the foo namespace:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -133,10 +115,8 @@
request_host:
value: "request.host"
-
Policy to remove the response_code dimension on some Prometheus metrics for
the bar.foo workload:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -171,9 +151,7 @@
response_code:
operation: REMOVE
-
Policy to enable access logging for the entire mesh:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -189,9 +167,7 @@
# cases where a parent configuration has marked as `disabled: true`. In
# those cases, `disabled: false` must be set explicitly to override.
-
Policy to disable access logging for the foo namespace:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -273,7 +249,6 @@ Tracing
Tracing configures tracing behavior for workloads within a mesh.
It can be used to enable/disable tracing, as well as to set sampling
rates and custom tag extraction.
-
Tracing configuration support overrides of the fields providers,
random_sampling_percentage, disable_span_reporting, and custom_tags at
each level in the configuration hierarchy, with missing values filled in
@@ -326,7 +301,6 @@
Tracing
decision has been made (example: no x-b3-sampled tracing header was
present in the requests), the traffic will be selected for telemetry
generation at the percentage specified.
-
Defaults to 0%. Valid values [0.00-100.00]. Can be specified in 0.01%
increments.
@@ -385,7 +359,7 @@ ProviderRef
-No
+Yes
@@ -426,14 +400,14 @@ Metrics
MetricsOverrides[]
Optional. Ordered list of overrides to metrics generation behavior.
-
Specified overrides will be applied in order. They will be applied on
top of inherited overrides from other resources in the hierarchy in the
-following order:
-1. Mesh-scoped overrides
-2. Namespace-scoped overrides
-3. Workload-scoped overrides
-
+following order:
+
+- Mesh-scoped overrides
+- Namespace-scoped overrides
+- Workload-scoped overrides
+
Because overrides are applied in order, users are advised to order their
overrides from least specific to most specific matches. That is, it is
a best practice to list any universal overrides first, with tailored
@@ -522,7 +496,6 @@
MetricsOverrides
Match allows provides the scope of the override. It can be used to select
individual metrics, as well as the workload modes (server and/or client)
in which the metrics will be generated.
-
If match is not specified, the overrides will apply to all metrics for
both modes of operation (client and server).
@@ -554,7 +527,7 @@ MetricsOverrides
The key in the map is the name of the tag.
The value in the map is the operation to perform on the the tag.
WARNING: some providers may not support adding/removing tags.
-See also: https://istio.io/latest/docs/reference/config/metrics/#labels
+See also: https://istio.io/latest/docs/reference/config/metrics/#labels
@@ -670,7 +643,6 @@ Tracing.CustomTag
an operator-supplied value. This value can either be a hard-coded value,
a value taken from an environment variable known to the sidecar proxy, or
from a request header.
-
NOTE: when specified, custom_tags will fully replace any values provided
by parent configuration.
@@ -924,9 +896,7 @@ AccessLogging.Filter
string
CEL expression for selecting when requests/connections should be logged.
-
Examples:
-
response.code >= 400connection.mtls && request.url_path.contains('v1beta3')MetricSelector.IstioMetric
Curated list of known metric types that is supported by Istio metric
providers. See also:
-https://istio.io/latest/docs/reference/config/metrics/#metrics
+https://istio.io/latest/docs/reference/config/metrics/#metrics
@@ -967,11 +937,8 @@ MetricSelector.IstioMetric
Counter of requests to/from an application, generated for HTTP, HTTP/2,
and GRPC traffic.
-
The Prometheus provider exports this metric as: istio_requests_total.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/request_count (SERVER mode)istio.io/service/client/request_count (CLIENT mode)MetricSelector.IstioMetric
Histogram of request durations, generated for HTTP, HTTP/2, and GRPC
traffic.
-
The Prometheus provider exports this metric as:
istio_request_duration_milliseconds.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/response_latencies (SERVER mode)istio.io/service/client/roundtrip_latencies (CLIENT mode)MetricSelector.IstioMetric
Histogram of request body sizes, generated for HTTP, HTTP/2, and GRPC
traffic.
-
The Prometheus provider exports this metric as: istio_request_bytes.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/request_bytes (SERVER mode)istio.io/service/client/request_bytes (CLIENT mode)MetricSelector.IstioMetric
Histogram of response body sizes, generated for HTTP, HTTP/2, and GRPC
traffic.
-
The Prometheus provider exports this metric as: istio_response_bytes.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/response_bytes (SERVER mode)istio.io/service/client/response_bytes (CLIENT mode)MetricSelector.IstioMetric
TCP_OPENED_CONNECTIONS
Counter of TCP connections opened over lifetime of workload.
-
The Prometheus provider exports this metric as:
istio_tcp_connections_opened_total.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/connection_open_count (SERVER mode)istio.io/service/client/connection_open_count (CLIENT mode)MetricSelector.IstioMetric
TCP_CLOSED_CONNECTIONS
Counter of TCP connections closed over lifetime of workload.
-
The Prometheus provider exports this metric as:
istio_tcp_connections_closed_total.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/connection_close_count (SERVER mode)istio.io/service/client/connection_close_count (CLIENT mode)MetricSelector.IstioMetric
TCP_SENT_BYTES
Counter of bytes sent during a response over a TCP connection.
-
The Prometheus provider exports this metric as:
istio_tcp_sent_bytes_total.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/sent_bytes_count (SERVER mode)istio.io/service/client/sent_bytes_count (CLIENT mode)MetricSelector.IstioMetric
TCP_RECEIVED_BYTES
Counter of bytes received during a request over a TCP connection.
-
The Prometheus provider exports this metric as:
istio_tcp_received_bytes_total.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/received_bytes_count (SERVER mode)istio.io/service/client/received_bytes_count (CLIENT mode)MetricSelector.IstioMetric
GRPC_REQUEST_MESSAGES
Counter incremented for every gRPC messages sent from a client.
-
The Prometheus provider exports this metric as:
istio_request_messages_total
@@ -1113,7 +1058,6 @@ MetricSelector.IstioMetric
GRPC_RESPONSE_MESSAGES
Counter incremented for every gRPC messages sent from a server.
-
The Prometheus provider exports this metric as:
istio_response_messages_total
diff --git a/content/en/docs/reference/config/type/workload-selector/index.html b/content/en/docs/reference/config/type/workload-selector/index.html
index ec2818ed29712..3c494d39d60f0 100644
--- a/content/en/docs/reference/config/type/workload-selector/index.html
+++ b/content/en/docs/reference/config/type/workload-selector/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Workload Selector
description: Definition of a workload selector.
location: https://istio.io/docs/reference/config/type/workload-selector.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
number_of_entries: 3
---
diff --git a/content/zh/docs/reference/config/annotations/index.html b/content/zh/docs/reference/config/annotations/index.html
index e3446f8dbc3cd..3cf883b198a3a 100644
--- a/content/zh/docs/reference/config/annotations/index.html
+++ b/content/zh/docs/reference/config/annotations/index.html
@@ -1,6 +1,6 @@
---
-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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Resource Annotations
description: Resource annotations used by Istio.
location: https://istio.io/docs/reference/config/annotations/
diff --git a/content/zh/docs/reference/config/istio.analysis.v1alpha1/index.html b/content/zh/docs/reference/config/istio.analysis.v1alpha1/index.html
index 65f537b02cca2..6f24f5da011f4 100644
--- a/content/zh/docs/reference/config/istio.analysis.v1alpha1/index.html
+++ b/content/zh/docs/reference/config/istio.analysis.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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Analysis Messages
description: Describes the structure of messages generated by Istio analyzers.
location: https://istio.io/docs/reference/config/istio.analysis.v1alpha1.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
weight: 20
number_of_entries: 7
@@ -106,7 +106,7 @@ AnalysisMessageWeakSchema
templatestring
-A go-style template string (https://golang.org/pkg/fmt/#hdr-Printing)
+
A go-style template string (https://golang.org/pkg/fmt/#hdr-Printing)
defining how to combine the args for a particular message into a log line.
Required.
@@ -175,10 +175,10 @@ GenericAnalysisMessage
string[]
A list of strings specifying the resource identifiers that were the cause
-of message generation. A “path” here is a (NAMESPACE\/)?RESOURCETYPE/NAME
+of message generation. A “path” here is a (NAMESPACE/)?RESOURCETYPE/NAME
tuple that uniquely identifies a particular resource. There doesn’t seem to
be a single concept for this, but this is intuitively taken from
-https://kubernetes.io/docs/reference/using-api/api-concepts/#standard-api-terminology
+https://kubernetes.io/docs/reference/using-api/api-concepts/#standard-api-terminology
At least one is required.
diff --git a/content/zh/docs/reference/config/istio.mesh.v1alpha1/index.html b/content/zh/docs/reference/config/istio.mesh.v1alpha1/index.html
index 5df69d2b20357..82eb892f2bf8f 100644
--- a/content/zh/docs/reference/config/istio.mesh.v1alpha1/index.html
+++ b/content/zh/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Global Mesh Options
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
weight: 20
number_of_entries: 55
@@ -308,11 +308,9 @@ MeshConfig
The trust domain aliases represent the aliases of trust_domain.
For example, if we have
-
trustDomain: td1
trustDomainAliases: ["td2", "td3"]
-
Any service with the identity td1/ns/foo/sa/a-service-account, td2/ns/foo/sa/a-service-account,
or td3/ns/foo/sa/a-service-account will be treated the same in the Istio mesh.
@@ -343,15 +341,12 @@ MeshConfig
imported through container registry integrations, e.g. this applies to
Kubernetes Service resources. The value is a list of namespace names and
reserved namespace aliases. The allowed namespace aliases are:
-
* - All Namespaces
. - Current Namespace
~ - No Namespace
-
If not set the system will use “*” as the default value which implies that
services are exported to all namespaces.
-
All namespaces is a reasonable default for implementations that don’t
need to restrict access or visibility of services across namespace
boundaries. If that requirement is present it is generally good practice to
@@ -361,7 +356,6 @@
MeshConfig
is expected to be rare but can have utility for deployments where
dependency management needs to be precise even within the scope of a single
namespace.
-
For further discussion see the reference documentation for ServiceEntry,
Sidecar, and Gateway.
@@ -376,7 +370,6 @@ MeshConfig
The default value for the VirtualService.export_to field. Has the same
syntax as default_service_export_to.
-
If not set the system will use “*” as the default value which implies that
virtual services are exported to all namespaces
@@ -391,7 +384,6 @@ MeshConfig
The default value for the DestinationRule.export_to field. Has the same
syntax as default_service_export_to.
-
If not set the system will use “*” as the default value which implies that
destination rules are exported to all namespaces
@@ -409,7 +401,6 @@ MeshConfig
declarations in that namespace first and if none are found it will
search in the root namespace. Any matching declaration found in the root
namespace is processed as if it were declared in the leaf namespace.
-
The precise semantics of this processing are documented on each resource
type.
@@ -463,18 +454,14 @@ MeshConfig
network filters like TCP and Redis.
By default, Istio emits statistics with the pattern inbound|<port>|<port-name>|<service-FQDN>.
For example inbound|7443|grpc-reviews|reviews.prod.svc.cluster.local. This can be used to override that pattern.
-
A Pattern can be composed of various pre-defined variables. The following variables are supported.
-
%SERVICE% - Will be substituted with name of the service.%SERVICE_FQDN% - Will be substituted with FQDN of the service.%SERVICE_PORT% - Will be substituted with port of the service.%SERVICE_PORT_NAME% - Will be substituted with port name of the service.
-
Following are some examples of supported patterns for reviews:
-
%SERVICE_FQDN%_%SERVICE_PORT% will use reviews.prod.svc.cluster.local_7443 as the stats name.%SERVICE% will use reviews.prod as the stats name.MeshConfig
network filters like TCP and Redis.
By default, Istio emits statistics with the pattern outbound|<port>|<subsetname>|<service-FQDN>.
For example outbound|8080|v2|reviews.prod.svc.cluster.local. This can be used to override that pattern.
-
A Pattern can be composed of various pre-defined variables. The following variables are supported.
-
%SERVICE% - Will be substituted with name of the service.%SERVICE_FQDN% - Will be substituted with FQDN of the service.MeshConfig
%SERVICE_PORT_NAME% - Will be substituted with port name of the service.%SUBSET_NAME% - Will be substituted with subset.
-
Following are some examples of supported patterns for reviews:
-
%SERVICE_FQDN%_%SERVICE_PORT% will use reviews.prod.svc.cluster.local_7443 as the stats name.%SERVICE% will use reviews.prod as the stats name.MeshConfig
by limiting the number of entities (including services, pods, and endpoints) that are watched and processed.
If omitted, Istio will use the default behavior of processing all namespaces in the cluster.
Elements in the list are disjunctive (OR semantics), i.e. a namespace will be included if it matches any selector.
-The following example selects any namespace that matches either below:
-1. The namespace has both of these labels: env: prod and region: us-east1
-2. The namespace has label app equal to cassandra or spark.
-
+The following example selects any namespace that matches either below:
+
+- The namespace has both of these labels:
env: prod and region: us-east1
+- The namespace has label
app equal to cassandra or spark.
+
discoverySelectors:
- matchLabels:
env: prod
@@ -593,7 +577,6 @@ MeshConfig
- cassandra
- spark
-
Refer to the kubernetes selector docs
for additional detail on selector semantics.
@@ -625,7 +608,7 @@ MeshConfig
Configure the default HTTP retry policy.
The default number of retry attempts is set at 2 for these errors:
- “connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes”.
+“connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes”.
Setting the number of attempts to 0 disables retry policy globally.
This setting can be overriden on a per-host basis using the Virtual Service
API.
@@ -760,9 +743,9 @@
MeshConfig.CertificateData
string (oneof)
The SPIFFE bundle endpoint URL that complies to:
-https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE_Trust_Domain_and_Bundle.md#the-spiffe-trust-domain-and-bundle
+https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE_Trust_Domain_and_Bundle.md#the-spiffe-trust-domain-and-bundle
The endpoint should support authentication based on Web PKI:
-https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE_Trust_Domain_and_Bundle.md#521-web-pki
+https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE_Trust_Domain_and_Bundle.md#521-web-pki
The certificate is retrieved from the endpoint.
@@ -874,12 +857,14 @@ MeshConfig.CA
ClientTLSSettings
Use the tls_settings to specify the tls mode to use.
-Regarding tls_settings:
-- DISABLE MODE is legitimate for the case Istiod is making the request via an Envoy sidecar.
-DISABLE MODE can also be used for testing
-- TLS MUTUAL MODE be on by default. If the CA certificates
+Regarding tls_settings:
+
+- DISABLE MODE is legitimate for the case Istiod is making the request via an Envoy sidecar.
+DISABLE MODE can also be used for testing
+- TLS MUTUAL MODE be on by default. If the CA certificates
(cert bundle to verify the CA server’s certificate) is omitted, Istiod will
-use the system root certs to verify the CA server’s certificate.
+use the system root certs to verify the CA server’s certificate.
+
@@ -1100,7 +1085,6 @@ MeshConfig.DefaultProviders
Holds the name references to the providers that will be used by default
in other Istio configuration resources if the provider is not specified.
-
These names must match a provider defined in extension_providers that is
one of the supported tracing providers.
@@ -1228,9 +1212,7 @@ MeshConfig.ServiceSettings.Settings
endpoints to be reachable from any client in any of the clusters which are part of the
mesh. This configuration option limits the set of service endpoints visible to a client
to be cluster scoped.
-
There are some common scenarios when this can be useful:
-
- A service (or group of services) is inherently local to the cluster and has local storage
for that cluster. For example, the kube-system namespace (e.g. the Kube API Server).
@@ -1239,7 +1221,6 @@ MeshConfig.ServiceSettings.Settings
this service-by-service (e.g. mysvc.myns.svc.cluster.local) or as a group
(e.g. *.myns.svc.cluster.local).
-
By default Istio will consider kubernetes.default.svc (i.e. the API Server) as well as all
services in the kube-system namespace to be cluster-local, unless explicitly overridden here.
@@ -1297,8 +1278,8 @@ Mesh
bool
If true, the body sent to the external authorization service in the gRPC authorization request is set with raw bytes
-in the raw_body field (https://github.com/envoyproxy/envoy/blame/cffb095d59d7935abda12b9509bcd136808367bb/api/envoy/service/auth/v3/attribute_context.proto#L153).
-Otherwise, it will be filled with UTF-8 string in the body field (https://github.com/envoyproxy/envoy/blame/cffb095d59d7935abda12b9509bcd136808367bb/api/envoy/service/auth/v3/attribute_context.proto#L147).
+in the raw_body field (https://github.com/envoyproxy/envoy/blame/cffb095d59d7935abda12b9509bcd136808367bb/api/envoy/service/auth/v3/attribute_context.proto#L153).
+Otherwise, it will be filled with UTF-8 string in the body field (https://github.com/envoyproxy/envoy/blame/cffb095d59d7935abda12b9509bcd136808367bb/api/envoy/service/auth/v3/attribute_context.proto#L147).
This field only works with the envoy_ext_authz_grpc provider and has no effect for the envoy_ext_authz_http provider.
@@ -1329,7 +1310,6 @@ Mes
The format is [<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “my-ext-authz.foo.svc.cluster.local” or “bar/my-ext-authz.example.com”.
@@ -1415,17 +1395,20 @@ Mes
string[]
List of client request headers that should be included in the authorization request sent to the authorization service.
-Note that in addition to the headers specified here following headers are included by default:
-1. Host, Method, Path and Content-Length are automatically sent.
-2. Content-Length will be set to 0 and the request will not have a message body. However, the authorization
+Note that in addition to the headers specified here following headers are included by default:
+
+- Host, Method, Path and Content-Length are automatically sent.
+- Content-Length will be set to 0 and the request will not have a message body. However, the authorization
request can include the buffered client request body (controlled by include_request_body_in_check setting),
-consequently the value of Content-Length of the authorization request reflects the size of its payload size.
-
+consequently the value of Content-Length of the authorization request reflects the size of its payload size.
+
Exact, prefix and suffix matches are supported (similar to the authorization policy rule syntax except the presence match
-https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule):
-- Exact match: “abc” will match on value “abc”.
-- Prefix match: “abc*” will match on value “abc” and “abcd”.
-- Suffix match: “*abc” will match on value “abc” and “xabc”.
+https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule):
+
+- Exact match: “abc” will match on value “abc”.
+- Prefix match: “abc*” will match on value “abc” and “abcd”.
+- Suffix match: “*abc” will match on value “abc” and “xabc”.
+
@@ -1464,12 +1447,13 @@ Mes
forwarded to the upstream when the authorization check result is allowed (HTTP code 200).
If not specified, the original request will not be modified and forwarded to backend as-is.
Note, any existing headers will be overridden.
-
Exact, prefix and suffix matches are supported (similar to the authorization policy rule syntax except the presence match
-https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule):
-- Exact match: “abc” will match on value “abc”.
-- Prefix match: “abc*” will match on value “abc” and “abcd”.
-- Suffix match: “*abc” will match on value “abc” and “xabc”.
+https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule):
+
+- Exact match: “abc” will match on value “abc”.
+- Prefix match: “abc*” will match on value “abc” and “abcd”.
+- Suffix match: “*abc” will match on value “abc” and “xabc”.
+
@@ -1487,12 +1471,13 @@ Mes
When a header is included in this list, Path, Status, Content-Length, WWWAuthenticate and Location are
automatically added.
Note, the body from the authorization service is always included in the response to downstream.
-
Exact, prefix and suffix matches are supported (similar to the authorization policy rule syntax except the presence match
-https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule):
-- Exact match: “abc” will match on value “abc”.
-- Prefix match: “abc*” will match on value “abc” and “abcd”.
-- Suffix match: “*abc” will match on value “abc” and “xabc”.
+https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule):
+
+- Exact match: “abc” will match on value “abc”.
+- Prefix match: “abc*” will match on value “abc” and “abcd”.
+- Suffix match: “*abc” will match on value “abc” and “xabc”.
+
@@ -1507,12 +1492,13 @@ Mes
check result is allowed (HTTP code 200).
If not specified, the original response will not be modified and forwarded to downstream as-is.
Note, any existing headers will be overridden.
-
Exact, prefix and suffix matches are supported (similar to the authorization policy rule syntax except the presence match
-https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule):
-- Exact match: “abc” will match on value “abc”.
-- Prefix match: “abc*” will match on value “abc” and “abcd”.
-- Suffix match: “*abc” will match on value “abc” and “xabc”.
+https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule):
+
+- Exact match: “abc” will match on value “abc”.
+- Prefix match: “abc*” will match on value “abc” and “abcd”.
+- Suffix match: “*abc” will match on value “abc” and “xabc”.
+
@@ -1542,7 +1528,6 @@ Mes
The format is [<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “my-ext-authz.foo.svc.cluster.local” or “bar/my-ext-authz.example.com”.
@@ -1635,7 +1620,6 @@ MeshConfig.Extension
The format is [<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “zipkin.default.svc.cluster.local” or “bar/zipkin.example.com”.
@@ -1693,7 +1677,6 @@ MeshConfig.Extens
The format is [<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “lightstep.default.svc.cluster.local” or “bar/lightstep.example.com”.
@@ -1760,7 +1743,6 @@ MeshConfig.Extensio
The format is [<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “datadog.default.svc.cluster.local” or “bar/datadog.example.com”.
@@ -1816,7 +1798,6 @@ MeshConfig.Exten
The format is [<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “skywalking.default.svc.cluster.local” or “bar/skywalking.example.com”.
@@ -1852,7 +1833,6 @@ MeshConfig.Exten
MeshConfig.ExtensionProvider.StackdriverProvider
Defines configuration for Stackdriver.
-
WARNING: Stackdriver tracing uses OpenCensus configuration under the hood and, as a result, cannot be used
alongside any OpenCensus provider configuration. This is due to a limitation in the implementation of OpenCensus
driver in Envoy.
@@ -1896,13 +1876,11 @@ MeshConfig.ExtensionPr
MeshConfig.ExtensionProvider.OpenCensusAgentTracingProvider
Defines configuration for an OpenCensus tracer writing to an OpenCensus backend.
-
WARNING: OpenCensusAgentTracingProviders should be used with extreme care. Configuration of
OpenCensus providers CANNOT be changed during the course of proxy’s lifetime due to a limitation
in the implementation of OpenCensus driver in Envoy. This means only a single provider configuration
may be used for OpenCensus at any given time for a proxy or group of proxies AND that any change to the provider
configuration MUST be accompanied by a restart of all proxies that will use that configuration.
-
NOTE: Stackdriver tracing uses OpenCensus configuraiton under the hood and, as a result, cannot be used
alongside OpenCensus provider configuration.
@@ -1924,7 +1902,6 @@ MeshConfig.
The format is [<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “ocagent.default.svc.cluster.local” or “bar/ocagent.example.com”.
@@ -2040,7 +2017,6 @@ MeshConfig.Exte
The format is [<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “envoy-als.foo.svc.cluster.local” or “bar/envoy-als.example.com”.
@@ -2064,9 +2040,11 @@ MeshConfig.Exte
string
Optional. The friendly name of the access log.
-Defaults:
-- “http_envoy_accesslog”
-- “listener_envoy_accesslog”
+Defaults:
+
+- “http_envoy_accesslog”
+- “listener_envoy_accesslog”
+
@@ -2143,7 +2121,6 @@ MeshConfig.Exten
The format is [<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “envoy-als.foo.svc.cluster.local” or “bar/envoy-als.example.com”.
@@ -2167,9 +2144,11 @@ MeshConfig.Exten
string
Optional. The friendly name of the access log.
-Defaults:
-- “tcp_envoy_accesslog”
-- “listener_envoy_accesslog”
+Defaults:
+
+- “tcp_envoy_accesslog”
+- “listener_envoy_accesslog”
+
@@ -2212,7 +2191,6 @@ MeshConfig.E
The format is [<Namespace>/]<Hostname>. The specification of <Namespace> is required only when it is insufficient
to unambiguously resolve a service in the service registry. The <Hostname> is a fully qualified host name of a
service defined by the Kubernetes service or ServiceEntry.
-
Example: “envoy-als.foo.svc.cluster.local” or “bar/envoy-als.example.com”.
@@ -2236,8 +2214,10 @@ MeshConfig.E
string
Optional. The friendly name of the access log.
-Defaults:
-- “otel_envoy_accesslog”
+Defaults:
+
+- “otel_envoy_accesslog”
+
@@ -2278,11 +2258,10 @@ MeshConfig.Ext
Collection of tag names and tag expressions to include in the log
entry. Conflicts are resolved by the tag name by overriding previously
supplied values.
-
Example:
- labels:
- path: request.url_path
- foo: request.headers[‘x-foo’]
+labels:
+path: request.url_path
+foo: request.headers[‘x-foo’]
@@ -2311,9 +2290,7 @@ MeshC
Textual format for the envoy access logs. Envoy command operators may be
used in the format. The format string documentation
provides more information.
-
-NOTE: Istio will insert a newline (‘\n’) on all formats (if missing).
-
+NOTE: Istio will insert a newline (’\n’) on all formats (if missing).
Example: text: "%LOCAL_REPLY_BODY%:%RESPONSE_CODE%:path=%REQ(:path)%"
@@ -2331,9 +2308,7 @@ MeshC
(see: format dictionaries). Nested JSON is
supported for some command operators (e.g. FILTER_STATE or DYNAMIC_METADATA).
Use labels: {} for default envoy JSON log format.
-
Example:
-
labels:
status: "%RESPONSE_CODE%"
message: "%LOCAL_REPLY_BODY%"
@@ -2385,9 +2360,7 @@ Me
(see: format dictionaries). Nested JSON is
supported for some command operators (e.g. FILTER_STATE or DYNAMIC_METADATA).
Alias to attributes filed in Open Telemetry
-
Example:
-
labels:
status: "%RESPONSE_CODE%"
message: "%LOCAL_REPLY_BODY%"
@@ -2578,24 +2551,19 @@ ProxyConfig
ProxyConfig defines variables for individual Envoy instances. This can be configured on a per-workload basis
as well as by the mesh-wide defaults.
To set the mesh wide defaults, configure the defaultConfig section of meshConfig. For example:
-
meshConfig:
defaultConfig:
discoveryAddress: istiod:15012
-
This can also be configured on a per-workload basis by configuring the proxy.istio.io/config annotation on the pod. For example:
-
annotations:
proxy.istio.io/config: |
discoveryAddress: istiod:15012
-
If both are configured, the two are merged with per field semantics; the field set in annotation will fully replace the field from mesh config defaults.
This is different than a deep merge provided by protobuf.
For example, "tracing": { "sampling": 5 } would completely override a setting configuring a tracing provider
such as "tracing": { "zipkin": { "address": "..." } }.
-
Note: fields in ProxyConfig are not dynamically configured; changes will require restart of workloads to take effect.
@@ -2640,7 +2608,6 @@ ProxyConfig
--service-cluster flag in Envoy. In a typical Envoy deployment, the
service-cluster flag is used to identify the caller, for
source-based routing scenarios.
-
Since Istio does not assign a local service/service version to each
Envoy instance, the name is same for all of them. However, the
source/caller’s identity (e.g., IP address) is encoded in the
@@ -2947,7 +2914,6 @@
ProxyConfig
sidecar.istio.io/statsInclusionSuffixes). For example, to enable stats
for circuit breaker, retry, and upstream connections, you can specify stats
matcher as follow:
-
proxyStatsMatcher:
inclusionRegexps:
- .*circuit_breakers.*
@@ -2955,7 +2921,6 @@ ProxyConfig
- upstream_rq_retry
- upstream_cx
-
Note including more Envoy stats might increase number of time series
collected by prometheus significantly. Care needs to be taken on Prometheus
resource provision and configuration to reduce cardinality.
@@ -3341,9 +3306,7 @@ MeshNetworks
MeshNetworks (config map) provides information about the set of networks
inside a mesh and how to route to endpoints in each network. For example
-
MeshNetworks(file/config map):
-
networks:
network1:
endpoints:
@@ -3389,24 +3352,23 @@ Network.NetworkEndpoints
NetworkEndpoints describes how the network associated with an endpoint
should be inferred. An endpoint will be assigned to a network based on
the following rules:
-
-Implicitly: If the registry explicitly provides information about
+
-
+
Implicitly: If the registry explicitly provides information about
the network to which the endpoint belongs to. In some cases, its
possible to indicate the network associated with the endpoint by
-adding the ISTIO_META_NETWORK environment variable to the sidecar.
-
-Explicitly:
-
+adding the ISTIO_META_NETWORK environment variable to the sidecar.
+
+-
+
Explicitly:
a. By matching the registry name with one of the “fromRegistry”
- in the mesh config. A “from_registry” can only be assigned to a
- single network.
-
+in the mesh config. A “from_registry” can only be assigned to a
+single network.
b. By matching the IP against one of the CIDR ranges in a mesh
- config network. The CIDR ranges must not overlap and be assigned to
- a single network.
-
+config network. The CIDR ranges must not overlap and be assigned to
+a single network.
+
+
(2) will override (1) if both are present.
diff --git a/content/zh/docs/reference/config/istio.operator.v1alpha1/index.html b/content/zh/docs/reference/config/istio.operator.v1alpha1/index.html
index 65502923c5988..f1c5f2147174f 100644
--- a/content/zh/docs/reference/config/istio.operator.v1alpha1/index.html
+++ b/content/zh/docs/reference/config/istio.operator.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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: IstioOperator Options
description: Configuration affecting Istio control plane installation version and shape.
location: https://istio.io/docs/reference/config/istio.operator.v1alpha1.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
weight: 20
number_of_entries: 74
@@ -21,7 +21,6 @@ IstioOperatorSpec
The spec is a used to define a customization of the default profile values that are supplied with each Istio release.
Because the spec is a customization API, specifying an empty IstioOperatorSpec results in a default Istio
component values.
-
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
@@ -53,12 +52,10 @@ IstioOperatorSpec
string
Path or name for the profile e.g.
-
- minimal (looks in profiles dir for a file called minimal.yaml)
- /tmp/istio/install/values/custom/custom-install.yaml (local file path)
-
default profile is used if this field is unset.
@@ -71,7 +68,6 @@ IstioOperatorSpec
string
Path for the install package. e.g.
-
- /tmp/istio-installer/nightly (local file path)
@@ -224,7 +220,6 @@ InstallStatus
Status
Overall status of all components controlled by the operator.
-
- If all components have status
NONE, overall status is NONE.
- If all components are
HEALTHY, overall status is HEALTHY.
@@ -3770,7 +3765,6 @@ google.protobuf.Value
null, a number, a string, a boolean, a recursive struct value, or a
list of values. A producer of value is expected to set one of that
variants, absence of any variant indicates an error.
-
The JSON representation for Value is JSON value.
@@ -3872,7 +3866,7 @@ k8s.io.api.core.v1.Volume
name of the volume.
Must be a DNS_LABEL and unique within the pod.
-More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
+More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
@@ -3950,7 +3944,7 @@ k8s.io.api.core.v1.VolumeMount
string
Path within the volume from which the container’s volume should be mounted.
-Defaults to “” (volume’s root).
+Defaults to "" (volume’s root).
+optional
@@ -3979,7 +3973,7 @@ k8s.io.api.core.v1.VolumeMount
Expanded path within the volume from which the container’s volume should be mounted.
Behaves similarly to SubPath but environment variable references $(VAR_NAME) are expanded using the container’s environment.
-Defaults to “” (volume’s root).
+Defaults to "" (volume’s root).
SubPathExpr and SubPath are mutually exclusive.
+optional
diff --git a/content/zh/docs/reference/config/labels/index.html b/content/zh/docs/reference/config/labels/index.html
index 2bf14acebd388..f23adff55a40e 100644
--- a/content/zh/docs/reference/config/labels/index.html
+++ b/content/zh/docs/reference/config/labels/index.html
@@ -1,6 +1,6 @@
---
-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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Resource Labels
description: Resource labels used by Istio.
location: https://istio.io/docs/reference/config/labels/
diff --git a/content/zh/docs/reference/config/meta/v1beta1/istio-status/index.html b/content/zh/docs/reference/config/meta/v1beta1/istio-status/index.html
index ea2e6136e5d29..48be4f360d77c 100644
--- a/content/zh/docs/reference/config/meta/v1beta1/istio-status/index.html
+++ b/content/zh/docs/reference/config/meta/v1beta1/istio-status/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Istio Status
description: Common status field for all istio collections.
location: https://istio.io/docs/reference/config/meta/v1beta1/istio-status.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
number_of_entries: 2
---
@@ -25,7 +25,7 @@ IstioStatus
IstioCondition[]
Current service state of pod.
-More info: https://istio.io/docs/reference/config/config-status/
+More info: https://istio.io/docs/reference/config/config-status/
+optional
+patchMergeKey=type
+patchStrategy=merge
@@ -55,7 +55,7 @@ IstioStatus
Resource Generation to which the Reconciled Condition refers.
When this value is not equal to the object’s metadata generation, reconciled condition calculation for the current
-generation is still in progress. See https://istio.io/latest/docs/reference/config/config-status/ for more info.
+generation is still in progress. See https://istio.io/latest/docs/reference/config/config-status/ for more info.
+optional
diff --git a/content/zh/docs/reference/config/networking/destination-rule/index.html b/content/zh/docs/reference/config/networking/destination-rule/index.html
index 047efa4780180..83bd9dbb0c453 100644
--- a/content/zh/docs/reference/config/networking/destination-rule/index.html
+++ b/content/zh/docs/reference/config/networking/destination-rule/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Destination Rule
description: Configuration affecting load balancing, outlier detection, etc.
location: https://istio.io/docs/reference/config/networking/destination-rule.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.DestinationRule
aliases: [/zh/docs/reference/config/networking/v1alpha3/destination-rule]
@@ -16,10 +16,8 @@
detection settings to detect and evict unhealthy hosts from the load
balancing pool. For example, a simple load balancing policy for the
ratings service would look as follows:
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -30,11 +28,8 @@
loadBalancer:
simple: LEAST_REQUEST
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -45,19 +40,15 @@
loadBalancer:
simple: LEAST_REQUEST
-
{{}}
{{}}
-
Version specific policies can be specified by defining a named
subset and overriding the settings specified at the service level. The
following rule uses a round robin load balancing policy for all traffic
going to a subset named testversion that is composed of endpoints (e.g.,
pods) with labels (version:v3).
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -75,11 +66,8 @@
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -97,21 +85,16 @@
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
{{}}
-
Note: Policies specified for subsets will not take effect until
a route rule explicitly sends traffic to this subset.
-
Traffic policies can be customized to specific ports as well. The
following rule uses the least connection load balancing policy for all
traffic to port 80, while uses a round robin load balancing setting for
traffic to the port 9080.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -129,11 +112,8 @@
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -151,17 +131,13 @@
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
{{}}
-
Destination Rules can be customized to specific workloads as well.
The following example shows how a destination rule can be applied to a
specific workload using the workloadSelector configuration.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -181,10 +157,8 @@
credentialName: client-credential
mode: MUTUAL
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -204,7 +178,6 @@
credentialName: client-credential
mode: MUTUAL
-
{{}}
{{}}
@@ -232,7 +205,6 @@ DestinationRule
Kubernetes services, Consul services, etc.) and from the hosts
declared by ServiceEntries. Rules defined for
services that do not exist in the service registry will be ignored.
-
Note for Kubernetes users: When short names are used (e.g. “reviews”
instead of “reviews.default.svc.cluster.local”), Istio will interpret
the short name based on the namespace of the rule, not the service. A
@@ -241,7 +213,6 @@
DestinationRule
the actual namespace associated with the reviews service. To avoid
potential misconfigurations, it is recommended to always use fully
qualified domain names over short names.
-
Note that the host field applies to both HTTP and TCP services.
@@ -284,10 +255,8 @@ DestinationRule
other namespaces. This feature provides a mechanism for service owners
and mesh administrators to control the visibility of destination rules
across namespace boundaries.
-
If no namespaces are specified then the destination rule is exported to all
namespaces by default.
-
The value “.” is reserved and defines an export to the same namespace that
the destination rule is declared in. Similarly, the value “*” is reserved and
defines an export to all namespaces.
@@ -302,13 +271,13 @@ DestinationRule
WorkloadSelector
Criteria used to select the specific set of pods/VMs on which this
- DestinationRule configuration should be applied. If specified, the DestinationRule
- configuration will be applied only to the workload instances matching the workload selector
- label in the same namespace. Workload selectors do not apply across namespace boundaries.
- If omitted, the DestinationRule falls back to its default behavior.
- For example, if specific sidecars need to have egress TLS settings for services outside
- of the mesh, instead of every sidecar in the mesh needing to have the
- configuration (which is the default behaviour), a workload selector can be specified.
+DestinationRule configuration should be applied. If specified, the DestinationRule
+configuration will be applied only to the workload instances matching the workload selector
+label in the same namespace. Workload selectors do not apply across namespace boundaries.
+If omitted, the DestinationRule falls back to its default behavior.
+For example, if specific sidecars need to have egress TLS settings for services outside
+of the mesh, instead of every sidecar in the mesh needing to have the
+configuration (which is the default behaviour), a workload selector can be specified.
@@ -418,10 +387,8 @@ Subset
uses a round robin load balancing policy for all traffic going to a
subset named testversion that is composed of endpoints (e.g., pods) with
labels (version:v3).
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -439,11 +406,8 @@ Subset
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -461,13 +425,10 @@ Subset
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
{{}}
-
Note: Policies specified for subsets will not take effect until
a route rule explicitly sends traffic to this subset.
-
One or more labels are typically required to identify the subset destination,
however, when the corresponding DestinationRule represents a host that
supports multiple SNI hosts (e.g., an egress gateway), a subset without labels
@@ -531,13 +492,10 @@
LoadBalancerSettings
load balancing
documentation
for more details.
-
For example, the following rule uses a round robin load balancing policy
for all traffic going to the ratings service.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -548,11 +506,8 @@ LoadBalancerSettings
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -563,17 +518,13 @@ LoadBalancerSettings
loadBalancer:
simple: ROUND_ROBIN
-
{{}}
{{}}
-
The following example sets up sticky sessions for the ratings service
hashing-based load balancer for the same ratings service using the
the User cookie as the hash key.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -587,11 +538,8 @@ LoadBalancerSettings
name: user
ttl: 0s
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -605,7 +553,6 @@ LoadBalancerSettings
name: user
ttl: 0s
-
{{}}
{{}}
@@ -674,13 +621,10 @@ ConnectionPoolSettings
breaker
for more details. Connection pool settings can be applied at the TCP
level as well as at HTTP level.
-
For example, the following rule sets a limit of 100 connections to redis
service called myredissrv with a connect timeout of 30ms
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -696,11 +640,8 @@ ConnectionPoolSettings
time: 7200s
interval: 75s
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -716,7 +657,6 @@ ConnectionPoolSettings
time: 7200s
interval: 75s
-
{{}}
{{}}
@@ -766,16 +706,13 @@ OutlierDetection
consecutive errors metric. See Envoy’s outlier
detection
for more details.
-
The following rule sets a connection pool size of 100 HTTP1 connections
with no more than 10 req/connection to the “reviews” service. In addition,
it sets a limit of 1000 concurrent HTTP2 requests and configures upstream
hosts to be scanned every 5 mins so that any host that fails 7 consecutive
times with a 502, 503, or 504 error code will be ejected for 15 minutes.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -794,11 +731,8 @@ OutlierDetection
interval: 5m
baseEjectionTime: 15m
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -817,7 +751,6 @@ OutlierDetection
interval: 5m
baseEjectionTime: 15m
-
{{}}
{{}}
@@ -872,7 +805,6 @@ OutlierDetection
an opaque TCP connection, connect timeouts and connection error/failure
events qualify as a gateway error.
This feature is disabled by default or when set to the value 0.
-
Note that consecutive_gateway_errors and consecutive_5xx_errors can be
used separately or together. Because the errors counted by
consecutive_gateway_errors are also included in consecutive_5xx_errors,
@@ -894,7 +826,6 @@
OutlierDetection
timeouts, connection error/failure and request failure events qualify as a
5xx error.
This feature defaults to 5 but can be disabled by setting the value to 0.
-
Note that consecutive_gateway_errors and consecutive_5xx_errors can be
used separately or together. Because the errors counted by
consecutive_gateway_errors are also included in consecutive_5xx_errors,
@@ -971,13 +902,10 @@
ClientTLSSettings
SSL/TLS related settings for upstream connections. See Envoy’s TLS
context
for more details. These settings are common to both HTTP and TCP upstreams.
-
For example, the following rule configures a client to use mutual TLS
for connections to upstream database cluster.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -991,11 +919,8 @@ ClientTLSSettings
privateKey: /etc/certs/client_private_key.pem
caCertificates: /etc/certs/rootcacerts.pem
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -1009,16 +934,12 @@ ClientTLSSettings
privateKey: /etc/certs/client_private_key.pem
caCertificates: /etc/certs/rootcacerts.pem
-
{{}}
{{}}
-
The following rule configures a client to use TLS when talking to a
foreign service whose domain matches *.foo.com.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -1029,11 +950,8 @@ ClientTLSSettings
tls:
mode: SIMPLE
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -1044,16 +962,12 @@ ClientTLSSettings
tls:
mode: SIMPLE
-
{{}}
{{}}
-
The following rule configures a client to use Istio mutual TLS when talking
to rating services.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -1064,11 +978,8 @@ ClientTLSSettings
tls:
mode: ISTIO_MUTUAL
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -1079,7 +990,6 @@ ClientTLSSettings
tls:
mode: ISTIO_MUTUAL
-
{{}}
{{}}
@@ -1160,7 +1070,6 @@ ClientTLSSettings
ca.crt key for CA certificates is also supported.
Only one of client certificates and CA certificate
or credentialName can be specified.
-
NOTE: This field is applicable at sidecars only if
DestinationRule has a workloadSelector specified.
Otherwise the field will be applicable only at gateways, and
@@ -1214,7 +1123,6 @@
ClientTLSSettings
but no verification is desired for a specific host. If enabled with or
without VerifyCertAtClient enabled, verification of the CA signature and
SAN will be skipped.
-
InsecureSkipVerify is false by default.
VerifyCertAtClient is false by default in Istio version 1.9 but will
be true by default in a later version where, going forward, it will be
@@ -1237,7 +1145,6 @@
LocalityLoadBalancerSetting
{region}/{zone}/{sub-zone} form. For additional detail refer to
Locality Weight
The following example shows how to setup locality weights mesh-wide.
-
Given a mesh with workloads and their service deployed to “us-west/zone1/”
and “us-west/zone2/”. This example specifies that when traffic accessing a
service originates from workloads in “us-west/zone1/”, 80% of the traffic
@@ -1245,7 +1152,6 @@ LocalityLoadBalancerSetting
remaining 20% will go to endpoints in “us-west/zone2/”. This setup is
intended to favor routing traffic to endpoints in the same locality.
A similar setting is specified for traffic originating in “us-west/zone2/”.
-
distribute:
- from: us-west/zone1/*
to:
@@ -1256,25 +1162,21 @@ LocalityLoadBalancerSetting
"us-west/zone1/*": 20
"us-west/zone2/*": 80
-
If the goal of the operator is not to distribute load across zones and
regions but rather to restrict the regionality of failover to meet other
operational requirements an operator can set a ‘failover’ policy instead of
a ‘distribute’ policy.
-
The following example sets up a locality failover policy for regions.
Assume a service resides in zones within us-east, us-west & eu-west
this example specifies that when endpoints within us-east become unhealthy
traffic should failover to endpoints in any zone or sub-zone within eu-west
and similarly us-west should failover to us-east.
-
failover:
- from: us-east
to: eu-west
- from: us-west
to: us-east
-
Locality load balancing settings.
@@ -1322,19 +1224,15 @@ LocalityLoadBalancerSetting
failoverPriority is an ordered list of labels used to sort endpoints to do priority based load balancing.
This is to support traffic failover across different groups of endpoints.
Suppose there are total N labels specified:
-
- Endpoints matching all N labels with the client proxy have priority P(0) i.e. the highest priority.
- Endpoints matching the first N-1 labels with the client proxy have priority P(1) i.e. second highest priority.
- By extension of this logic, endpoints matching only the first label with the client proxy has priority P(N-1) i.e. second lowest priority.
- All the other endpoints have priority P(N) i.e. lowest priority.
-
Note: For a label to be considered for match, the previous labels must match, i.e. nth label would be considered matched only if first n-1 labels match.
-
It can be any label specified on both client and server workloads.
The following labels which have special semantic meaning are also supported:
-
topology.istio.io/network is used to match the network metadata of an endpoint, which can be specified by pod/namespace label topology.istio.io/network, sidecar env ISTIO_META_NETWORK or MeshNetworks.topology.istio.io/cluster is used to match the clusterID of an endpoint, which can be specified by pod label topology.istio.io/cluster or pod env ISTIO_META_CLUSTER_ID.LocalityLoadBalancerSetting
topology.kubernetes.io/zone is used to match the zone metadata of an endpoint, which maps to Kubernetes node label topology.kubernetes.io/zone or the deprecated label failure-domain.beta.kubernetes.io/zone.topology.istio.io/subzone is used to match the subzone metadata of an endpoint, which maps to Istio node label topology.istio.io/subzone.
-
The below topology config indicates the following priority levels:
-
failoverPriority:
- "topology.istio.io/network"
- "topology.kubernetes.io/region"
- "topology.kubernetes.io/zone"
- "topology.istio.io/subzone"
-
- endpoints match same [network, region, zone, subzone] label with the client proxy have the highest priority.
- endpoints have same [network, region, zone] label but different [subzone] label with the client proxy have the second highest priority.
@@ -1359,7 +1254,6 @@ LocalityLoadBalancerSetting
- endpoints have same [network] but different [region] labels with the client proxy have the fourth highest priority.
- all the other endpoints have the same lowest priority.
-
Optional: only one of distribute, failover or failoverPriority can be set.
And it should be used together with OutlierDetection to detect unhealthy endpoints, otherwise has no effect.
@@ -1474,8 +1368,8 @@ TrafficPolicy.TunnelSettings
Specifies which protocol to use for tunneling the downstream connection.
Supported protocols are:
- CONNECT - uses HTTP CONNECT;
- POST - uses HTTP POST.
+CONNECT - uses HTTP CONNECT;
+POST - uses HTTP POST.
CONNECT is used by default if not specified.
HTTP version for upstream requests is determined by the service protocol defined for the proxy.
@@ -1803,7 +1697,7 @@ ConnectionPoolSettings.HTTPSettings
Maximum number of requests that will be queued while waiting for
a ready connection pool connection. Default 1024.
-Refer to https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/circuit_breaking
+Refer to https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/circuit_breaking
under which conditions a new connection is created for HTTP2.
Please note that this is applicable to both HTTP/1.1 and HTTP2.
@@ -1952,14 +1846,11 @@ ConnectionPoolSettings.
LocalityLoadBalancerSetting.Distribute
Describes how traffic originating in the ‘from’ zone or sub-zone is
-distributed over a set of ‘to’ zones. Syntax for specifying a zone is
+distributed over a set of ’to’ zones. Syntax for specifying a zone is
{region}/{zone}/{sub-zone} and terminal wildcards are allowed on any
segment of the specification. Examples:
-
* - matches all localities
-
us-west/* - all zones and sub-zones within the us-west region
-
us-west/zone-1/* - all sub-zones within us-west/zone-1
@@ -2048,7 +1939,6 @@ LocalityLoadBalancerSetting.Failov
google.protobuf.UInt32Value
Wrapper message for uint32.
-
The JSON representation for UInt32Value is JSON number.
diff --git a/content/zh/docs/reference/config/networking/envoy-filter/index.html b/content/zh/docs/reference/config/networking/envoy-filter/index.html
index 4f5e0e4f5f747..99a38866971cc 100644
--- a/content/zh/docs/reference/config/networking/envoy-filter/index.html
+++ b/content/zh/docs/reference/config/networking/envoy-filter/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Envoy Filter
description: Customizing Envoy configuration generated by Istio.
location: https://istio.io/docs/reference/config/networking/envoy-filter.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.EnvoyFilter
aliases: [/zh/docs/reference/config/networking/v1alpha3/envoy-filter]
@@ -22,7 +22,6 @@
in the config root
namespace,
followed by all matching EnvoyFilters in the workload’s namespace.
-
NOTE 1: Some aspects of this API are deeply tied to the internal
implementation in Istio networking subsystem as well as Envoy’s XDS
API. While the EnvoyFilter API by itself will maintain backward
@@ -30,25 +29,21 @@
mechanism should be carefully monitored across Istio proxy version
upgrades, to ensure that deprecated fields are removed and replaced
appropriately.
-
NOTE 2: When multiple EnvoyFilters are bound to the same
workload in a given namespace, all patches will be processed
sequentially in order of creation time. The behavior is undefined
if multiple EnvoyFilter configurations conflict with each other.
-
NOTE 3: To apply an EnvoyFilter resource to all workloads
(sidecars and gateways) in the system, define the resource in the
config root
namespace,
without a workloadSelector.
-
The example below declares a global default EnvoyFilter resource in
the root namespace called istio-config, that adds a custom
protocol filter on all sidecars in the system, for outbound port
9307. The filter should be added before the terminating tcp_proxy
filter to take effect. In addition, it sets a 30s idle timeout for
all HTTP connections in both gateways and sidecars.
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -88,14 +83,12 @@
common_http_protocol_options:
idle_timeout: 30s
-
The following example enables Envoy’s Lua filter for all inbound
HTTP calls arriving at service port 8080 of the reviews service pod
with labels “app: reviews”, in the bookinfo namespace. The lua
filter calls out to an external service internal.org.net:8888 that
requires a special cluster definition in envoy. The cluster is also
added to the sidecar as part of this configuration.
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -159,12 +152,10 @@
address: "internal.org.net"
port_value: 8888
-
The following example overwrites certain fields (HTTP idle timeout
and X-Forward-For trusted hops) in the HTTP connection manager in a
listener on the ingress gateway in istio-system namespace for the
SNI host app.example.com:
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -192,11 +183,9 @@
common_http_protocol_options:
idle_timeout: 30s
-
The following example inserts an attributegen filter
that produces istio_operationId attribute which is consumed
by the istio.stats filter. filterClass: STATS encodes this dependency.
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -237,9 +226,7 @@
code:
local: { inline_string: "envoy.wasm.attributegen" }
-
The following example inserts an http ext_authz filter in the myns namespace.
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -264,12 +251,10 @@
- key: foo
value: myauth.acme # required by local ext auth server.
-
A workload in the myns namespace needs to access a different ext_auth server
that does not accept initial metadata. Since proto merge cannot remove fields, the
following configuration uses the REPLACE operation. If you do not need to inherit
fields, REPLACE is preferred over MERGE.
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -293,9 +278,7 @@
envoy_grpc:
cluster_name: acme-ext-authz-alt
-
The following example deploys a Wasm extension for all inbound sidecar HTTP requests.
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -348,12 +331,10 @@
ads: {}
type_urls: ["type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm"]
-
The following example adds a Wasm service extension for all proxies using a locally available Wasm file.
The singleton Wasm extension is used to maintain a shared state between workers executing Wasm filters.
For example, a local rate limit extension would rely on a singleton to limit requests across all workers.
As another example, an authorization Wasm extension can use a singleton to maintain a database of accounts.
-
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
@@ -437,14 +418,11 @@ EnvoyFilter
Patch sets in the root namespace are applied before the patch sets in the
workload namespace. Patches within a patch set are processed in the order
that they appear in the configPatches list.
-
The default value for priority is 0 and the range is [ min-int32, max-int32 ].
A patch set with a negative priority is processed before the default. A patch
set with a positive priority is processed after the default.
-
It is recommended to start with priority values that are multiples of 10
to leave room for further insertion.
-
Patch sets are sorted in the following ascending key order:
priority, creation time, fully qualified resource name.
@@ -1041,9 +1019,7 @@ EnvoyFilter.ListenerMatch.Fi
chain match. This value will be compared against the
transport protocol of a new connection, when it’s detected by
the tls_inspector listener filter.
-
Accepted values include:
-
raw_buffer - default, used when no transport protocol is detected.tls - set when TLS protocol is detected by the TLS inspector.EnvoyFilter.ListenerMatch.Fi
filter chain match. This value will be compared against the
application protocols of a new connection, when it’s detected
by one of the listener filters such as the http_inspector.
-
Accepted values include: h2, http/1.1, http/1.0
diff --git a/content/zh/docs/reference/config/networking/gateway/index.html b/content/zh/docs/reference/config/networking/gateway/index.html
index 62570d2ac9bdd..b26944779ea6a 100644
--- a/content/zh/docs/reference/config/networking/gateway/index.html
+++ b/content/zh/docs/reference/config/networking/gateway/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Gateway
description: Configuration affecting edge load balancer.
location: https://istio.io/docs/reference/config/networking/gateway.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.Gateway
aliases: [/zh/docs/reference/config/networking/v1alpha3/gateway]
@@ -14,18 +14,14 @@
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.
-
For example, the following Gateway configuration sets up a proxy to act
as a load balancer exposing port 80 and 9080 (http), 443 (https),
9443(https) and port 2379 (TCP) for ingress. The gateway will be
-applied to the proxy running on a pod with labels app:
-my-gateway-controller. While Istio will configure the proxy to listen
+applied to the proxy running on a pod with labels app: my-gateway-controller. 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.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@@ -77,11 +73,8 @@
hosts:
- "*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
@@ -133,14 +126,11 @@
hosts:
- "*"
-
{{}}
{{}}
-
The Gateway specification above describes the L4-L6 properties of a load
balancer. A VirtualService can then be bound to a gateway to control
the forwarding of traffic arriving at a particular host or gateway port.
-
For example, the following VirtualService splits traffic for
https://uk.bookinfo.com/reviews, https://eu.bookinfo.com/reviews,
http://uk.bookinfo.com:9080/reviews,
@@ -151,10 +141,8 @@
requests to the “reviews.prod.svc.cluster.local” service. This rule is
applicable across ports 443, 9080. Note that http://uk.bookinfo.com
gets redirected to https://uk.bookinfo.com (i.e. 80 redirects to 443).
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -191,11 +179,8 @@
host: reviews.qa.svc.cluster.local
weight: 20
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -232,18 +217,14 @@
host: reviews.qa.svc.cluster.local
weight: 20
-
{{}}
{{}}
-
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 mesh.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -263,11 +244,8 @@
port:
number: 5555
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -287,19 +265,15 @@
port:
number: 5555
-
{{}}
{{}}
-
It is possible to restrict the set of virtual services that can bind to
a gateway server using the namespace/hostname syntax in the hosts field.
For example, the following Gateway allows any virtual service in the ns1
namespace to bind to it, while restricting only the virtual service with
foo.bar.com host in the ns2 namespace to bind to it.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@@ -317,11 +291,8 @@
- "ns1/*"
- "ns2/foo.bar.com"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
@@ -339,7 +310,6 @@
- "ns1/*"
- "ns2/foo.bar.com"
-
{{}}
{{}}
@@ -398,10 +368,8 @@ Server
Server describes the properties of the proxy on a given load balancer
port. For example,
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@@ -417,11 +385,8 @@ Server
hosts:
- "*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
@@ -437,15 +402,11 @@ Server
hosts:
- "*"
-
{{}}
{{}}
-
Another example
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@@ -461,11 +422,8 @@ Server
hosts:
- "*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
@@ -481,15 +439,11 @@ Server
hosts:
- "*"
-
{{}}
{{}}
-
The following is an example of TLS configuration for port 443
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@@ -508,11 +462,8 @@ Server
mode: SIMPLE
credentialName: tls-cert
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
@@ -531,7 +482,6 @@ Server
mode: SIMPLE
credentialName: tls-cert
-
{{}}
{{}}
@@ -587,14 +537,12 @@ Server
a wildcard character in the left-most component (e.g., prod/*.example.com).
Set the dnsName to * to select all VirtualService hosts from the
specified namespace (e.g.,prod/*).
-
The namespace can be set to * or ., representing any or the current
namespace, respectively. For example, */foo.example.com selects the
service from any available namespace while ./foo.example.com only selects
the service from the namespace of the sidecar. The default, if no namespace/
is specified, is */, that is, select services from any namespace.
Any associated DestinationRule in the selected namespace will also be used.
-
A VirtualService must be bound to the gateway and 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’s hosts. For
@@ -602,7 +550,6 @@
Server
VirtualService with hosts dev.example.com or prod.example.com will
match. However, a VirtualService with host example.com or
newexample.com will not match.
-
NOTE: Only virtual services exported to the gateway’s namespace
(e.g., exportTo value of *) can be referenced.
Private configurations (e.g., exportTo set to .) will not be
@@ -789,8 +736,7 @@
ServerTLSSettings
For gateways running on Kubernetes, the name of the secret that
holds the TLS certs including the CA certificates. Applicable
only on Kubernetes. The secret (of type generic) should
-contain the following keys and values: key:
-<privateKey> and cert: <serverCert>. For mutual TLS,
+contain the following keys and values: key: <privateKey> and cert: <serverCert>. For mutual TLS,
cacert: <CACertificate> can be provided in the same secret or
a separate secret named <secret>-cacert.
Secret of type tls for server certificates along with
diff --git a/content/zh/docs/reference/config/networking/proxy-config/index.html b/content/zh/docs/reference/config/networking/proxy-config/index.html
index 866d9897db11f..c4460dfbf28ed 100644
--- a/content/zh/docs/reference/config/networking/proxy-config/index.html
+++ b/content/zh/docs/reference/config/networking/proxy-config/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: ProxyConfig
description: Provides configuration for individual workloads.
location: https://istio.io/docs/reference/config/networking/proxy-config.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1beta1.ProxyConfig
aliases: [/zh/docs/reference/config/networking/v1beta1/proxy-config]
@@ -13,18 +13,13 @@
ProxyConfig exposes proxy level configuration options. ProxyConfig can be configured on a per-workload basis,
a per-namespace basis, or mesh-wide. ProxyConfig is not a required resource; there are default values in place, which are documented
inline with each field.
-
NOTE: fields in ProxyConfig are not dynamically configured - changes will require restart of workloads to take effect.
-
For any namespace, including the root configuration namespace, it is only valid
to have a single workload selector-less ProxyConfig resource.
-
For resources with a workload selector, it is only valid to have one resource selecting
any given workload.
-
For mesh level configuration, put the resource in the root configuration namespace for
your Istio installation without a workload selector:
-
apiVersion: networking.istio.io/v1beta1
kind: ProxyConfig
metadata:
@@ -35,9 +30,7 @@
image:
imageType: distroless
-
For namespace level configuration, put the resource in the desired namespace without a workload selector:
-
apiVersion: networking.istio.io/v1beta1
kind: ProxyConfig
metadata:
@@ -46,9 +39,7 @@
spec:
concurrency: 0
-
For workload level configuration, set the selector field on the ProxyConfig resource:
-
apiVersion: networking.istio.io/v1beta1
kind: ProxyConfig
metadata:
@@ -62,7 +53,6 @@
image:
imageType: debug
-
If a ProxyConfig CR is defined that matches a workload it will merge with its proxy.istio.io/config annotation if present,
with the CR taking precedence over the annotation for overlapping fields. Similarly, if a mesh wide ProxyConfig CR is defined and
meshConfig.DefaultConfig is set, the two resources will be merged with the CR taking precedence for overlapping fields.
diff --git a/content/zh/docs/reference/config/networking/service-entry/index.html b/content/zh/docs/reference/config/networking/service-entry/index.html
index 2088e61c6f524..9fd6d7fcf46d1 100644
--- a/content/zh/docs/reference/config/networking/service-entry/index.html
+++ b/content/zh/docs/reference/config/networking/service-entry/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Service Entry
description: Configuration affecting service registry.
location: https://istio.io/docs/reference/config/networking/service-entry.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.ServiceEntry
aliases: [/zh/docs/reference/config/networking/v1alpha3/service-entry]
@@ -25,14 +25,11 @@
service allows for migration of services from VMs to Kubernetes
without having to change the existing DNS names associated with the
services.
-
The following example declares a few external APIs accessed by internal
applications over HTTPS. The sidecar inspects the SNI value in the
ClientHello message to route to the appropriate external service.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -49,11 +46,8 @@
protocol: TLS
resolution: DNS
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -70,18 +64,14 @@
protocol: TLS
resolution: DNS
-
{{}}
{{}}
-
The following configuration adds a set of MongoDB instances running on
unmanaged VMs to Istio’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.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -101,11 +91,8 @@
- address: 2.2.2.2
- address: 3.3.3.3
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -125,15 +112,11 @@
- address: 2.2.2.2
- address: 3.3.3.3
-
{{}}
{{}}
-
and the associated DestinationRule
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -147,11 +130,8 @@
privateKey: /etc/certs/client_private_key.pem
caCertificates: /etc/certs/rootcacerts.pem
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -165,17 +145,13 @@
privateKey: /etc/certs/client_private_key.pem
caCertificates: /etc/certs/rootcacerts.pem
-
{{}}
{{}}
-
The following example uses a combination of service entry and TLS
routing in a virtual service to steer traffic based on the SNI value to
an internal egress firewall.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -191,11 +167,8 @@
protocol: TLS
resolution: NONE
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -211,15 +184,11 @@
protocol: TLS
resolution: NONE
-
{{}}
{{}}
-
And the associated VirtualService to route based on the SNI value.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -237,11 +206,8 @@
- destination:
host: internal-egress-firewall.ns1.svc.cluster.local
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -259,25 +225,20 @@
- destination:
host: internal-egress-firewall.ns1.svc.cluster.local
-
{{}}
{{}}
-
The virtual service with TLS match serves to override the default SNI
match. In the absence of a virtual service, traffic will be forwarded to
the wikipedia domains.
-
The following example demonstrates the use of a dedicated egress gateway
through which all external service traffic is forwarded.
-The ‘exportTo’ field allows for control over the visibility of a service
+The ’exportTo’ 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 “.”, so that it cannot be used by other
namespaces.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -295,11 +256,8 @@
protocol: HTTP
resolution: DNS
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -317,15 +275,11 @@
protocol: HTTP
resolution: DNS
-
{{}}
{{}}
-
Define a gateway to handle all egress traffic.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@@ -342,11 +296,8 @@
hosts:
- "*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
@@ -363,20 +314,16 @@
hosts:
- "*"
-
{{}}
{{}}
-
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.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -406,11 +353,8 @@
- destination:
host: example.com
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -440,18 +384,14 @@
- destination:
host: example.com
-
{{}}
{{}}
-
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 NONE.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -466,11 +406,8 @@
protocol: HTTP
resolution: NONE
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -485,17 +422,13 @@
protocol: HTTP
resolution: NONE
-
{{}}
{{}}
-
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.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -512,11 +445,8 @@
endpoints:
- address: unix:///var/run/example/socket
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -533,10 +463,8 @@
endpoints:
- address: unix:///var/run/example/socket
-
{{}}
{{}}
-
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
@@ -544,10 +472,8 @@
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
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -572,11 +498,8 @@
ports:
http: 7080
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -601,22 +524,17 @@
ports:
http: 7080
-
{{}}
{{}}
-
With HTTP_PROXY=http://localhost/, calls from the application to
http://foo.bar.com will be load balanced across the three domains
specified above. In other words, a call to http://foo.bar.com/baz would
be translated to http://uk.foo.bar.com/baz.
-
The following example illustrates the usage of a ServiceEntry
containing a subject alternate name
whose format conforms to the SPIFFE standard:
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -637,11 +555,8 @@
subjectAltNames:
- "spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -662,10 +577,8 @@
subjectAltNames:
- "spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account"
-
{{}}
{{}}
-
The following example demonstrates the use of ServiceEntry with a
workloadSelector to handle the migration of a service
details.bookinfo.com from VMs to Kubernetes. The service has two
@@ -677,10 +590,8 @@
details-legacy service account. The sidecar receives HTTP traffic
on port 80 (wrapped in istio mutual TLS) and forwards it to the
application on the localhost on the same port.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
@@ -703,11 +614,8 @@
app: details
instance-id: vm2
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: WorkloadEntry
metadata:
@@ -730,18 +638,14 @@
app: details
instance-id: vm2
-
{{}}
{{}}
-
Assuming there is also a Kubernetes deployment with pod labels
app: details using the same service account details, the
following service entry declares a service spanning both VMs and
Kubernetes:
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -759,11 +663,8 @@
labels:
app: details
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -781,7 +682,6 @@
labels:
app: details
-
{{}}
{{}}
@@ -806,18 +706,15 @@ ServiceEntry
The hosts associated with the ServiceEntry. Could be a DNS
name with wildcard prefix.
-
- The hosts field is used to select matching hosts in VirtualServices and DestinationRules.
- For HTTP traffic the HTTP Host/Authority header will be matched against the hosts field.
- For HTTPs or TLS traffic containing Server Name Indication (SNI), the SNI value
will be matched against the hosts field.
-
NOTE 1: When resolution is set to type DNS and no endpoints
are specified, the host field will be used as the DNS name of the
endpoint to route traffic to.
-
NOTE 2: If the hostname matches with the name of a service
from another service registry such as Kubernetes that also
supplies its own set of endpoints, the ServiceEntry will be
@@ -825,7 +722,6 @@
ServiceEntry
service. Properties in the service entry will be added to the
Kubernetes service if applicable. Currently, the only the
following additional properties will be considered by istiod:
-
- subjectAltNames: In addition to verifying the SANs of the
service accounts associated with the pods of the service, the
@@ -937,14 +833,11 @@
ServiceEntry
other namespaces. This feature provides a mechanism for service owners
and mesh administrators to control the visibility of services across
namespace boundaries.
-
If no namespaces are specified then the service is exported to all
namespaces by default.
-
The value “.” is reserved and defines an export to the same namespace that
the service is declared in. Similarly the value “*” is reserved and
defines an export to all namespaces.
-
For a Kubernetes Service, the equivalent effect can be achieved by setting
the annotation “networking.istio.io/exportTo” to a comma-separated list
of namespace names.
@@ -960,7 +853,6 @@ ServiceEntry
If specified, the proxy will verify that the server certificate’s
subject alternate name matches one of the specified values.
-
NOTE: When using the workloadEntry with workloadSelectors, the
service account specified in the workloadEntry will also be used
to derive the additional subject alternate names that should be
diff --git a/content/zh/docs/reference/config/networking/sidecar/index.html b/content/zh/docs/reference/config/networking/sidecar/index.html
index 81d5dc21dcb92..c4e1c50ddff57 100644
--- a/content/zh/docs/reference/config/networking/sidecar/index.html
+++ b/content/zh/docs/reference/config/networking/sidecar/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Sidecar
description: Configuration affecting network reachability of a sidecar.
location: https://istio.io/docs/reference/config/networking/sidecar.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.Sidecar
aliases: [/zh/docs/reference/config/networking/v1alpha3/sidecar]
@@ -20,7 +20,6 @@
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 workload instances.
-
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
configuration in a namespace will apply to one or more workload instances in the same
@@ -30,7 +29,6 @@
workload instance, preference will be given to the resource with a
workloadSelector that selects this workload instance, over a Sidecar configuration
without any workloadSelector.
-
NOTE 1: Each namespace can have only one Sidecar
configuration without any workloadSelector that specifies the
default for all pods in that namespace. It is recommended to use
@@ -39,22 +37,18 @@
configurations exist in a given namespace. The behavior of the
system is undefined if two or more Sidecar configurations with a
workloadSelector select the same workload instance.
-
NOTE 2: A Sidecar configuration in the MeshConfig
root namespace
will be applied by default to all namespaces without a Sidecar
configuration. This global default Sidecar configuration should not have
any workloadSelector.
-
The example below declares a global default Sidecar configuration
in the root namespace called istio-config, that configures
sidecars in all namespaces to allow egress traffic only to other
workloads in the same namespace as well as to services in the
istio-system namespace.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
@@ -66,11 +60,8 @@
- "./*"
- "istio-system/*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
@@ -82,19 +73,15 @@
- "./*"
- "istio-system/*"
-
{{}}
{{}}
-
The example below declares a Sidecar configuration in the
prod-us1 namespace that overrides the global default defined
above, and configures the sidecars in the namespace to allow egress
traffic to public services in the prod-us1, prod-apis, and the
istio-system namespaces.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
@@ -107,11 +94,8 @@
- "prod-apis/*"
- "istio-system/*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
@@ -124,10 +108,8 @@
- "prod-apis/*"
- "istio-system/*"
-
{{}}
{{}}
-
The following example declares a Sidecar configuration in the
prod-us1 namespace for all pods with labels app: ratings
belonging to the ratings.prod-us1 service. The workload accepts
@@ -136,10 +118,8 @@
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.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
@@ -165,11 +145,8 @@
- hosts:
- "istio-system/*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
@@ -195,10 +172,8 @@
- hosts:
- "istio-system/*"
-
{{}}
{{}}
-
If the workload is deployed without IPTables-based traffic capture,
the Sidecar configuration is the only way to configure the ports
on the proxy attached to the workload instance. The following
@@ -213,10 +188,8 @@
the application to communicate with a backing MySQL database on
127.0.0.1:3306, that then gets proxied to the externally hosted
MySQL service at mysql.foo.com:3306.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
@@ -243,11 +216,8 @@
hosts:
- "*/mysql.foo.com"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
@@ -274,15 +244,11 @@
hosts:
- "*/mysql.foo.com"
-
{{}}
{{}}
-
And the associated service entry for routing to mysql.foo.com:3306
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -298,11 +264,8 @@
location: MESH_EXTERNAL
resolution: DNS
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -318,10 +281,8 @@
location: MESH_EXTERNAL
resolution: DNS
-
{{}}
{{}}
-
It is also possible to mix and match traffic capture modes in a single
proxy. For example, consider a setup where internal services are on the
192.168.0.0/16 subnet. So, IP tables are setup on the VM to capture all
@@ -330,14 +291,11 @@
traffic. The following Sidecar configuration allows the VM to expose a
listener on 172.16.1.32:80 (the VM’s IP) for traffic arriving from the
172.16.0.0/16 subnet.
-
NOTE: The ISTIO_META_INTERCEPTION_MODE metadata on the
proxy in the VM should contain REDIRECT or TPROXY as its value,
implying that IP tables based traffic capture is active.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
@@ -364,11 +322,8 @@
hosts:
- "*/*"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
@@ -395,10 +350,8 @@
hosts:
- "*/*"
-
{{}}
{{}}
-
The following example declares a Sidecar configuration in the
prod-us1 namespace for all pods with labels app: ratings
belonging to the ratings.prod-us1 service. The service accepts
@@ -411,10 +364,8 @@
ports.
In this example, the mTLS mode is disabled on PORT 80.
This feature is currently experimental.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
@@ -435,11 +386,8 @@
privateKey: "/etc/certs/privatekey.pem"
serverCertificate: "/etc/certs/servercert.pem"
-
{{}}
-
{{}}
-
apiVersion: v1
kind: Service
metadata:
@@ -455,11 +403,8 @@
selector:
app: ratings
-
{{}}
-
{{}}
-
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
@@ -475,7 +420,6 @@
80:
mode: DISABLE
-
{{}}
{{}}
@@ -721,12 +665,10 @@ IstioEgressListener
(e.g., a Kubernetes or cloud foundry service) or a service specified
using a ServiceEntry or VirtualService configuration. Any
associated DestinationRule in the same namespace will also be used.
-
The dnsName should be specified using FQDN format, optionally including
a wildcard character in the left-most component (e.g., prod/*.example.com).
Set the dnsName to * to select all services from the specified namespace
(e.g., prod/*).
-
The namespace can be set to *, ., or ~, representing any, the current,
or no namespace, respectively. For example, */foo.example.com selects the
service from any available namespace while ./foo.example.com only selects
@@ -735,7 +677,6 @@
IstioEgressListener
mesh that is exported to the sidecar’s namespace. The value ~/* can be used
to completely trim the configuration for sidecars that simply receive traffic
and respond, but make no outbound connections of their own.
-
NOTE: Only services and configuration artifacts exported to the sidecar’s
namespace (e.g., exportTo value of *) can be referenced.
Private configurations (e.g., exportTo set to .) will
diff --git a/content/zh/docs/reference/config/networking/virtual-service/index.html b/content/zh/docs/reference/config/networking/virtual-service/index.html
index ad012d60efd69..2c1b51dff3e73 100644
--- a/content/zh/docs/reference/config/networking/virtual-service/index.html
+++ b/content/zh/docs/reference/config/networking/virtual-service/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Virtual Service
description: Configuration affecting label/content routing, sni routing, etc.
location: https://istio.io/docs/reference/config/networking/virtual-service.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.VirtualService
aliases: [/zh/docs/reference/config/networking/v1alpha3/virtual-service]
@@ -12,11 +12,9 @@
---
Configuration affecting traffic routing. Here are a few terms useful to define
in the context of traffic routing.
-
Service a unit of application behavior bound to a unique name in a
service registry. Services consist of multiple network endpoints
implemented by workload instances running on pods, containers, VMs etc.
-
Service versions (a.k.a. subsets) - In a continuous deployment
scenario, for a given service, there can be distinct subsets of
instances running different variants of the application binary. These
@@ -27,34 +25,26 @@
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 - A downstream client calling a service.
-
Host - The address used by a client when attempting to connect to a
service.
-
Access model - Applications address only the destination service
(Host) without knowledge of individual service versions (subsets). The
actual choice of the version is determined by the proxy/sidecar, enabling the
application code to decouple itself from the evolution of dependent
services.
-
A VirtualService defines a set of traffic routing rules to apply when a host is
addressed. Each routing rule defines matching criteria for traffic of a specific
protocol. If the traffic is matched, then it is sent to a named destination service
(or subset/version of it) defined in the registry.
-
The source of traffic can also be matched in a routing rule. This allows routing
to be customized for specific client contexts.
-
The following example on Kubernetes, routes all HTTP traffic by default to
pods of the reviews service with label “version: v1”. In addition,
HTTP requests with path starting with /wpcatalog/ or /consumercatalog/ will
be rewritten to /newcatalog and sent to pods with label “version: v2”.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -81,11 +71,8 @@
host: reviews.prod.svc.cluster.local
subset: v1
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -112,17 +99,13 @@
host: reviews.prod.svc.cluster.local
subset: v1
-
{{}}
{{}}
-
A subset/version of a route destination is identified with a reference
to a named service subset which must be declared in a corresponding
DestinationRule.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -137,11 +120,8 @@
labels:
version: v2
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -156,7 +136,6 @@
labels:
version: v2
-
{{}}
{{}}
@@ -183,7 +162,6 @@ VirtualService
platform, short-names can also be used instead of a FQDN (i.e. has no
dots in the name). In such a scenario, the FQDN of the host would be
derived based on the underlying platform.
-
A single VirtualService can be used to describe all the traffic
properties of the corresponding hosts, including those for multiple
HTTP and TCP ports. Alternatively, the traffic properties of a host
@@ -191,7 +169,6 @@
VirtualService
caveats. Refer to the
Operations Guide
for details.
-
Note for Kubernetes users: When short names are used (e.g. “reviews”
instead of “reviews.default.svc.cluster.local”), Istio will interpret
the short name based on the namespace of the rule, not the service. A
@@ -200,12 +177,10 @@
VirtualService
the actual namespace associated with the reviews service. To avoid
potential misconfigurations, it is recommended to always use fully
qualified domain names over short names.
-
The hosts field applies to both HTTP and TCP services. Service inside
the mesh, i.e., those found in the service registry, must always be
referred to using their alphanumeric names. IP addresses are allowed
only for services defined via the Gateway.
-
Note: It must be empty for a delegate VirtualService.
@@ -258,10 +233,10 @@ VirtualService
An ordered list of route rule for non-terminated TLS & HTTPS
traffic. Routing is typically performed using the SNI value presented
by the ClientHello message. TLS routes will be applied to platform
-service ports named ‘https-’, ‘tls-’, unterminated gateway ports using
+service ports named ‘https-’, ’tls-’, unterminated gateway ports using
HTTPS/TLS protocols (i.e. with “passthrough” TLS mode) and service
entry ports using HTTPS/TLS protocols. The first rule matching an
-incoming request is used. NOTE: Traffic ‘https-’ or ‘tls-’ ports
+incoming request is used. NOTE: Traffic ‘https-’ or ’tls-’ ports
without associated virtual service will be treated as opaque TCP
traffic.
@@ -292,10 +267,8 @@ VirtualService
other namespaces. This feature provides a mechanism for service owners
and mesh administrators to control the visibility of virtual services
across namespace boundaries.
-
If no namespaces are specified then the virtual service is exported to all
namespaces by default.
-
The value “.” is reserved and defines an export to the same namespace that
the virtual service is declared in. Similarly the value “*” is reserved and
defines an export to all namespaces.
@@ -317,7 +290,6 @@ Destination
in the platform’s service registry (e.g., Kubernetes services, Consul
services), as well as services declared through the
ServiceEntry resource.
-
Note for Kubernetes users: When short names are used (e.g. “reviews”
instead of “reviews.default.svc.cluster.local”), Istio will interpret
the short name based on the namespace of the rule, not the service. A
@@ -326,14 +298,11 @@
Destination
actual namespace associated with the reviews service. To avoid potential
misconfigurations, it is recommended to always use fully qualified
domain names over short names.
-
The following Kubernetes example routes all traffic by default to pods
of the reviews service with label “version: v1” (i.e., subset v1), and
some to subset v2, in a Kubernetes environment.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -359,11 +328,8 @@ Destination
host: reviews # interpreted as reviews.foo.svc.cluster.local
subset: v1
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -389,15 +355,11 @@ Destination
host: reviews # interpreted as reviews.foo.svc.cluster.local
subset: v1
-
{{}}
{{}}
-
And the associated DestinationRule
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -413,11 +375,8 @@ Destination
labels:
version: v2
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -433,10 +392,8 @@ Destination
labels:
version: v2
-
{{}}
{{}}
-
The following VirtualService sets a timeout of 5s for all calls to
productpage.prod.svc.cluster.local service in Kubernetes. Notice that
there are no subsets defined in this rule. Istio will fetch all
@@ -446,10 +403,8 @@
Destination
qualified domain name of the productpage service,
productpage.prod.svc.cluster.local. Therefore the rule’s namespace does
not have an impact in resolving the name of the productpage service.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -464,11 +419,8 @@ Destination
- destination:
host: productpage.prod.svc.cluster.local
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -483,19 +435,15 @@ Destination
- destination:
host: productpage.prod.svc.cluster.local
-
{{}}
{{}}
-
To control routing for traffic bound to services outside the mesh, external
services must first be added to Istio’s internal service registry using the
ServiceEntry resource. VirtualServices can then be defined to control traffic
bound to these external services. For example, the following rules define a
Service for wikipedia.org and set a timeout of 5s for HTTP requests.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -523,11 +471,8 @@ Destination
- destination:
host: wikipedia.org
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -555,7 +500,6 @@ Destination
- destination:
host: wikipedia.org
-
{{}}
{{}}
@@ -578,7 +522,6 @@ Destination
Kubernetes services, Consul services, etc.) and from the hosts
declared by ServiceEntry. Traffic forwarded to
destinations that are not found in either of the two, will be dropped.
-
Note for Kubernetes users: When short names are used (e.g. “reviews”
instead of “reviews.default.svc.cluster.local”), Istio will interpret
the short name based on the namespace of the rule, not the service. A
@@ -700,7 +643,6 @@
HTTPRoute
A HTTP rule can either return a direct_response, redirect or forward (default) traffic.
Direct Response is used to specify a fixed response that should
be sent to clients.
-
It can be set only when Route and Redirect are empty.
@@ -714,13 +656,10 @@ HTTPRoute
Delegate is used to specify the particular VirtualService which
can be used to define delegate HTTPRoute.
-
It can be set only when Route and Redirect are empty, and the route
rules of the delegate VirtualService will be merged with that in the
current one.
-
NOTE:
-
- Only one level delegation is supported.
- The delegate’s HTTPMatchRequest must be a strict subset of the root’s,
@@ -840,7 +779,6 @@
Delegate
Describes the delegate VirtualService.
The following routing rules forward the traffic to /productpage by a delegate VirtualService named productpage,
forward the traffic to /reviews by a delegate VirtualService named reviews.
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -864,7 +802,6 @@ Delegate
name: reviews
namespace: nsB
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -882,7 +819,6 @@ Delegate
- destination:
host: productpage.nsA.svc.cluster.local
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -940,10 +876,8 @@ Headers
to requests that are routed to any reviews service destination.
It also removes the foo response header, but only from responses
coming from the v1 subset (version) of the reviews service.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -970,11 +904,8 @@ Headers
- foo
weight: 75
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -1001,7 +932,6 @@ Headers
- foo
weight: 75
-
{{}}
{{}}
@@ -1048,10 +978,8 @@ TLSRoute
traffic (TLS/HTTPS) The following routing rule forwards unterminated TLS
traffic arriving at port 443 of gateway called “mygateway” to internal
services in the mesh based on the SNI value.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -1077,11 +1005,8 @@ TLSRoute
- destination:
host: reviews.prod.svc.cluster.local
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -1107,7 +1032,6 @@ TLSRoute
- destination:
host: reviews.prod.svc.cluster.local
-
{{}}
{{}}
@@ -1154,10 +1078,8 @@ TCPRoute
Describes match conditions and actions for routing TCP traffic. The
following routing rule forwards traffic arriving at port 27017 for
mongo.prod.svc.cluster.local to another Mongo server on port 5555.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -1174,11 +1096,8 @@ TCPRoute
port:
number: 5555
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -1195,7 +1114,6 @@ TCPRoute
port:
number: 5555
-
{{}}
{{}}
@@ -1244,10 +1162,8 @@ HTTPMatchRequest
restricts the rule to match only requests where the URL path
starts with /ratings/v2/ and the request contains a custom end-user header
with value jason.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -1267,11 +1183,8 @@ HTTPMatchRequest
- destination:
host: ratings.prod.svc.cluster.local
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -1291,10 +1204,8 @@ HTTPMatchRequest
- destination:
host: ratings.prod.svc.cluster.local
-
{{}}
{{}}
-
HTTPMatchRequest CANNOT be empty.
Note: No regex string match can be set when delegate VirtualService is specified.
@@ -1327,15 +1238,17 @@ HTTPMatchRequest
URI to match
values are case-sensitive and formatted as follows:
-
-exact: "value" for exact string match
prefix: "value" for prefix-based match
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
-
+
exact: "value" for exact string match
+
+-
+
prefix: "value" for prefix-based match
+
+-
+
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
+
-
Note: Case-insensitive matching could be enabled via the
ignore_uri_case flag.
@@ -1350,13 +1263,16 @@ HTTPMatchRequest
URI Scheme
values are case-sensitive and formatted as follows:
-
-exact: "value" for exact string match
prefix: "value" for prefix-based match
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
-
+
exact: "value" for exact string match
+
+-
+
prefix: "value" for prefix-based match
+
+-
+
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
+
@@ -1370,13 +1286,16 @@ HTTPMatchRequest
HTTP Method
values are case-sensitive and formatted as follows:
-
-exact: "value" for exact string match
prefix: "value" for prefix-based match
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
-
+
exact: "value" for exact string match
+
+-
+
prefix: "value" for prefix-based match
+
+-
+
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
+
@@ -1390,13 +1309,16 @@ HTTPMatchRequest
HTTP Authority
values are case-sensitive and formatted as follows:
-
-exact: "value" for exact string match
prefix: "value" for prefix-based match
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
-
+
exact: "value" for exact string match
+
+-
+
prefix: "value" for prefix-based match
+
+-
+
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
+
@@ -1410,17 +1332,18 @@ HTTPMatchRequest
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" for exact string match
prefix: "value" for prefix-based match
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
-
+
exact: "value" for exact string match
+
+-
+
prefix: "value" for prefix-based match
+
+-
+
regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
+
-
If the value is empty and only the name of header is specfied, presence of the header is checked.
Note: The keys uri, scheme, method, and authority will be ignored.
@@ -1474,21 +1397,22 @@ HTTPMatchRequest
map<string, StringMatch>
Query parameters for matching.
-
Ex:
-
-For a query parameter like “?key=true”, the map key would be “key” and
-the string match could be defined as exact: "true".
For a query parameter like “?key”, the map key would be “key” and the
-string match could be defined as exact: "".
For a query parameter like “?key=123”, the map key would be “key” and the
+
-
+
For a query parameter like “?key=true”, the map key would be “key” and
+the string match could be defined as exact: "true".
+
+-
+
For a query parameter like “?key”, the map key would be “key” and the
+string match could be defined as exact: "".
+
+-
+
For a query parameter like “?key=123”, the map key would be “key” and the
string match could be defined as regex: "\d+$". Note that this
-configuration will only match values like “123” but not “a123” or “123a”.
+configuration will only match values like “123” but not “a123” or “123a”.
+
-
Note: prefix matching is currently not supported.
@@ -1501,7 +1425,6 @@ HTTPMatchRequest
bool
Flag to specify whether the URI matching should be case-insensitive.
-
Note: The case will be ignored only in the case of exact and prefix
URI matches.
@@ -1540,10 +1463,10 @@ HTTPMatchRequest
string
The human readable prefix to use when emitting statistics for this route.
-The statistics are generated with prefix route..
+The statistics are generated with prefix route.<stat_prefix>.
This should be set for highly critical routes that one wishes to get “per-route” statistics on.
-This prefix is only for proxy-level statistics (envoy*) and not service-level (istio*) statistics.
-Refer to https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-field-config-route-v3-route-stat-prefix
+This prefix is only for proxy-level statistics (envoy_) and not service-level (istio_) statistics.
+Refer to https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-field-config-route-v3-route-stat-prefix
for statistics that are generated when this is configured.
@@ -1562,10 +1485,8 @@ HTTPRouteDestination
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”.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -1584,11 +1505,8 @@ HTTPRouteDestination
subset: v1
weight: 75
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -1607,15 +1525,11 @@ HTTPRouteDestination
subset: v1
weight: 75
-
{{}}
{{}}
-
And the associated DestinationRule
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@@ -1630,11 +1544,8 @@ HTTPRouteDestination
labels:
version: v2
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
@@ -1649,17 +1560,13 @@ HTTPRouteDestination
labels:
version: v2
-
{{}}
{{}}
-
Traffic can also be split across two entirely different services without
having to define new subsets. For example, the following rule forwards 25% of
traffic to reviews.com to dev.reviews.com
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -1676,11 +1583,8 @@ HTTPRouteDestination
host: reviews.com
weight: 75
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -1697,7 +1601,6 @@ HTTPRouteDestination
host: reviews.com
weight: 75
-
{{}}
{{}}
@@ -1979,10 +1882,8 @@ HTTPRedirect
the specified values. For example, the following rule redirects
requests for /v1/getProductRatings API on the ratings service to
/v1/bookRatings provided by the bookratings service.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -1999,11 +1900,8 @@ HTTPRedirect
authority: newratings.default.svc.cluster.local
...
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2020,7 +1918,6 @@ HTTPRedirect
authority: newratings.default.svc.cluster.local
...
-
{{}}
{{}}
@@ -2074,9 +1971,11 @@ HTTPRedirect
derivePortRedirectPortSelection (oneof)
-On a redirect, dynamically set the port:
-* FROM_PROTOCOL_DEFAULT: automatically set to 80 for HTTP and 443 for HTTPS.
-* FROM_REQUEST_PORT: automatically use the port of the request.
+On a redirect, dynamically set the port:
+
+- FROM_PROTOCOL_DEFAULT: automatically set to 80 for HTTP and 443 for HTTPS.
+- FROM_REQUEST_PORT: automatically use the port of the request.
+
@@ -2117,10 +2016,8 @@ HTTPDirectResponse
HTTPDirectResponse can be used to send a fixed response to clients.
For example, the following rule returns a fixed 503 status with a body
to requests for /v1/getProductRatings API.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -2138,11 +2035,8 @@ HTTPDirectResponse
string: "unknown error"
...
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2160,16 +2054,12 @@ HTTPDirectResponse
string: "unknown error"
...
-
{{}}
{{}}
-
It is also possible to specify a binary response body.
This is mostly useful for non text-based protocols such as gRPC.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -2187,11 +2077,8 @@ HTTPDirectResponse
bytes: "dW5rbm93biBlcnJvcg==" # "unknown error" in base64
...
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2209,17 +2096,13 @@ HTTPDirectResponse
bytes: "dW5rbm93biBlcnJvcg==" # "unknown error" in base64
...
-
{{}}
{{}}
-
It is good practice to add headers in the HTTPRoute
as well as the direct_response, for example to specify
the returned Content-Type.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -2241,11 +2124,8 @@ HTTPDirectResponse
content-type: "appliation/json"
...
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2267,7 +2147,6 @@ HTTPDirectResponse
content-type: "text/plain"
...
-
{{}}
{{}}
@@ -2351,10 +2230,8 @@ HTTPRewrite
be used only with HTTPRouteDestination. The following example
demonstrates how to rewrite the URL prefix for api call (/ratings) to
ratings service before making the actual API call.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -2373,11 +2250,8 @@ HTTPRewrite
host: ratings.prod.svc.cluster.local
subset: v1
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2396,7 +2270,6 @@ HTTPRewrite
host: ratings.prod.svc.cluster.local
subset: v1
-
{{}}
{{}}
@@ -2478,7 +2351,7 @@ StringMatch
regexstring (oneof)
-RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
+RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).
@@ -2495,10 +2368,8 @@ HTTPRetry
calling ratings:v1 service, with a 2s timeout per retry attempt.
A retry will be attempted if there is a connect-failure, refused_stream
or when the upstream server responds with Service Unavailable(503).
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -2516,11 +2387,8 @@ HTTPRetry
perTryTimeout: 2s
retryOn: connect-failure,refused-stream,503
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2538,7 +2406,6 @@ HTTPRetry
perTryTimeout: 2s
retryOn: gateway-error,connect-failure,refused-stream
-
{{}}
{{}}
@@ -2620,10 +2487,8 @@ CorsPolicy
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.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -2647,11 +2512,8 @@ CorsPolicy
- X-Foo-Bar
maxAge: "24h"
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2675,7 +2537,6 @@ CorsPolicy
- X-Foo-Bar
maxAge: "24h"
-
{{}}
{{}}
@@ -2773,7 +2634,6 @@ HTTPFaultInjection
Fault specification is part of a VirtualService rule. Faults include
aborting the Http request from downstream service, and/or delaying
proxying of requests. A fault rule MUST HAVE delay or abort or both.
-
Note: Delay and abort faults are independent of one another, even if
both are specified simultaneously.
@@ -2926,10 +2786,8 @@ HTTPFaultInjection.Delay
forwarding path. The following example will introduce a 5 second delay
in 1 out of every 1000 requests to the “v1” version of the “reviews”
service from all pods with label env: prod
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -2951,11 +2809,8 @@ HTTPFaultInjection.Delay
value: 0.1
fixedDelay: 5s
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -2977,10 +2832,8 @@ HTTPFaultInjection.Delay
value: 0.1
fixedDelay: 5s
-
{{}}
{{}}
-
The fixedDelay field is used to indicate the amount of delay in seconds.
The optional percentage field can be used to only delay a certain
percentage of requests. If left unspecified, all request will be delayed.
@@ -3039,10 +2892,8 @@ 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 1 out of every 1000 requests to the “ratings” service “v1”.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@@ -3061,11 +2912,8 @@ HTTPFaultInjection.Abort
value: 0.1
httpStatus: 400
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
@@ -3084,10 +2932,8 @@ HTTPFaultInjection.Abort
value: 0.1
httpStatus: 400
-
{{}}
{{}}
-
The httpStatus field is used to indicate the HTTP status code to
return to the caller. The optional percentage field can be used to only
abort a certain percentage of requests. If not specified, all requests are
@@ -3119,7 +2965,7 @@
HTTPFaultInjection.Abort
string (oneof)
GRPC status code to use to abort the request. The supported
-codes are documented in https://github.com/grpc/grpc/blob/master/doc/statuscodes.md
+codes are documented in https://github.com/grpc/grpc/blob/master/doc/statuscodes.md
Note: If you want to return the status “Unavailable”, then you should
specify the code as UNAVAILABLE(all caps), but not 14.
@@ -3145,7 +2991,6 @@ HTTPFaultInjection.Abort
google.protobuf.UInt32Value
Wrapper message for uint32.
-
The JSON representation for UInt32Value is JSON number.
diff --git a/content/zh/docs/reference/config/networking/workload-entry/index.html b/content/zh/docs/reference/config/networking/workload-entry/index.html
index 2b8051aa58411..62ce572ccb6b8 100644
--- a/content/zh/docs/reference/config/networking/workload-entry/index.html
+++ b/content/zh/docs/reference/config/networking/workload-entry/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Workload Entry
description: Configuration affecting VMs onboarded into the mesh.
location: https://istio.io/docs/reference/config/networking/workload-entry.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.WorkloadEntry
aliases: [/zh/docs/reference/config/networking/v1alpha3/workload-entry]
@@ -19,12 +19,10 @@
ServiceEntry object can select multiple workload entries as well
as Kubernetes pods based on the label selector specified in the
service entry.
-
When a workload connects to istiod, the status field in the
custom resource will be updated to indicate the health of the
workload along with other details, similar to how Kubernetes
updates the status of a pod.
-
The following example declares a workload entry representing a VM
for the details.bookinfo.com service. This VM has sidecar
installed and bootstrapped using the details-legacy service
@@ -32,10 +30,8 @@
mesh. The HTTP traffic to this service is wrapped in Istio mutual
TLS and sent to sidecars on VMs on target port 8080, that in turn
forward it to the application on localhost on the same port.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
@@ -51,11 +47,8 @@
app: details-legacy
instance-id: vm1
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: WorkloadEntry
metadata:
@@ -71,15 +64,11 @@
app: details-legacy
instance-id: vm1
-
{{}}
{{}}
-
and the associated service entry
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -98,11 +87,8 @@
labels:
app: details-legacy
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -121,19 +107,15 @@
labels:
app: details-legacy
-
{{}}
{{}}
-
The following example declares the same VM workload using
its fully qualified DNS name. The service entry’s resolution
mode should be changed to DNS to indicate that the client-side
sidecars should dynamically resolve the DNS name at runtime before
forwarding the request.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
@@ -149,11 +131,8 @@
app: details-legacy
instance-id: vm1
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: WorkloadEntry
metadata:
@@ -169,15 +148,11 @@
app: details-legacy
instance-id: vm1
-
{{}}
{{}}
-
and the associated service entry
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@@ -196,11 +171,8 @@
labels:
app: details-legacy
-
{{}}
-
{{}}
-
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
@@ -219,7 +191,6 @@
labels:
app: details-legacy
-
{{}}
{{}}
@@ -265,9 +236,7 @@ WorkloadEntry
the targetPort and endpoint’s port map are not specified, traffic
to a service port will be forwarded to one of the endpoints on
the same port.
-
NOTE 1: Do not use for unix:// addresses.
-
NOTE 2: endpoint port map takes precedence over targetPort.
diff --git a/content/zh/docs/reference/config/networking/workload-group/index.html b/content/zh/docs/reference/config/networking/workload-group/index.html
index 5b0352e6ccf1a..ea466e3b9e46c 100644
--- a/content/zh/docs/reference/config/networking/workload-group/index.html
+++ b/content/zh/docs/reference/config/networking/workload-group/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Workload Group
description: Describes a collection of workload instances.
location: https://istio.io/docs/reference/config/networking/workload-group.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.networking.v1alpha3.WorkloadGroup
aliases: [/zh/docs/reference/config/networking/v1alpha3/workload-group]
@@ -16,17 +16,14 @@
be used with non-k8s workloads like Virtual Machines, and is meant to mimic
the existing sidecar injection and deployment specification model used for
Kubernetes workloads to bootstrap Istio proxies.
-
The following example declares a workload group representing a collection
of workloads that will be registered under reviews in namespace
bookinfo. The set of labels will be associated with each workload
instance during the bootstrap process, and the ports 3550 and 8080
will be associated with the workload group and use service account default.
app.kubernetes.io/version is just an arbitrary example of a label.
-
{{}}
{{}}
-
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
@@ -57,7 +54,6 @@
- name: Lit-Header
value: Im-The-Best
-
{{}}
{{}}
diff --git a/content/zh/docs/reference/config/proxy_extensions/wasm-plugin/index.html b/content/zh/docs/reference/config/proxy_extensions/wasm-plugin/index.html
index 2b85b6e193816..8983b86059951 100644
--- a/content/zh/docs/reference/config/proxy_extensions/wasm-plugin/index.html
+++ b/content/zh/docs/reference/config/proxy_extensions/wasm-plugin/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Wasm Plugin
description: Extend the functionality provided by the Istio proxy through WebAssembly filters.
location: https://istio.io/docs/reference/config/proxy_extensions/wasm-plugin.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.extensions.v1alpha1.WasmPlugin
aliases: [/zh/docs/reference/config/extensions/v1alpha1/wasm-plugin]
@@ -12,18 +12,14 @@
---
WasmPlugins provides a mechanism to extend the functionality provided by
the Istio proxy through WebAssembly filters.
-
Order of execution (as part of Envoy’s filter chain) is determined by
phase and priority settings, allowing the configuration of complex
interactions between user-supplied WasmPlugins and Istio’s internal
filters.
-
Examples:
-
AuthN Filter deployed to ingress-gateway that implements an OpenID flow
and populates the Authorization header with a JWT to be consumed by
Istio AuthN.
-
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
@@ -40,9 +36,7 @@
openid_server: authn
openid_realm: ingress
-
This is the same as the last example, but using an OCI image.
-
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
@@ -60,9 +54,7 @@
openid_server: authn
openid_realm: ingress
-
This is the same as the last example, but using VmConfig to configure environment variables in the VM.
-
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
@@ -86,9 +78,7 @@
- name: TRUST_DOMAIN
value: "cluster.local"
-
This is also the same as the last example, but the Wasm module is pulled via https and updated for each time when this plugin resource is changed.
-
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
@@ -111,7 +101,6 @@
- name: TRUST_DOMAIN
value: "cluster.local"
-
And a more complex example that deploys three WasmPlugins and orders them
using phase and priority. The (hypothetical) setup is that the
openid-connect filter performs an OpenID Connect flow to authenticate the
@@ -123,10 +112,8 @@
acl-check filter writes this token to a header. Finally, the check-header
filter verifies the token in that header and makes sure that the token’s
contents (the permitted ‘function’) matches its plugin configuration.
-
The resulting filter chain looks like this:
-> openid-connect -> istio.authn -> acl-check -> check-header -> router
-
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
@@ -144,7 +131,6 @@
openid_server: authn
openid_realm: ingress
-
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
@@ -163,7 +149,6 @@
acl_server: some_server
set_header: authz_complete
-
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
diff --git a/content/zh/docs/reference/config/security/authorization-policy/index.html b/content/zh/docs/reference/config/security/authorization-policy/index.html
index 6944834715333..7562ce83f6d8c 100644
--- a/content/zh/docs/reference/config/security/authorization-policy/index.html
+++ b/content/zh/docs/reference/config/security/authorization-policy/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Authorization Policy
description: Configuration for access control on workloads.
location: https://istio.io/docs/reference/config/security/authorization-policy.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.security.v1beta1.AuthorizationPolicy
weight: 20
@@ -12,11 +12,9 @@
number_of_entries: 9
---
Istio Authorization Policy enables access control on workloads in the mesh.
-
Authorization policy supports CUSTOM, DENY and ALLOW actions for access control. When CUSTOM, DENY and ALLOW actions
are used for a workload at the same time, the CUSTOM action is evaluated first, then the DENY action, and finally the ALLOW action.
The evaluation is determined by the following rules:
-
- If there are any CUSTOM policies that match the request, evaluate and deny the request if the evaluation result is deny.
- If there are any DENY policies that match the request, deny the request.
@@ -24,39 +22,28 @@
- If any of the ALLOW policies match the request, allow the request.
- Deny the request.
-
Istio Authorization Policy also supports the AUDIT action to decide whether to log requests.
AUDIT policies do not affect whether requests are allowed or denied to the workload.
Requests will be allowed or denied based solely on CUSTOM, DENY and ALLOW actions.
-
A request will be internally marked that it should be audited if there is an AUDIT policy on the workload that matches the request.
A separate plugin must be configured and enabled to actually fulfill the audit decision and complete the audit behavior.
The request will not be audited if there are no such supporting plugins enabled.
Currently, the only supported plugin is the Stackdriver plugin.
-
Here is an example of Istio Authorization Policy:
-
It sets the action to “ALLOW” to create an allow policy. The default action is “ALLOW”
but it is useful to be explicit in the policy.
-
It allows requests from:
-
- service account “cluster.local/ns/default/sa/sleep” or
- namespace “test”
-
to access the workload with:
-
- “GET” method at paths of prefix “/info” or,
- “POST” method at path “/data”.
-
-when the request has a valid JWT token issued by “https://accounts.google.com”.
-
+when the request has a valid JWT token issued by “https://accounts.google.com”.
Any other requests will be denied.
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -81,11 +68,9 @@
- key: request.auth.claims[iss]
values: ["https://accounts.google.com"]
-
The following is another example that sets action to “DENY” to create a deny policy.
It denies requests from the “dev” namespace to the “POST” method on all workloads
in the “foo” namespace.
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -101,10 +86,8 @@
- operation:
methods: ["POST"]
-
The following authorization policy sets the action to “AUDIT”. It will audit any GET requests to the path with the
prefix “/user/profile”.
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -121,21 +104,16 @@
methods: ["GET"]
paths: ["/user/profile/*"]
-
Authorization Policy scope (target) is determined by “metadata/namespace” and
an optional “selector”.
-
- “metadata/namespace” tells which namespace the policy applies. If set to root
namespace, the policy applies to all namespaces in a mesh.
- workload “selector” can be used to further restrict where a policy applies.
-
For example,
-
The following authorization policy applies to all workloads in namespace foo. It allows nothing and effectively denies
all requests to workloads in namespace foo.
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -144,9 +122,7 @@
spec:
{}
-
The following authorization policy allows all requests to workloads in namespace foo.
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -156,10 +132,8 @@
rules:
- {}
-
The following authorization policy applies to workloads containing label “app: httpbin” in namespace bar. It allows
nothing and effectively denies all requests to the selected workloads.
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -170,10 +144,8 @@
matchLabels:
app: httpbin
-
The following authorization policy applies to workloads containing label “version: v1” in all namespaces in the mesh.
(Assuming the root namespace is configured to “istio-system”).
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -206,7 +178,6 @@ AuthorizationPolicy
Optional. The selector decides where to apply the authorization policy. The selector will match with workloads
in the same namespace as the authorization policy. If the authorization policy is in the root namespace, the selector
will additionally match with workloads in all namespaces.
-
If not set, the selector will match all workloads.
@@ -219,7 +190,6 @@ AuthorizationPolicy
Rule[]
Optional. A list of rules to match the request. A match occurs when at least one rule matches the request.
-
If not set, the match will never occur. This is equivalent to setting a default of deny for the target workloads if
the action is ALLOW.
@@ -258,9 +228,7 @@ Rule
Rule matches requests from a list of sources that perform a list of operations subject to a
list of conditions. A match occurs when at least one source, one operation and all conditions
matches the request. An empty rule is always matched.
-
Any string field in the rule supports Exact, Prefix, Suffix and Presence match:
-
- Exact match: “abc” will match on value “abc”.
- Prefix match: “abc*” will match on value “abc” and “abcd”.
@@ -283,7 +251,6 @@ Rule
From[]
Optional. from specifies the source of a request.
-
If not set, any source is allowed.
@@ -296,7 +263,6 @@ Rule
To[]
Optional. to specifies the operation of a request.
-
If not set, any operation is allowed.
@@ -309,7 +275,6 @@ Rule
Condition[]
Optional. when specifies a list of additional conditions of a request.
-
If not set, any condition is allowed.
@@ -324,10 +289,8 @@ Source
Source specifies the source identities of a request. Fields in the source are
ANDed together.
-
For example, the following source matches if the principal is “admin” or “dev”
and the namespace is “prod” or “test” and the ip is not “1.2.3.4”.
-
principals: ["admin", "dev"]
namespaces: ["prod", "test"]
notIpBlocks: ["1.2.3.4"]
@@ -350,7 +313,6 @@ Source
Optional. A list of peer identities derived from the peer certificate. The peer identity is in the format of
"<TRUST_DOMAIN>/ns/<NAMESPACE>/sa/<SERVICE_ACCOUNT>", for example, "cluster.local/ns/default/sa/productpage".
This field requires mTLS enabled and is the same as the source.principal attribute.
-
If not set, any principal is allowed.
@@ -376,7 +338,6 @@ Source
Optional. A list of request identities derived from the JWT. The request identity is in the format of
"<ISS>/<SUB>", for example, "example.com/sub-1". This field requires request authentication enabled and is the
same as the request.auth.principal attribute.
-
If not set, any request principal is allowed.
@@ -401,7 +362,6 @@ Source
Optional. A list of namespaces derived from the peer certificate.
This field requires mTLS enabled and is the same as the source.namespace attribute.
-
If not set, any namespace is allowed.
@@ -426,7 +386,6 @@ Source
Optional. A list of IP blocks, populated from the source address of the IP packet. Single IP (e.g. “1.2.3.4”) and
CIDR (e.g. “1.2.3.0/24”) are supported. This is the same as the source.ip attribute.
-
If not set, any IP is allowed.
@@ -455,7 +414,6 @@ Source
Configuring Gateway Network Topology.
Single IP (e.g. “1.2.3.4”) and CIDR (e.g. “1.2.3.0/24”) are supported.
This is the same as the remote.ip attribute.
-
If not set, any IP is allowed.
@@ -481,10 +439,8 @@ Operation
Operation specifies the operations of a request. Fields in the operation are
ANDed together.
-
For example, the following operation matches if the host has suffix “.example.com”
and the method is “GET” or “HEAD” and the path doesn’t have prefix “/admin”.
-
hosts: ["*.example.com"]
methods: ["GET", "HEAD"]
notPaths: ["/admin*"]
@@ -507,7 +463,6 @@ Operation
Optional. A list of hosts as specified in the HTTP request. The match is case-insensitive.
See the security best practices for
recommended usage of this field.
-
If not set, any host is allowed. Must be used only with HTTP.
@@ -531,7 +486,6 @@ Operation
string[]
Optional. A list of ports as specified in the connection.
-
If not set, any port is allowed.
@@ -556,7 +510,6 @@ Operation
Optional. A list of methods as specified in the HTTP request.
For gRPC service, this will always be “POST”.
-
If not set, any method is allowed. Must be used only with HTTP.
@@ -582,7 +535,6 @@ Operation
Optional. A list of paths as specified in the HTTP request. See the Authorization Policy Normalization
for details of the path normalization.
For gRPC service, this will be the fully-qualified name in the form of “/package.service/method”.
-
If not set, any path is allowed. Must be used only with HTTP.
@@ -784,12 +736,9 @@ AuthorizationPolicy.Action
the extension by specifying the name of the provider.
One example use case of the extension is to integrate with a custom external authorization system to delegate
the authorization decision to it.
-
Note: The CUSTOM action is currently an alpha feature and is subject to breaking changes in later versions.
-
The following authorization policy applies to an ingress gateway and delegates the authorization check to a named extension
“my-custom-authz” if the request path has prefix “/admin/”.
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
diff --git a/content/zh/docs/reference/config/security/jwt/index.html b/content/zh/docs/reference/config/security/jwt/index.html
index d2804820347bd..bdb53deeebccd 100644
--- a/content/zh/docs/reference/config/security/jwt/index.html
+++ b/content/zh/docs/reference/config/security/jwt/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: JWTRule
description: Configuration to validate JWT.
location: https://istio.io/docs/reference/config/security/jwt.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.security.v1beta1.JWTRule
aliases: [/zh/docs/reference/config/security/v1beta1/jwt]
@@ -16,23 +16,18 @@ JWTRule
RFC 7519. See OAuth 2.0 and
OIDC 1.0 for how this is used in the whole
authentication flow.
-
Examples:
-
Spec for a JWT that is issued by https://example.com, with the audience claims must be either
bookstore_android.apps.example.com or bookstore_web.apps.example.com.
The token should be presented at the Authorization header (default). The JSON Web Key Set (JWKS)
will be discovered following OpenID Connect protocol.
-
issuer: https://example.com
audiences:
- bookstore_android.apps.example.com
bookstore_web.apps.example.com
-
This example specifies a token in a non-default location (x-goog-iap-jwt-assertion header). It also
defines the URI to fetch JWKS explicitly.
-
issuer: https://example.com
jwksUri: https://example.com/.secret/jwks.json
fromHeaders:
@@ -56,9 +51,8 @@ JWTRule
Identifies the issuer that issued the JWT. See
issuer
A JWT with different iss claim will be rejected.
-
-Example: https://foobar.auth0.com
-Example: 1234567-compute@developer.gserviceaccount.com
+Example: https://foobar.auth0.com
+Example: 1234567-compute@developer.gserviceaccount.com
@@ -73,11 +67,8 @@ JWTRule
audiences.
that are allowed to access. A JWT containing any of these
audiences will be accepted.
-
The service name will be accepted if audiences is empty.
-
Example:
-
audiences:
- bookstore_android.apps.example.com
bookstore_web.apps.example.com
@@ -94,15 +85,12 @@ JWTRule
URL of the provider’s public key set to validate signature of the
JWT. See OpenID Discovery.
-
Optional if the key set document can either (a) be retrieved from
OpenID
Discovery of
the issuer or (b) inferred from the email domain of the issuer (e.g. a
Google service account).
-
Example: https://www.googleapis.com/oauth2/v1/certs
-
Note: Only one of jwksUri and jwks should be used.
@@ -115,8 +103,7 @@ JWTRule
string
JSON Web Key Set of public keys to validate signature of the JWT.
-See https://auth0.com/docs/jwks.
-
+See https://auth0.com/docs/jwks.
Note: Only one of jwksUri and jwks should be used.
@@ -129,13 +116,11 @@ JWTRule
JWTHeader[]
List of header locations from which JWT is expected. For example, below is the location spec
-if JWT is expected to be found in x-jwt-assertion header, and have “Bearer ” prefix:
-
+if JWT is expected to be found in x-jwt-assertion header, and have “Bearer " prefix:
fromHeaders:
- name: x-jwt-assertion
prefix: "Bearer "
-
Note: Requests with multiple tokens (at different locations) are not supported, the output principal of
such requests is undefined.
@@ -150,11 +135,9 @@ JWTRule
List of query parameters from which JWT is expected. For example, if JWT is provided via query
parameter my_token (e.g /path?my_token=), the config is:
-
fromParams:
- "my_token"
-
Note: Requests with multiple tokens (at different locations) are not supported, the output principal of
such requests is undefined.
@@ -220,7 +203,7 @@ JWTHeader
string
The prefix that should be stripped before decoding the token.
-For example, for “Authorization: Bearer ”, prefix=“Bearer ” with a space at the end.
+For example, for “Authorization: Bearer ”, prefix=“Bearer " with a space at the end.
If the header doesn’t have this exact prefix, it is considered invalid.
diff --git a/content/zh/docs/reference/config/security/peer_authentication/index.html b/content/zh/docs/reference/config/security/peer_authentication/index.html
index 7af74ce9cb451..e8552ebce6701 100644
--- a/content/zh/docs/reference/config/security/peer_authentication/index.html
+++ b/content/zh/docs/reference/config/security/peer_authentication/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: PeerAuthentication
description: Peer authentication configuration for workloads.
location: https://istio.io/docs/reference/config/security/peer_authentication.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.security.v1beta1.PeerAuthentication
aliases: [/zh/docs/reference/config/security/v1beta1/peer_authentication]
@@ -13,11 +13,8 @@
PeerAuthentication
PeerAuthentication defines how traffic will be tunneled (or not) to the sidecar.
-
Examples:
-
Policy to allow mTLS traffic for all workloads under namespace foo:
-
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
@@ -27,12 +24,9 @@ PeerAuthentication
mtls:
mode: STRICT
-
For mesh level, put the policy in root-namespace according to your Istio installation.
-
Policies to allow both mTLS & plaintext traffic for all workloads under namespace foo, but
require mTLS for workload finance.
-
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
@@ -54,10 +48,8 @@ PeerAuthentication
mtls:
mode: STRICT
-
Policy to allow mTLS strict for all workloads, but leave port 8080 to
plaintext:
-
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
@@ -73,10 +65,8 @@ PeerAuthentication
8080:
mode: DISABLE
-
Policy to inherit mTLS mode from namespace (or mesh) settings, and overwrite
settings for port 8080
-
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
diff --git a/content/zh/docs/reference/config/security/request_authentication/index.html b/content/zh/docs/reference/config/security/request_authentication/index.html
index 1457b6e7975cc..e881d57cb5fe7 100644
--- a/content/zh/docs/reference/config/security/request_authentication/index.html
+++ b/content/zh/docs/reference/config/security/request_authentication/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: RequestAuthentication
description: Request authentication configuration for workloads.
location: https://istio.io/docs/reference/config/security/request_authentication.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.security.v1beta1.RequestAuthentication
aliases: [/zh/docs/reference/config/security/v1beta1/request_authentication]
@@ -18,11 +18,9 @@ RequestAuthentication
will be accepted but will not have any authenticated identity. To restrict access to authenticated
requests only, this should be accompanied by an authorization rule.
Examples:
-
- Require JWT for all request for workloads that have label
app:httpbin
-
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
@@ -50,13 +48,11 @@ RequestAuthentication
- source:
requestPrincipals: ["*"]
-
- A policy in the root namespace (“istio-system” by default) applies to workloads in all namespaces
in a mesh. The following policy makes all workloads only accept requests that contain a
valid JWT token.
-
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
@@ -78,13 +74,11 @@ RequestAuthentication
- source:
requestPrincipals: ["*"]
-
- The next example shows how to set a different JWT requirement for a different
host. The RequestAuthentication
declares it can accept JWTs issued by either issuer-foo or issuer-bar (the public key set is implicitly
set from the OpenID Connect spec).
-
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
@@ -121,13 +115,11 @@ RequestAuthentication
- operation:
hosts: ["another-host.com"]
-
- You can fine tune the authorization policy to set different requirement per path. For example,
to require JWT on all paths, except /healthz, the same
RequestAuthentication can be used, but the
authorization policy could be:
-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
@@ -145,24 +137,19 @@ RequestAuthentication
- operation:
paths: ["/healthz"]
-
[Experimental] Routing based on derived metadata
is now supported. A prefix ‘@’ is used to denote a match against internal metadata instead of the headers in the request.
Currently this feature is only supported for the following metadata:
-
request.auth.claims.{claim-name}[.{sub-claim}]* which are extracted from validated JWT tokens. The claim name
currently does not support the . character. Examples: request.auth.claims.sub and request.auth.claims.name.givenName.
-
The use of matches against JWT claim metadata is only supported in Gateways. The following example shows:
-
- RequestAuthentication to decode and validate a JWT. This also makes the
@request.auth.claims available for use in the VirtualService.
- AuthorizationPolicy to check for valid principals in the request. This makes the JWT required for the request.
- VirtualService to route the request based on the “sub” claim.
-
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
@@ -233,7 +220,6 @@ RequestAuthentication
Optional. The selector decides where to apply the request authentication policy. The selector will match with workloads
in the same namespace as the request authentication policy. If the request authentication policy is in the root namespace,
the selector will additionally match with workloads in all namespaces.
-
If not set, the selector will match all workloads.
diff --git a/content/zh/docs/reference/config/telemetry/index.html b/content/zh/docs/reference/config/telemetry/index.html
index db4f57c8c6e6f..014cf8e80f3fc 100644
--- a/content/zh/docs/reference/config/telemetry/index.html
+++ b/content/zh/docs/reference/config/telemetry/index.html
@@ -1,38 +1,30 @@
---
-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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Telemetry
description: Telemetry configuration for workloads.
location: https://istio.io/docs/reference/config/telemetry.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
schema: istio.telemetry.v1alpha1.Telemetry
aliases: [/zh/docs/reference/config/telemetry/v1alpha1/telemetry]
number_of_entries: 18
---
Telemetry defines how the telemetry is generated for workloads within a mesh.
-
For mesh level configuration, put the resource in root configuration
namespace for your Istio installation without a workload selector.
-
For any namespace, including the root configuration namespace, it is only
valid to have a single workload selector-less Telemetry resource.
-
For resources with a workload selector, it is only valid to have one resource
selecting any given workload.
-
The hierarchy of Telemetry configuration is as follows:
-
- Workload-specific configuration
- Namespace-specific configuration
- Root namespace configuration
-
Examples:
-
Policy to enable random sampling for 10% of traffic:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -43,10 +35,8 @@
tracing:
- randomSamplingPercentage: 10.00
-
Policy to disable trace reporting for the “foo” workload (note: tracing
context will still be propagated):
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -59,9 +49,7 @@
tracing:
- disableSpanReporting: true
-
Policy to select the alternate zipkin provider for trace reporting:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -76,9 +64,7 @@
- name: "zipkin-alternate"
randomSamplingPercentage: 10.00
-
Policy to add a custom tag from a literal value:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -93,9 +79,7 @@
literal:
value: "foo"
-
Policy to disable server-side metrics for Stackdriver for an entire mesh:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -112,9 +96,7 @@
mode: SERVER
disabled: true
-
Policy to add dimensions to all Prometheus metrics for the foo namespace:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -133,10 +115,8 @@
request_host:
value: "request.host"
-
Policy to remove the response_code dimension on some Prometheus metrics for
the bar.foo workload:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -171,9 +151,7 @@
response_code:
operation: REMOVE
-
Policy to enable access logging for the entire mesh:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -189,9 +167,7 @@
# cases where a parent configuration has marked as `disabled: true`. In
# those cases, `disabled: false` must be set explicitly to override.
-
Policy to disable access logging for the foo namespace:
-
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
@@ -273,7 +249,6 @@ Tracing
Tracing configures tracing behavior for workloads within a mesh.
It can be used to enable/disable tracing, as well as to set sampling
rates and custom tag extraction.
-
Tracing configuration support overrides of the fields providers,
random_sampling_percentage, disable_span_reporting, and custom_tags at
each level in the configuration hierarchy, with missing values filled in
@@ -326,7 +301,6 @@
Tracing
decision has been made (example: no x-b3-sampled tracing header was
present in the requests), the traffic will be selected for telemetry
generation at the percentage specified.
-
Defaults to 0%. Valid values [0.00-100.00]. Can be specified in 0.01%
increments.
@@ -385,7 +359,7 @@ ProviderRef
-No
+Yes
@@ -426,14 +400,14 @@ Metrics
MetricsOverrides[]
Optional. Ordered list of overrides to metrics generation behavior.
-
Specified overrides will be applied in order. They will be applied on
top of inherited overrides from other resources in the hierarchy in the
-following order:
-1. Mesh-scoped overrides
-2. Namespace-scoped overrides
-3. Workload-scoped overrides
-
+following order:
+
+- Mesh-scoped overrides
+- Namespace-scoped overrides
+- Workload-scoped overrides
+
Because overrides are applied in order, users are advised to order their
overrides from least specific to most specific matches. That is, it is
a best practice to list any universal overrides first, with tailored
@@ -522,7 +496,6 @@
MetricsOverrides
Match allows provides the scope of the override. It can be used to select
individual metrics, as well as the workload modes (server and/or client)
in which the metrics will be generated.
-
If match is not specified, the overrides will apply to all metrics for
both modes of operation (client and server).
@@ -554,7 +527,7 @@ MetricsOverrides
The key in the map is the name of the tag.
The value in the map is the operation to perform on the the tag.
WARNING: some providers may not support adding/removing tags.
-See also: https://istio.io/latest/docs/reference/config/metrics/#labels
+See also: https://istio.io/latest/docs/reference/config/metrics/#labels
@@ -670,7 +643,6 @@ Tracing.CustomTag
an operator-supplied value. This value can either be a hard-coded value,
a value taken from an environment variable known to the sidecar proxy, or
from a request header.
-
NOTE: when specified, custom_tags will fully replace any values provided
by parent configuration.
@@ -924,9 +896,7 @@ AccessLogging.Filter
string
CEL expression for selecting when requests/connections should be logged.
-
Examples:
-
response.code >= 400connection.mtls && request.url_path.contains('v1beta3')MetricSelector.IstioMetric
Curated list of known metric types that is supported by Istio metric
providers. See also:
-https://istio.io/latest/docs/reference/config/metrics/#metrics
+https://istio.io/latest/docs/reference/config/metrics/#metrics
@@ -967,11 +937,8 @@ MetricSelector.IstioMetric
Counter of requests to/from an application, generated for HTTP, HTTP/2,
and GRPC traffic.
-
The Prometheus provider exports this metric as: istio_requests_total.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/request_count (SERVER mode)istio.io/service/client/request_count (CLIENT mode)MetricSelector.IstioMetric
Histogram of request durations, generated for HTTP, HTTP/2, and GRPC
traffic.
-
The Prometheus provider exports this metric as:
istio_request_duration_milliseconds.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/response_latencies (SERVER mode)istio.io/service/client/roundtrip_latencies (CLIENT mode)MetricSelector.IstioMetric
Histogram of request body sizes, generated for HTTP, HTTP/2, and GRPC
traffic.
-
The Prometheus provider exports this metric as: istio_request_bytes.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/request_bytes (SERVER mode)istio.io/service/client/request_bytes (CLIENT mode)MetricSelector.IstioMetric
Histogram of response body sizes, generated for HTTP, HTTP/2, and GRPC
traffic.
-
The Prometheus provider exports this metric as: istio_response_bytes.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/response_bytes (SERVER mode)istio.io/service/client/response_bytes (CLIENT mode)MetricSelector.IstioMetric
TCP_OPENED_CONNECTIONS
Counter of TCP connections opened over lifetime of workload.
-
The Prometheus provider exports this metric as:
istio_tcp_connections_opened_total.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/connection_open_count (SERVER mode)istio.io/service/client/connection_open_count (CLIENT mode)MetricSelector.IstioMetric
TCP_CLOSED_CONNECTIONS
Counter of TCP connections closed over lifetime of workload.
-
The Prometheus provider exports this metric as:
istio_tcp_connections_closed_total.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/connection_close_count (SERVER mode)istio.io/service/client/connection_close_count (CLIENT mode)MetricSelector.IstioMetric
TCP_SENT_BYTES
Counter of bytes sent during a response over a TCP connection.
-
The Prometheus provider exports this metric as:
istio_tcp_sent_bytes_total.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/sent_bytes_count (SERVER mode)istio.io/service/client/sent_bytes_count (CLIENT mode)MetricSelector.IstioMetric
TCP_RECEIVED_BYTES
Counter of bytes received during a request over a TCP connection.
-
The Prometheus provider exports this metric as:
istio_tcp_received_bytes_total.
-
The Stackdriver provider exports this metric as:
-
istio.io/service/server/received_bytes_count (SERVER mode)istio.io/service/client/received_bytes_count (CLIENT mode)MetricSelector.IstioMetric
GRPC_REQUEST_MESSAGES
Counter incremented for every gRPC messages sent from a client.
-
The Prometheus provider exports this metric as:
istio_request_messages_total
@@ -1113,7 +1058,6 @@ MetricSelector.IstioMetric
GRPC_RESPONSE_MESSAGES
Counter incremented for every gRPC messages sent from a server.
-
The Prometheus provider exports this metric as:
istio_response_messages_total
diff --git a/content/zh/docs/reference/config/type/workload-selector/index.html b/content/zh/docs/reference/config/type/workload-selector/index.html
index ec2818ed29712..3c494d39d60f0 100644
--- a/content/zh/docs/reference/config/type/workload-selector/index.html
+++ b/content/zh/docs/reference/config/type/workload-selector/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 'https://github.com/ericvn/api' REPO
+source_repo: https://github.com/ericvn/api
title: Workload Selector
description: Definition of a workload selector.
location: https://istio.io/docs/reference/config/type/workload-selector.html
-layout: protoc-gen-docs
+layout: partner-component
generator: protoc-gen-docs
number_of_entries: 3
---
diff --git a/scripts/grab_reference_docs.sh b/scripts/grab_reference_docs.sh
index 8e3660b8f42c0..804e9b19a5b5c 100755
--- a/scripts/grab_reference_docs.sh
+++ b/scripts/grab_reference_docs.sh
@@ -36,7 +36,7 @@ fi
# The repos to mine for docs, just add new entries here to pull in more repos.
REPOS=(
https://github.com/istio/istio.git@"${SOURCE_BRANCH_NAME}"
- https://github.com/istio/api.git@"${SOURCE_BRANCH_NAME}"
+ https://github.com/ericvn/api.git@testNewImage
https://github.com/istio/proxy.git@"${SOURCE_BRANCH_NAME}"
)