Sync #15774 add back ambient helm inplace upgrade into Chinese (#15780)

content/zh/docs/ambient/upgrade/helm/index.md

@@ -12,14 +12,15 @@ test: yes
 status: Experimental
 ---
 
-按照本指南使用 [Helm](https://helm.sh/docs/) 对 Ambient 模式的安装进行升级和配置。
+按照本指南使用 [Helm](https://helm.sh/docs/) 对 Ambient
-本指南假设您已经使用之前的 Istio 版本执行了
+模式的安装进行升级和配置。本指南假设您已经使用之前的 Istio 版本执行了
 [Helm Ambient 模式安装](/zh/docs/ambient/install/helm/)。
 
 {{< warning >}}
-与 Sidecar 模式相比，Ambient 模式支持将应用程序 Pod 移动到升级后的 ztunnel 代理，
+与 Sidecar 模式相比，Ambient 模式支持将应用程序 Pod
-而无需强制重启或重新安排正在运行的应用程序 Pod。但是，升级 ztunnel
+移动到升级后的 ztunnel 代理，而无需强制重启或重新安排正在运行的应用程序 Pod。
-**将**导致升级节点上所有长寿命 TCP 连接重置，并且 Istio 目前不支持 ztunnel 的金丝雀升级。
+但是，**即使使用修订版**，升级 ztunnel 也**将**导致升级节点上所有长寿命 TCP 连接重置，
+并且 Istio 目前不支持 ztunnel 的金丝雀升级。
 
 建议使用节点封锁和蓝/绿节点池来限制生产升级期间应用程序流量重置的影响范围。
 有关详细信息，请参阅 Kubernetes 提供商文档。
@@ -29,12 +30,13 @@ status: Experimental
 
 所有 Istio 升级都涉及升级控制平面、数据平面和 Istio CRD。
 由于 Ambient 数据平面分为[两个组件](/zh/docs/ambient/architecture/data-plane)，
-即 ztunnel 和 waypoint，因此升级涉及这些组件的单独步骤。
+即 ztunnel 和网关（包含 waypoint），因此升级涉及这些组件的单独步骤。
-这里简要介绍了升级控制平面和 CRD，但本质上与[在 Sidecar 模式下升级这些组件的过程](/zh/docs/setup/upgrade/canary/)相同。
+这里简要介绍了升级控制平面和 CRD，
+但本质上与[在 Sidecar 模式下升级这些组件的过程](/zh/docs/setup/upgrade/canary/)相同。
 
 与 Sidecar 模式类似，网关可以使用[修订标签](/zh/docs/setup/upgrade/canary/#stable-revision-labels)来对
 {{< gloss >}}Gateway{{</ gloss >}}）升级，
-包括 waypoint 进行细粒度控制，并可通过简单的控件随时回滚。
+包括 waypoint 进行细粒度控制，并可通过简单的控件随时回滚到 Istio 控制平面的旧版本。
 但是，与 Sidecar 模式不同，ztunnel 作为 DaemonSet（每个节点的代理）运行，
 这意味着 ztunnel 升级至少一次会影响整个节点。虽然这在许多情况下是可以接受的，
 但具有长 TCP 连接的应用程序可能会中断。在这种情况下，
@@ -43,18 +45,10 @@ status: Experimental
 
 ## 前提条件 {#prerequisites}
 
-### 整理您的标签和修订 {#organize-your-tags-and-revisions}
-
-为了安全地在 Ambient 模式下升级网格，您的网关和命名空间应使用 `istio.io/rev` 标签来指定修订标签，
-该标签控制正在运行的代理版本。我们建议将您的生产集群分成多个标签来组织您的升级。
-给定标签的所有成员将同时升级，因此最好从风险最低的应用程序开始升级。
-我们不建议直接通过标签引用修订进行升级，因为此过程很容易导致意外升级大量代理，
-并且难以细分。要查看您在集群中使用的标签和修订，请参阅有关升级标签的部分。
-
 ### 准备升级 {#prepare-for-the-upgrade}
 
-在升级 Istio 之前，我们建议下载新版本的 istioctl，
+在升级 Istio 之前，我们建议下载新版本的 istioctl，并运行 `istioctl x precheck`
-并运行 `istioctl x precheck` 以确保升级与您的 Ambient 兼容。输出应如下所示：
+以确保升级与您的 Ambient 兼容。输出应如下所示：
 
 {{< text syntax=bash snip_id=istioctl_precheck >}}
 $ istioctl x precheck
@@ -68,6 +62,25 @@ $ istioctl x precheck
 $ helm repo update istio
 {{< /text >}}
 
+{{< tabset category-name="upgrade-prerequisites" >}}
+
+{{< tab name="就地升级" category-value="in-place" >}}
+
+无需进行就地升级的额外准备，继续下一步。
+
+{{< /tab >}}
+
+{{< tab name="修订升级" category-value="revisions" >}}
+
+### 整理您的标签和修订 {#organize-your-tags-and-revisions}
+
+为了以可控的方式升级 Ambient 模式下的网格，我们建议您的网关和命名空间使用
+`istio.io/rev` 标签来指定修订标记，以控制将使用哪些网关和控制平面版本来管理工作负载的流量。
+我们建议将您的生产集群分成多个标签来组织您的升级。给定标签的所有成员将同时升级，
+因此最好从风险最低的应用程序开始升级。我们不建议直接通过标签引用修订进行升级，
+因为此过程很容易导致意外升级大量代理，并且难以细分。
+要查看您在集群中使用的标签和修订，请参阅有关升级标签的部分。
+
 ### 选择修订名称 {#choose-a-revision-name}
 
 修订标识了 Istio 控制平面的唯一实例，允许您在单个网格中同时运行控制平面的多个不同版本。
@@ -75,10 +88,10 @@ $ helm repo update istio
 建议修订版本保持不变，也就是说，一旦使用特定修订版本名称安装了控制平面，
 就不应修改安装，也不应重用修订版本名称。另一方面，标签是指向修订版本的可变指针。
 这使集群操作员能够进行数据平面升级，而无需调整任何工作负载标签，
-只需将标签从一个修订版本移动到下一个修订版本即可。所有数据平面将仅连接到一个控制平面，
+只需将标签从一个修订版本移动到下一个修订版本即可。
-该控制平面由 `istio.io/rev` 标签（指向修订版本或标签）指定，
+所有数据平面将仅连接到一个控制平面，该控制平面由 `istio.io/rev`
-如果不存在 `istio.io/rev` 标签，则由默认修订版本指定。
+标签（指向修订版本或标签）指定，如果不存在 `istio.io/rev` 标签，
-升级数据平面只需通过修改标签或编辑标签来更改它指向的控制平面即可。
+则由默认修订版本指定。升级数据平面只需通过修改标签或编辑标签来更改它指向的控制平面即可。
 
 由于修订版本是不可变的，我们建议选择与您正在安装的 Istio 版本相对应的修订版本名称，
 例如 `1-22-1`。除了选择新的修订版本名称外，您还应该记下当前的修订版本名称。
@@ -91,6 +104,10 @@ $ export REVISION=istio-1-22-1
 $ export OLD_REVISION=istio-1-21-2
 {{< /text >}}
 
+{{< /tab >}}
+
+{{< /tabset >}}
+
 ## 升级控制平面 {#upgrade-the-control-plane}
 
 ### 基本组件 {#base-components}
@@ -106,28 +123,48 @@ $ helm upgrade istio-base istio/base -n istio-system
 ### istiod 控制平面 {#istiod-control-plane}
 
 [Istiod](/zh/docs/ops/deployment/architecture/#istiod) 控制平面管理和配置在网格内路由流量的代理。
-以下命令将在当前实例旁边安装控制平面的新实例，但不会引入任何新代理，也不会接管现有代理的控制权。
+以下命令将在当前实例旁边安装控制平面的新实例，
+但不会引入任何新网关代理或 waypoint，也不会接管现有代理的控制权。
 
 如果您已经定制了 istiod 安装，则可以重用以前升级或安装中的 `values.yaml` 文件，以保持控制平面的一致性。
 
-{{< text syntax=bash snip_id=upgrade_istiod >}}
+{{< tabset category-name="upgrade-control-plane" >}}
+
+{{< tab name="就地升级" category-value="in-place" >}}
+
+{{< text syntax=bash snip_id=upgrade_istiod_inplace >}}
+$ helm upgrade istiod istio/istiod -n istio-system --wait
+{{< /text >}}
+
+{{< /tab >}}
+
+{{< tab name="修订升级" category-value="revisions" >}}
+
+{{< text syntax=bash snip_id=upgrade_istiod_revisioned >}}
 $ helm install istiod-"$REVISION" istio/istiod -n istio-system --set revision="$REVISION" --set profile=ambient --wait
 {{< /text >}}
 
+{{< /tab >}}
+
+{{< /tabset >}}
+
 ### CNI 节点代理 {#cni-node-agent}
 
 Istio CNI 节点代理负责检测添加到 Ambient 网格的 Pod，
-通知 ztunnel 应在添加的 Pod 内建立代理端口，并在 Pod 网络命名空间内配置流量重定向。
+通知 ztunnel 应在添加的 Pod 内建立代理端口，
-它不是数据平面或控制平面的一部分。
+并在 Pod 网络命名空间内配置流量重定向。它不是数据平面或控制平面的一部分。
 
-1.x 版本的 CNI 与 1.x+1 和 1.x 版本的控制平面兼容。这意味着，
+1.x 版本的 CNI 与 1.x+1 和 1.x 版本的控制平面兼容。
-只要控制平面和 Istio CNI 的版本差异在一个小版本以内，就必须在升级控制平面之前对其升级。
+这意味着，只要控制平面和 Istio CNI 的版本差异在一个小版本以内，就必须在升级控制平面之前对其升级。
 
 {{< warning >}}
-将 Istio CNI 节点代理就地升级到兼容版本不会中断已成功添加到 Ambient 网格的正在运行的 Pod 的网络，
+**即使使用修订版本**，Istio 目前也不支持 istio-cni 的金丝雀升级。
-但在升级完成且节点上升级的 Istio CNI 代理通过就绪性检查之前，
+
-不会在节点上成功调度（或重新调度）任何环境捕获的 Pod。如果这是一个严重的中断问题，
+将 Istio CNI 节点代理就地升级到兼容版本不会中断已成功添加到
-或者需要对 CNI 升级进行更严格的影响范围控制，建议使用节点污点和/或节点警戒线。
+Ambient 网格的正在运行的 Pod 的网络，但在升级完成且节点上升级的
+Istio CNI 代理通过就绪检查之前，不应在节点上安排任何新 Pod。
+如果这是一个严重的中断问题，或者需要对 CNI 升级进行更严格的影响范围控制，
+建议使用节点污点和/或节点警戒线。
 {{< /warning >}}
 
 {{< text syntax=bash snip_id=upgrade_cni >}}
@@ -145,17 +182,49 @@ $ helm upgrade istio-cni istio/cni -n istio-system
 以保持{{< gloss "data plane" >}}数据平面{{< /gloss >}}的一致性。
 
 {{< warning >}}
-无论使用何种修订版本，就地升级 ztunnel 都会短暂中断节点上的所有 Ambient 网格流量。
+**即使使用修订版本**，就地升级 ztunnel 也会短暂中断节点上的所有 Ambient 网格流量。
 实际上，中断时间非常短，主要影响长时间运行的连接。
 
 建议使用节点封锁和蓝/绿节点池来减轻生产升级期间的影响范围风险。
 有关详细信息，请参阅 Kubernetes 提供商文档。
 {{< /warning >}}
 
-{{< text syntax=bash snip_id=upgrade_ztunnel >}}
+{{< tabset category-name="upgrade-ztunnel" >}}
+
+{{< tab name="就地升级" category-value="in-place" >}}
+
+{{< text syntax=bash snip_id=upgrade_ztunnel_inplace >}}
+$ helm upgrade ztunnel istio/ztunnel -n istio-system --wait
+{{< /text >}}
+
+{{< /tab >}}
+
+{{< tab name="修订升级" category-value="revisions" >}}
+
+{{< text syntax=bash snip_id=upgrade_ztunnel_revisioned >}}
 $ helm upgrade ztunnel istio/ztunnel -n istio-system --set revision="$REVISION" --wait
 {{< /text >}}
 
+{{< /tab >}}
+
+{{< /tabset >}}
+
+{{< tabset category-name="change-gateway-revision" >}}
+
+{{< tab name="就地升级" category-value="in-place" >}}
+
+### 对手动部署的网关 Chart 进行升级（可选） {#upgrade-manually-deployed-gateway-chart-optional}
+
+必须使用 Helm 单独升级[手动部署](/zh/docs/tasks/traffic-management/ingress/gateway-api/#manual-deployment) 的 `Gateway`：
+
+{{< text syntax=bash snip_id=none >}}
+$ helm upgrade istio-ingress istio/gateway -n istio-ingress
+{{< /text >}}
+
+{{< /tab >}}
+
+{{< tab name="修订升级" category-value="revisions" >}}
+
 ### 使用标签升级 waypoint 和网关 {#upgrade-waypoints-and-gateways-using-tags}
 
 如果您遵循了最佳实践，则所有网关、工作负载和命名空间都使用默认修订版本（实际上是名为 `default` 的标签）
@@ -197,9 +266,13 @@ $ helm upgrade istio-ingress istio/gateway -n istio-ingress
 
 ## 卸载之前的控制平面 {#uninstall-the-previous-control-plane}
 
-如果您已升级所有数据平面组件以使用新版本的 Istio，
+如果您已升级所有数据平面组件以使用 Istio 控制平面的新版本，
-并且认为不需要回滚，则可以通过运行以下命令删除以前版本的控制平面：
+并且认为不需要回滚，则可以通过运行以下命令删除控制平面的先前版本：
 
 {{< text syntax=bash snip_id=none >}}
 $ helm delete istiod-"$REVISION" -n istio-system
 {{< /text >}}
+
+{{< /tab >}}
+
+{{< /tabset >}}