HTTPRetryRetry policy for HTTP requests.
+Note: the default cluster-wide retry policy, if not specified, is:
+attempts: 2
+retryOn: "connect-failure,refused-stream,unavailable,cancelled,503"
+This can be customized in Mesh Config defaultHttpRetryPolicy.
Specifies the conditions under which retry takes place.
One or more policies can be specified using a ‘,’ delimited list.
-If retry_on specifies a valid HTTP status, it will be added to retriable_status_codes retry policy.
See the retry policies
and gRPC retry policies for more details.
In addition to the policies specified above, a list of HTTP status codes can be passed, such as retryOn: "503,reset".
+Note these status codes refer to the actual responses received from the destination.
+For example, if a connection is reset, Istio will translate this to 503 for it’s response.
+However, the destination did not return a 503 error, so this would not match "503" (it would, however, match "reset").
If not specified, this defaults to connect-failure,refused-stream,unavailable,cancelled,503.
{{< warning >}} -Development of PeerAuthentication is currently frozen and likely to be replaced in Ambient. -{{< /warning >}} -PeerAuthentication defines how traffic will be tunneled (or not) to the sidecar.
+PeerAuthentication defines mutual TLS (mTLS) requirements for incoming connections.
+In sidecar mode, PeerAuthentication determines whether or not mTLS is allowed or required +for connections to an Envoy proxy sidecar.
+In ambient mode, security is transparently enabled for a pod by the ztunnel node agent.
+(Traffic between proxies uses the HBONE protocol, which includes encryption with mTLS.)
+Because of this, DISABLE mode is not supported.
+STRICT mode is useful to ensure that connections that bypass the mesh are not possible.
Examples:
-Policy to allow mTLS traffic for all workloads under namespace foo:
Policy to require mTLS traffic for all workloads under namespace foo:
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
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 014f32bb39..1ceb9eea2b 100644
--- a/content/zh/docs/reference/config/networking/virtual-service/index.html
+++ b/content/zh/docs/reference/config/networking/virtual-service/index.html
@@ -542,6 +542,11 @@ No
HTTPRetry
Retry policy for HTTP requests.
+Note: the default cluster-wide retry policy, if not specified, is:
+attempts: 2
+retryOn: "connect-failure,refused-stream,unavailable,cancelled,503"
+
+This can be customized in Mesh Config defaultHttpRetryPolicy.
@@ -2064,9 +2069,13 @@ No
Specifies the conditions under which retry takes place.
One or more policies can be specified using a ‘,’ delimited list.
-If retry_on specifies a valid HTTP status, it will be added to retriable_status_codes retry policy.
See the retry policies
and gRPC retry policies for more details.
+In addition to the policies specified above, a list of HTTP status codes can be passed, such as retryOn: "503,reset".
+Note these status codes refer to the actual responses received from the destination.
+For example, if a connection is reset, Istio will translate this to 503 for it’s response.
+However, the destination did not return a 503 error, so this would not match "503" (it would, however, match "reset").
+If not specified, this defaults to connect-failure,refused-stream,unavailable,cancelled,503.
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 a3d773fcef..79ae4ef53b 100644
--- a/content/zh/docs/reference/config/security/peer_authentication/index.html
+++ b/content/zh/docs/reference/config/security/peer_authentication/index.html
@@ -12,12 +12,15 @@ number_of_entries: 3
---
PeerAuthentication
-{{< warning >}}
-Development of PeerAuthentication is currently frozen and likely to be replaced in Ambient.
-{{< /warning >}}
-PeerAuthentication defines how traffic will be tunneled (or not) to the sidecar.
+PeerAuthentication defines mutual TLS (mTLS) requirements for incoming connections.
+In sidecar mode, PeerAuthentication determines whether or not mTLS is allowed or required
+for connections to an Envoy proxy sidecar.
+In ambient mode, security is transparently enabled for a pod by the ztunnel node agent.
+(Traffic between proxies uses the HBONE protocol, which includes encryption with mTLS.)
+Because of this, DISABLE mode is not supported.
+STRICT mode is useful to ensure that connections that bypass the mesh are not possible.
Examples:
-Policy to allow mTLS traffic for all workloads under namespace foo:
+Policy to require mTLS traffic for all workloads under namespace foo:
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata: