[zh] Update 2 docs: data-plane and cni setup (#15516)

content/zh/docs/ambient/architecture/data-plane/index.md

@@ -6,7 +6,8 @@ owner: istio/wg-networking-maintainers
 test: no
 ---
 
-在 {{< gloss "ambient" >}}Ambient 模式{{< /gloss >}}中，工作负载分为 3 类：
+在 {{< gloss "ambient" >}}Ambient 模式{{< /gloss >}}中，工作负载可以分为 3 类：
+
 1. **网格之外**：未启用任何网格功能的标准 Pod。
    Istio 和 Ambient 的{{< gloss "data plane" >}}数据平面{{< /gloss >}}都未被启用。
 1. **网格内**：被包含在 Ambient {{< gloss "data plane" >}}数据平面{{< /gloss >}}中的 Pod，
@@ -17,7 +18,7 @@ test: no
    在此模式下，可以对 Pod 流量实施 L7 策略。可以通过设置 `istio.io/use-waypoint` 标签来启用此模式。
    有关更多详细信息，请参阅[标签](/zh/docs/ambient/architecture#ambient-labels)。
 
-根据工作负载所属的类别，请求的路径将有所不同。
+根据工作负载所属的类别，流量的路径将有所不同。
 
 ## 网格内路由 {#in-mesh-routing}
 
@@ -29,7 +30,7 @@ test: no
 对 `Service` 的请求将被发送到 `Service` 内的端点，而直接对 `Pod` IP 的请求将直接发送到其 IP。
 
 然而，根据目的地的权能，可能会出现不同的行为。
-如果目的地也被添加到网格中，或以其他方式具有 Istio 代理权能（例如 Sidecar），
+如果目的地也被添加到网格中，或以其他方式赋予 Istio 代理权能（例如 Sidecar），
 请求将被升级为加密的 {{< gloss "HBONE" >}}HBONE 隧道{{< /gloss >}}。
 如果目的地有一个 waypoint 代理，除了升级到 HBONE 之外，该请求还将被转发到该 waypoint 以执行 L7 策略。
 
@@ -43,39 +44,40 @@ test: no
 
 当 Ambient 网格中的 Pod 收到入站请求时，
 它将被[透明地重定向](/zh/docs/ambient/architecture/traffic-redirection)到节点本地 ztunnel。
-当 ztunnel 收到请求时，它会应用授权策略并仅在请求通过这些检查时转发请求。
+当 ztunnel 收到请求时，它会应用鉴权策略并仅在请求通过这些检查时转发请求。
 
-Pod 可以接收 HBONE 流量或纯文本流量。这两种流量默认都可以被 Ztunnel 接受。
+Pod 可以接收 HBONE 流量或明文流量。这两种流量默认都可以被 ztunnel 接受。
-因为来源自网格外的请求在评估鉴权策略时没有对等身份，
+因为源自网格外的请求在评估鉴权策略时没有对等身份，
-所以用户可以设置一个策略，要求进行身份验证（可以是**任何**身份验证或特定身份验证），以阻止所有纯文本流量。
+所以用户可以设置一个策略，要求进行身份验证（可以是**任何**身份验证或特定身份验证），以阻止所有明文流量。
 
 当目标启用 waypoint 时，如果来源位于 Ambient 网格中，
 则来源的 ztunnel 确保请求**将**会通过强制执行策略的 waypoint。
 但是，网格外部的工作负载对 waypoint 代理一无所知，因此即使目标启用了 waypoint，
 它也会直接将请求发送到目标，而不通过任何 waypoint 代理。
-目前，来自 Sidecar 和网关的流量也不会通过任何 waypoint 代理，并且它们将在未来版本中意识到 waypoint 代理。
+目前，来自 Sidecar 和网关的流量也不会通过任何 waypoint 代理，并且它们将在未来版本中感知到 waypoint 代理。
 
 #### 数据平面详细信息 {#dataplane-details}
 
 ##### 身份 {#identity}
 
-Ambient 网格中工作负载之间的所有入站和出站 L4 TCP 流量均由数据平面通过 {{< gloss "HBONE" >}}HBONE{{< /gloss >}}、
+Ambient 网格中工作负载之间的所有入站和出站 L4 TCP 流量均由数据平面通过
-ztunnel 和 x509 证书使用 mTLS 进行保护。
+{{< gloss "HBONE" >}}HBONE{{< /gloss >}}、ztunnel 和 x509 证书使用 mTLS 进行保护。
 
 根据 {{< gloss "mutual tls authentication" >}}mTLS{{< /gloss >}} 的强制要求，
 源和目标必须具有唯一的 x509 身份，并且必须使用这些身份来为该连接建立加密通道。
 
-这需要 ztunnel 代表代理工作负载管理多个不同的工作负载证书 - 每个节点本地 Pod 的每个唯一身份（服务帐户）都有一个证书。
+这需要 ztunnel 代表代理的工作负载管理多个不同的工作负载证书 - 每个节点本地 Pod 的每个唯一身份（服务帐户）都有一个证书。
 ztunnel 自己的身份从不用于工作负载之间的 mTLS 连接。
 
 获取证书时，ztunnel 将使用自己的身份向 CA 进行身份验证，
 但会请求另一个工作负载的身份。至关重要的是，CA 必须强制 ztunnel 有权请求该身份。
-对未在节点上运行的身份的请求将被拒绝。这对于确保受感染的节点不会危及整个网格至关重要。
+对未在节点上运行的身份所做的请求将被拒绝。这对于确保受感染的节点不会危及整个网格至关重要。
 
-此 CA 强制执行由 Istio 的 CA 使用 Kubernetes 服务帐户 JWT 令牌完成，
+此 CA 的强制执行由 Istio 的 CA 使用 Kubernetes 服务帐户 JWT 令牌完成，
-该令牌对 Pod 信息进行编码。此强制执行也是与 ztunnel 集成的任何替代 CA 的要求。
+这种 JWT 令牌会对 Pod 信息进行编码。此强制执行也是与 ztunnel 集成的任何替代 CA 的要求。
 
-ztunnel 将为节点上的所有身份请求证书。它根据收到的{{< gloss "control plane" >}}控制平面{{< /gloss>}}配置来确定这一点。
+ztunnel 将为节点上的所有身份请求证书。
+它根据收到的{{< gloss "control plane" >}}控制平面{{< /gloss>}}配置来确定这一点。
 当在节点上发现新身份时，它将以低优先级排队等待获取，作为一种优化。
 但是，如果请求需要尚未获取的某个身份，则会立即请求该身份。
 
@@ -101,23 +103,23 @@ caption="基础 ztunnel 仅 L4 数据路径"
 
 该图显示在节点 W1 上运行的 Pod C1 和 C2 与在节点 W2 上运行的 Pod S1 连接。
 
-C1 和 C2 的 TCP 流量通过 ztunnel 创建的 {{< gloss >}}HBONE{{< /gloss >}}
+C1 和 C2 的 TCP 流量通过 ztunnel 创建的 {{< gloss >}}HBONE{{< /gloss >}} 连接安全地通过隧道传输。
-连接安全地通过隧道传输。{{< gloss "mutual tls authentication" >}}双向 TLS（mTLS）{{< /gloss >}}用于加密以及隧道流量的相互身份验证。
+{{< gloss "mutual tls authentication" >}}双向 TLS（mTLS）{{< /gloss >}}用于加密以及隧道流量的双向身份验证。
 [SPIFFE](https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE.md) 身份用于识别连接每一端的工作负载。
 有关隧道协议和流量重定向机制的更多详细信息，请参阅 [HBONE](/zh/docs/ambient/architecture/hbone)
 和 [ztunnel 流量重定向](/zh/docs/ambient/architecture/traffic-redirection)中的指南。
 
 {{< tip >}}
 注意：虽然图中显示 HBONE 隧道位于两个 ztunnel 代理之间，
-隧道实际上位于源 Pod 和目标 Pod 之间。
+但是隧道实际上位于源 Pod 和目标 Pod 之间。
 流量在源 Pod 本身的网络命名空间中进行 HBONE 封装和加密，
 最终在目标工作节点上的目标 Pod 的网络命名空间中解封装和解密。
 ztunnel 代理仍然在逻辑上处理 HBONE 传输所需的控制平面和数据平面，
 但它能够从源 Pod 和目标 Pod 的网络命名空间内部执行此操作。
 {{< /tip >}}
 
-请注意，本地流量 - 如图所示，从工作节点 W2 上的 pod C3 到目标 pod S1 - 也会遍历本地 ztunnel 代理实例，
+请注意，本地流量（如图所示，从工作节点 W2 上的 Pod C3 到目标 Pod S1）也会遍历本地 ztunnel 代理实例，
-因此 L4 流量管理功能，例如 L4 授权和 L4 可观测将在流量上以相同的方式实施，无论跨越节点边界与否。
+因此 L4 授权和 L4 可观测等 L4 流量管理功能将在流量上以相同的方式实施，无论跨越节点边界与否。
 
 ## 在启用了 waypoint 的网格路由中 {#in-mesh-routing-with-waypoint-enabled}
 

content/zh/docs/setup/additional-setup/cni/index.md

@@ -135,7 +135,7 @@ $ helm install istio-cni istio/cni -n istio-system --wait
 $ helm install istiod istio/istiod -n istio-system --set pilot.cni.enabled=true --wait
 {{< /text >}}
 
-### 附加配置 {##additional-configuration}
+### 附加配置 {#additional-configuration}
 
 除了上述基本配置外，还有其他可设置的配置标志：
 
@@ -151,7 +151,7 @@ $ helm install istiod istio/istiod -n istio-system --set pilot.cni.enabled=true
 则可能未正确设置流量重定向，流量将能够绕过 Istio Sidecar。
 
 对于 Sidecar 数据平面模式，此竞争条件可通过“检测和修复”方法缓解。
-请参阅[竞争条件和缓解](#race-condition--mitigation)部分以了解此缓解措施的含义以及配置说明。
+请参阅[竞争条件和缓解](#race-condition-mitigation)部分以了解此缓解措施的含义以及配置说明。
 {{< /tip >}}
 
 ### 处理修订的 Init 容器注入 {#handling-init-container-injection-for-revisions}
@@ -207,7 +207,7 @@ spec:
 $ helm upgrade istio-cni istio/cni -n istio-system --wait
 {{< /text >}}
 
-### 竞争条件和缓解 {#race-condition--mitigation}
+### 竞争条件和缓解 {#race-condition-mitigation}
 
 Istio CNI DaemonSet 在每个节点上安装 CNI 网络插件。但是，DaemonSet Pod
 被调度到节点上与 CNI 插件安装并准备使用之间存在时间间隔。