[zh] Sync #15010 move architecture docs into Chinese (#15034)

* Sync #15010 move architecture docs into Chinese

* Fix lint

content/zh/docs/ambient/architecture/_index.md

@@ -11,16 +11,25 @@ test: n/a
 
 ## Ambient API {#ambient-apis}
 
+要实施 L7 策略，请将 `istio.io/use-waypoint`
+标签添加到您的资源中，以便对被标记的资源使用 waypoint。
+  - 如果命名空间被标记为 `istio.io/use-waypoint` 并且拥有命名空间的默认 waypoint，
+    则该 waypoint 将应用于命名空间中的所有 Pod。
+  - 当不需要为整个命名空间使用 waypoint 时，也可以在单个服务或 Pod 上设置 `istio.io/use-waypoint` 标签。
+  - 如果命名空间和服务上都存在 `istio.io/use-waypoint` 标签，
+    则只要服务 waypoint 可以处理服务流量或所有流量，则服务 waypoint 优先级就高于命名空间 waypoint。
+    同样，Pod 上的标签优先级将高于命名空间标签。
+
 ### 标签 {#labels}
 
 您可以使用以下标签将资源添加到网格中，
 流向资源的流量使用 waypoint，并控制被发送到 waypoint 的流量。
 
 |  名称  | 功能状态 | 资源 | 描述 |
-| --- | --- | --- | --- | --- |
+| --- | --- | --- | --- |
-| `istio.io/dataplane-mode` | Beta | `Namespace` |  将您的资源添加到网格中，有效值：`ambient`。 |
+| `istio.io/dataplane-mode` | Beta | `Namespace` |  将您的资源添加到 Ambient 网格中。<br><br>有效值：`ambient`。 |
-| `istio.io/use-waypoint` | Beta | `Namespace` 或 `Service` 或 `Pod` | 使用 waypoint 对被标记资源的流量执行 L7 策略，有效值：`{waypoint-name}`、`{namespace}/{waypoint-name}` 或 `#none` |
+| `istio.io/use-waypoint` | Beta | `Namespace`、`Service` 或 `Pod` | 使用 waypoint 对被标记资源的流量执行 L7 策略。<br><br>有效值：`{waypoint-name}`、`{namespace}/{waypoint-name}` 或 `#none`（带有哈希值）。 |
-| `istio.io/waypoint-for` | Alpha | `Gateway` | 指定 waypoint 将处理流量的端点类型，有效值：`service` 或 `none` 或 `workload` 或 `all`。该标签是可选的，其默认值为 `service`。 |
+| `istio.io/waypoint-for` | Alpha | `Gateway` | 指定 waypoint 将处理流量的端点类型。<br><br>有效值：`service`、`workload`、`none` 或 `all`。该标签是可选的，其默认值为 `service`。 |
 
 为了使您的 `istio.io/use-waypoint` 标签值有效，
 您必须确保为使用 waypoint 的端点配置 waypoint。默认情况下，waypoint 接受针对服务端点的流量。
@@ -63,90 +72,3 @@ test: n/a
         group: ""
         name: productpage
     {{< /text >}}
-
-## 流量路由 {#traffic-routing}
-
-在 {{< gloss "ambient" >}}Ambient 模式{{< /gloss >}}中，工作负载分为 3 类：
-
-1. **脱离网格：**这是一个标准 Pod，未启用任何网格功能。
-1. **网格内：**这是一个 Pod，其流量被 {{< gloss >}}ztunnel{{< /gloss >}} 在 4 层拦截。
-   在此模式下，可以对 Pod 流量实施 L4 策略。可以通过在 Pod 的命名空间上设置 `istio.io/dataplane-mode=ambient` 标签来为 Pod 启用此模式。
-   这将为该命名空间中的所有 Pod 启用**网格内**模式。
-1. **启用 waypoint：** 这是一个“网格内”的 Pod，**并且**部署了 {{< gloss "waypoint" >}}waypoint 代理{{< /gloss >}}。
-   要实施 L7 策略，请将 `istio.io/use-waypoint` 标签添加到您的资源中，以便对标记的资源使用 waypoint。
-  - 如果命名空间被标记为 `istio.io/use-waypoint` 并且拥有命名空间的默认 waypoint，
-    则该 waypoint 将应用于命名空间中的所有 Pod。
-  - 当不需要为整个命名空间使用 waypoint 时，也可以在单个服务或 Pod 上设置 `istio.io/use-waypoint` 标签。
-  - 如果命名空间和服务上都存在 `istio.io/use-waypoint` 标签，
-    则只要服务 waypoint 可以处理服务流量或所有流量，则服务 waypoint 优先级就高于命名空间 waypoint。
-    同样，Pod 上的标签优先级将高于命名空间标签。
-
-根据工作负载所属的类别，请求的路径将有所不同。
-
-### Ztunnel 路由 {#ztunnel-routing}
-
-#### 出站 {#outbound}
-
-当处于 Ambient 模式中的 Pod 发出出站请求时，它将被透明地重定向到 Ztunnel，
-由 Ztunnel 来决定如何转发请求以及转发到哪儿。总之，流量路由行为就像 Kubernetes 默认的流量路由一样；
-到 `Service` 的请求将被发送到 `Service` 内的一个端点，
-而直接发送到 `Pod` IP 的请求则将直接转到该 IP。
-
-然而，根据目的地的权能，可能会出现不同的行为。
-如果目的地也被添加到网格中，或以其他方式具有 Istio 代理权能（例如 Sidecar），
-请求将被升级为加密的 {{< gloss "HBONE" >}}HBONE 隧道{{< /gloss >}}。
-如果目的地有一个 waypoint 代理，除了升级到 HBONE 之外，该请求还将被转发到该 waypoint 以执行 L7 策略。
-
-请注意，在向 `Service` 发出请求的情况下，如果该服务**具有**一个 waypoint，
-则该请求将被发送到其 waypoint 以对流量实施 L7 策略。
-类似地，在向 `Pod` IP 发出请求的情况下，如果 Pod **具有**一个 waypoint，
-则该请求将被发送到其 waypoint，以对流量实施 L7 策略。由于可以改变 `Deployment` 中与 Pod 关联的标签，
-因此从技术上讲，某些 Pod 可以使用 waypoint，而其他 Pod 则不能。通常建议用户避免这种高级用例。
-
-#### 入站 {#inbound}
-
-当处于 Ambient 模式中的 Pod 收到一个入站请求时，它将被透明地重定向到 Ztunnel。
-当 Ztunnel 收到请求时，它将应用鉴权策略并仅在请求与策略匹配时转发请求。
-
-Pod 可以接收 HBONE 流量或纯文本流量。
-这两种流量默认都可以被 Ztunnel 接受。
-因为来源自网格外的请求在评估鉴权策略时没有对等身份，
-所以用户可以设置一个策略，要求进行身份验证（可以是**任何**身份验证或特定身份验证），以阻止所有纯文本流量。
-
-当目标启用 waypoint 时，如果来源位于 Ambient 网格中，
-则来源的 ztunnel 确保请求**必定**会通过强制执行策略的 waypoint。
-但是，网格外部的工作负载对 waypoint 代理一无所知，因此即使目标启用了 waypoint，
-它也会直接将请求发送到目标，而不通过任何 waypoint 代理。
-目前，来自 Sidecar 和网关的流量也不会通过任何 waypoint 代理，并且它们将在未来版本中意识到 waypoint 代理。
-
-### Waypoint 路由 {#waypoint-routing}
-
-waypoint 以独占方式接收 HBONE 请求。
-收到请求后，waypoint 将确保流量适用于使用它的 `Pod` 或 `Service`。
-
-接受流量后，waypoint 将在转发之前强制执行 L7 策略
-（例如 `AuthorizationPolicy`、`RequestAuthentication`、`WasmPlugin`、`Telemetry` 等）。
-
-对与直接发送到 `Pod` 的，请求将在应用策略后才会被直接转发。
-
-对于发送到 `Service` 的请求，waypoint 还将应用路由和负载均衡。
-默认情况下，`Service` 会简单地将请求路由到本身，在其端点之间进行负载均衡。
-这可以重载为针对 `Service` 的路由。
-
-例如，以下策略将确保到 `echo` 服务的请求被转发到 `echo-v1`：
-
-{{< text yaml >}}
-apiVersion: gateway.networking.k8s.io/v1
-kind: HTTPRoute
-metadata:
-  name: echo
-spec:
-  parentRefs:
-  - group: ""
-    kind: Service
-    name: echo
-  rules:
-  - backendRefs:
-    - name: echo-v1
-      port: 80
-{{< /text >}}

content/zh/docs/ambient/architecture/hbone/index.md

@@ -1,17 +1,16 @@
 ---
-title: TLS 和隧道
+title: HBONE
 description: 了解 Istio 的安全隧道协议。
 weight: 2
 owner: istio/wg-networking-maintainers
 test: no
 ---
 
-## 了解 HBONE 协议 {#understanding-the-hbone-protocol}
+**HBONE**（HTTP Based Overlay Network Encapsulation，基于 HTTP 的覆盖网络封装）
-
+是 Istio 组件之间使用的安全隧道协议。HBONE 是 Istio 特定的术语。
-HBONE（HTTP Based Overlay Network Encapsulation，基于 HTTP 的覆盖网络封装）是 Istio 中特定的术语。
 它是一种通过单个 mTLS 加密网络连接（加密隧道）透明地多路复用与许多不同应用程序连接相关的 TCP 流的机制。
 
-在 Istio 当前的实现中，HBONE 协议包含 3 个开放标准：
+在 Istio 当前的实现中，HBONE 协议包含三个开放标准：
 
 - [HTTP/2](https://httpwg.org/specs/rfc7540.html)
 - [HTTP CONNECT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CONNECT)

content/zh/docs/ambient/architecture/traffic-redirection/index.md

@@ -14,13 +14,6 @@ test: no
 并通过处理核心数据路径的 {{< gloss >}}ztunnel{{< /gloss >}} 节点代理将其路由。
 有时也使用术语**流量捕获**。
 
-{{< boilerplate ambient-alpha-warning >}}
-
-{{< tip >}}
-本指南中描述的方法首次包含在 Istio 1.21.0 版本中，
-并[替换之前的方法](/zh/blog/2024/inpod-traffic-redirection-ambient/)。
-{{< /tip >}}
-
 ## Istio 的 in-Pod 流量重定向模型 {#istio-s-in-pod-traffic-redirection-model}
 
 Ambient 模式 in-Pod 流量重定向的核心设计原则是 ztunnel
@@ -131,7 +124,7 @@ LISTEN 0      128                *:15008            *:*
 $ kubectl debug $(kubectl get pod -l app=sleep -n ambient-demo -o jsonpath='{.items[0].metadata.name}') -it --image gcr.io/istio-release/base --profile=netadmin -n ambient-demo -- iptables-save
 
 Defaulting debug container name to debugger-m44qc.
-# Generated by iptables-save v1.8.7 on Wed Feb 21 20:38:16 2024
+# Generated by iptables-save
 *mangle
 :PREROUTING ACCEPT [320:53261]
 :INPUT ACCEPT [23753:267657744]
@@ -150,8 +143,8 @@ Defaulting debug container name to debugger-m44qc.
 -A ISTIO_PRERT -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
 -A ISTIO_PRERT ! -d 127.0.0.1/32 -p tcp -m mark ! --mark 0x539/0xfff -j TPROXY --on-port 15006 --on-ip 0.0.0.0 --tproxy-mark 0x111/0xfff
 COMMIT
-# Completed on Wed Feb 21 20:38:16 2024
+# Completed
-# Generated by iptables-save v1.8.7 on Wed Feb 21 20:38:16 2024
+# Generated by iptables-save
 *nat
 :PREROUTING ACCEPT [0:0]
 :INPUT ACCEPT [0:0]

content/zh/docs/ambient/architecture/traffic-routing/index.md

@@ -0,0 +1,83 @@
+---
+title: 流量路由
+description: 了解流量如何在 Ambient 网格中的工作负载之间路由。
+weight: 2
+owner: istio/wg-networking-maintainers
+test: no
+---
+
+在 {{< gloss "ambient" >}}Ambient 模式{{< /gloss >}}中，工作负载分为 3 类：
+1. **脱离网格：**这是一个标准 Pod，未启用任何网格功能。
+1. **网格内：**这是一个 Pod，其流量被 {{< gloss >}}ztunnel{{< /gloss >}} 在 4 层拦截。
+   在此模式下，可以对 Pod 流量实施 L4 策略。可以通过在 Pod 的命名空间上设置 `istio.io/dataplane-mode=ambient` 标签来为 Pod 启用此模式。
+   这将为该命名空间中的所有 Pod 启用**网格内**模式。
+1. **启用 waypoint：**这是一个“网格内”的 Pod，**并且**部署了 {{< gloss "waypoint" >}}waypoint 代理{{< /gloss >}}。
+
+根据工作负载所属的类别，请求路径会有所不同。
+
+## Ztunnel 路由 {#ztunnel-routing}
+
+### 出站 {#outbound}
+
+当处于 Ambient 模式中的 Pod 发出出站请求时，它将被透明地重定向到 Ztunnel，
+由 Ztunnel 来决定如何转发请求以及转发到哪儿。总之，流量路由行为就像 Kubernetes 默认的流量路由一样；
+到 `Service` 的请求将被发送到 `Service` 内的一个端点，
+而直接发送到 `Pod` IP 的请求则将直接转到该 IP。
+
+然而，根据目的地的权能，可能会出现不同的行为。
+如果目的地也被添加到网格中，或以其他方式具有 Istio 代理权能（例如 Sidecar），
+请求将被升级为加密的 {{< gloss "HBONE" >}}HBONE 隧道{{< /gloss >}}。
+如果目的地有一个 waypoint 代理，除了升级到 HBONE 之外，该请求还将被转发到该 waypoint 以执行 L7 策略。
+
+请注意，在向 `Service` 发出请求的情况下，如果该服务**具有**一个 waypoint，
+则该请求将被发送到其 waypoint 以对流量实施 L7 策略。
+类似地，在向 `Pod` IP 发出请求的情况下，如果 Pod **具有**一个 waypoint，
+则该请求将被发送到其 waypoint，以对流量实施 L7 策略。由于可以改变 `Deployment` 中与 Pod 关联的标签，
+因此从技术上讲，某些 Pod 可以使用 waypoint，而其他 Pod 则不能。通常建议用户避免这种高级用例。
+
+### 入站 {#inbound}
+
+当处于 Ambient 模式中的 Pod 收到一个入站请求时，它将被透明地重定向到 Ztunnel。
+当 Ztunnel 收到请求时，它将应用鉴权策略并仅在请求与策略匹配时转发请求。
+
+Pod 可以接收 HBONE 流量或纯文本流量。这两种流量默认都可以被 Ztunnel 接受。
+因为来源自网格外的请求在评估鉴权策略时没有对等身份，
+所以用户可以设置一个策略，要求进行身份验证（可以是**任何**身份验证或特定身份验证），以阻止所有纯文本流量。
+
+当目标启用 waypoint 时，如果来源位于 Ambient 网格中，
+则来源的 ztunnel 确保请求**必定**会通过强制执行策略的 waypoint。
+但是，网格外部的工作负载对 waypoint 代理一无所知，因此即使目标启用了 waypoint，
+它也会直接将请求发送到目标，而不通过任何 waypoint 代理。
+目前，来自 Sidecar 和网关的流量也不会通过任何 waypoint 代理，并且它们将在未来版本中意识到 waypoint 代理。
+
+## Waypoint 路由 {#waypoint-routing}
+
+waypoint 以独占方式接收 HBONE 请求。
+收到请求后，waypoint 将确保流量适用于使用它的 `Pod` 或 `Service`。
+
+接受流量后，waypoint 将在转发之前强制执行 L7 策略
+（例如 `AuthorizationPolicy`、`RequestAuthentication`、`WasmPlugin`、`Telemetry` 等）。
+
+对与直接发送到 `Pod` 的，请求将在应用策略后才会被直接转发。
+
+对于发送到 `Service` 的请求，waypoint 还将应用路由和负载均衡。
+默认情况下，`Service` 会简单地将请求路由到本身，在其端点之间进行负载均衡。
+这可以重载为针对 `Service` 的路由。
+
+例如，以下策略将确保到 `echo` 服务的请求被转发到 `echo-v1`：
+
+{{< text yaml >}}
+apiVersion: gateway.networking.k8s.io/v1
+kind: HTTPRoute
+metadata:
+  name: echo
+spec:
+  parentRefs:
+  - group: ""
+    kind: Service
+    name: echo
+  rules:
+  - backendRefs:
+    - name: echo-v1
+      port: 80
+{{< /text >}}

content/zh/docs/ambient/usage/ztunnel/index.md

@@ -9,8 +9,6 @@ owner: istio/wg-networking-maintainers
 test: no
 ---
 
-{{< boilerplate ambient-alpha-warning >}}
-
 ## 简介  {#introsection}
 
 本指南深入介绍了 Istio Ambient 模式中 ztunnel 代理和 Layer 4 网络能力的功能和用法。
@@ -45,7 +43,7 @@ ztunnel 代理是用 Rust 语言编写的，旨在处理 Ambient 网格中的 L3
 其中实现了 Istio 的全套 L7 功能，例如 HTTP 遥测和负载均衡。
 “安全覆盖网络（Secure Overlay Networking）”概念被非正式地用于统称通过
 ztunnel 代理在 Ambient 网格中实现的 L4 网络功能集。
-在传输层，这是通过称为 [HBONE](/zh/docs/ambient/architecture/tls-tunnel)
+在传输层，这是通过称为 [HBONE](/zh/docs/ambient/architecture/hbone)
 的基于 HTTP CONNECT 的流量隧道协议来实现的。
 
 Istio 在 Ambient 模式下的一些用例可以仅通过 L4 安全覆盖网络功能来解决，
@@ -62,9 +60,7 @@ Istio 在 Ambient 模式下的一些用例可以仅通过 L4 安全覆盖网络
 
 ## 当前注意事项  {#caveats}
 
-{{< boilerplate ambient-alpha-warning >}}
+以下是 Ambient 模式中的功能限制或警告列表。
-
-以下是 Ambient 模式 Alpha 中的功能限制或警告列表。
 这些限制计划在未来版本中得到解决或删除。
 
 1. **仅限 Kubernetes：**目前仅支持 Ambient 模式下的 Istio 在 Kubernetes 集群上部署。
@@ -138,16 +134,15 @@ Pod C1、C2 和 C3 需要访问由 Pod S1 提供的服务，并且不需要高
 （例如 L7 流量路由或 L7 流量管理），因此不需要 Waypoint 代理。
 
 该图展示了在节点 W1 上运行的 Pod C1 和 C2 与在节点 W2 上运行的 Pod S1 连接，
-它们的 TCP 流量通过在每个节点的 ztunnel 代理 Pod 之间创建的 HBONE 隧道实例进行隧道传输。
+它们的 TCP 流量通过在每个节点的 ztunnel 代理 Pod 之间创建的 {{< gloss >}}HBONE{{< /gloss >}} 隧道实例进行隧道传输。
 双向 TLS（mTLS）用于加密以及隧道流量的相互身份验证。SPIFFE 身份用于识别连接两端的工作负载。
 Istio Ambient 中使用的 `HBONE`（基于 HTTP 的覆盖网络封装：HTTP Based Overlay Network Encapsulation）概念是指一种透明、
 安全地隧道传输封装在 HTTPS 数据包中的 TCP 数据包的技术。
-有关数据路径的更多详细信息，包括 HBONE 和流量重定向详细信息，
+有关数据路径的更多详细信息，请参阅 [HBONE](/zh/docs/ambient/architecture/hbone) 和
-请参阅 [ztunnel 流量重定向](/zh/docs/ambient/usage/traffic-redirection)指南。
+[ztunnel 流量重定向](/zh/docs/ambient/architecture/traffic-redirection)中的架构指南。
 
 {{< tip >}}
 注意：虽然图中显示 HBONE 隧道位于两个 ztunnel 代理之间，
-但在 Istio 1.21.0 中引入的 Pod 内重定向实现中，
 隧道实际上位于源 Pod 和目标 Pod 之间。
 流量在源 Pod 本身的网络命名空间中进行 HBONE 封装和加密，
 最终在目标工作节点上的目标 Pod 的网络命名空间中解封装和解密。

content/zh/docs/ops/deployment/requirements/index.md

@@ -133,11 +133,11 @@ mTLS 和[自动协议选择](/zh/docs/ops/configuration/traffic-management/proto
 
 为了支持 Istio 的流量路由功能，离开 Pod 的流量可能与未部署 Sidecar 时的流量不同。
 
-对于 HTTP 流量，流量根据 `Host` 标头进行路由。如果目标 IP 和 `Host`
+对基于 HTTP 的流量，流量根据 `Host` 标头进行路由。如果目标 IP 和 `Host`
 标头未对齐，这可能会导致意外行为。例如，`curl 1.2.3.4 -H "Host: httpbin.default"`
 请求将被路由到 `httpbin` 服务，而不是 `1.2.3.4`。
 
-对于非 HTTP 流量（包括 HTTPS），Istio 无法访问 `Host` 标头，
+对不基于 HTTP 的流量（包括 HTTPS），Istio 无法访问 `Host` 标头，
 因此路由决策基于服务 IP 地址。
 
 这意味着直接调用 Pod（例如，`curl <POD_IP>`），而不匹配 Service。

content/zh/docs/reference/glossary/hbone.md

@@ -5,4 +5,4 @@ test: n/a
 
 基于 HTTP 的上层网络环境（HTTP-Based Overlay Network Environment，HBONE）
 是在 Istio 组件之间使用的安全隧道化协议。
-[了解有关 HBONE 的更多信息](/zh/docs/ambient/architecture/tls-tunnel/)。
+[了解有关 HBONE 的更多信息](/zh/docs/ambient/architecture/hbone/)。