[zh-cn]sync kubeadm-upgrade-phase topology-manager service-accounts

Signed-off-by: xin.li <xin.li@daocloud.io>

Author: my-git9

content/zh-cn/docs/concepts/security/service-accounts.md

@@ -381,9 +381,19 @@ You can also use TokenRequest to obtain short-lived tokens for your external app
 {{< /note >}}
 
 <!--
-### Restricting access to Secrets {#enforce-mountable-secrets}
+### Restricting access to Secrets (deprecated) {#enforce-mountable-secrets}
 -->
-### 限制对 Secret 的访问   {#enforce-mountable-secrets}
+### 限制对 Secret 的访问（已弃用）  {#enforce-mountable-secrets}
+
+{{< feature-state for_k8s_version="v1.32" state="deprecated" >}}
+
+{{< note >}}
+<!--
+`kubernetes.io/enforce-mountable-secrets` is deprecated since Kubernetes v1.32. Use separate namespaces to isolate access to mounted secrets.
+-->
+`kubernetes.io/enforce-mountable-secrets` 自 Kubernetes v1.32 起已弃用。
+你可以使用单独的命名空间来隔离对挂载 Secret 的访问。
+{{< /note >}}
 
 <!--
 Kubernetes provides an annotation called `kubernetes.io/enforce-mountable-secrets`
@@ -425,7 +435,8 @@ the Secrets from this ServiceAccount are subject to certain mounting restriction
 1. The name of each Secret referenced using `envFrom` in a Pod must also appear in the `secrets`
    field of the Pod's ServiceAccount.
 -->
-2. 在 Pod 中使用 `envFrom` 引用的每个 Secret 的名称也必须列在该 Pod 中 ServiceAccount 的 `secrets` 字段中。
+2. 在 Pod 中使用 `envFrom` 引用的每个 Secret 的名称也必须列在该 Pod 中
+   ServiceAccount 的 `secrets` 字段中。
 
 <!--
 1. The name of each Secret referenced using `imagePullSecrets` in a Pod must also appear in the `secrets`
@@ -456,7 +467,7 @@ acting as a ServiceAccount tries to communicate with the Kubernetes API server,
 the client includes an `Authorization: Bearer <token>` header with the HTTP
 request. The API server checks the validity of that bearer token as follows:
 -->
-ServiceAccount 使用签名的 JSON Web Token (JWT) 来向 Kubernetes API
+ServiceAccount 使用签名的 JSON Web Token（JWT）来向 Kubernetes API
 服务器以及任何其他存在信任关系的系统进行身份认证。根据令牌的签发方式
 （使用 `TokenRequest` 限制时间或使用传统的 Secret 机制），ServiceAccount
 令牌也可能有到期时间、受众和令牌**开始**生效的时间点。
@@ -577,8 +588,8 @@ used in your application and nowhere else.
   * [Use the CertificateSigningRequest API with client certificates](/docs/tasks/tls/managing-tls-in-a-cluster/).
 -->
 * 从集群外部向 API 服务器进行身份认证，而不使用服务账号令牌：
-  * [配置 API 服务器接受来自你自己的身份驱动的 OpenID Connect (OIDC) 令牌](/zh-cn/docs/reference/access-authn-authz/authentication/#openid-connect-tokens)。
-  * 使用来自云提供商等外部身份和访问管理 (IAM) 服务创建的服务账号或用户账号向集群进行身份认证。
+  * [配置 API 服务器接受来自你自己的身份驱动的 OpenID Connect（OIDC）令牌](/zh-cn/docs/reference/access-authn-authz/authentication/#openid-connect-tokens)。
+  * 使用来自云提供商等外部身份和访问管理（IAM）服务创建的服务账号或用户账号向集群进行身份认证。
   * [使用 CertificateSigningRequest API 和客户端证书](/zh-cn/docs/tasks/tls/managing-tls-in-a-cluster/)。
 
 <!--
@@ -587,7 +598,7 @@ used in your application and nowhere else.
   then allows authentication using a private key.
 -->
 * [配置 kubelet 从镜像仓库中获取凭据](/zh-cn/docs/tasks/administer-cluster/kubelet-credential-provider/)。
-* 使用设备插件访问虚拟的可信平台模块 (TPM)，进而可以使用私钥进行身份认证。
+* 使用设备插件访问虚拟的可信平台模块（TPM），进而可以使用私钥进行身份认证。
 
 ## {{% heading "whatsnext" %}}
 

content/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md

@@ -1,35 +1,49 @@
 ---
-title: kubeadm upgrade phase
-weight: 90
+title: kubeadm upgrade phases
+weight: 40
 content_type: concept
 ---
 
 <!--
-In v1.15.0, kubeadm introduced preliminary support for `kubeadm upgrade node` phases.
-Phases for other `kubeadm upgrade` sub-commands such as `apply`, could be added in the
-following releases.
+## kubeadm upgrade apply phase {#cmd-apply-phase}
+
+Using the phases of `kubeadm upgrade apply`, you can choose to execute the separate steps of the initial upgrade
+of a control plane node.
 -->
-在 Kubernetes v1.15.0 版本中，kubeadm 引入了对 `kubeadm upgrade node` 阶段的初步支持。
-其他 `kubeadm upgrade` 子命令如 `apply` 等阶段将在未来发行版中添加。
+## kubeadm upgrade apply 阶段   {#cmd-apply-phase}
+
+使用 `kubeadm upgrade apply` 的各个阶段，
+你可以选择执行控制平面节点初始升级的单独步骤。
+
+{{< tabs name="tab-phase" >}}
+{{< tab name="phase" include="generated/kubeadm_upgrade/kubeadm_upgrade_apply_phase.md" />}}
+{{< tab name="preflight" include="generated/kubeadm_upgrade/kubeadm_upgrade_apply_phase_preflight.md" />}}
+{{< tab name="control-plane" include="generated/kubeadm_upgrade/kubeadm_upgrade_apply_phase_control-plane.md" />}}
+{{< tab name="upload-config" include="generated/kubeadm_upgrade/kubeadm_upgrade_apply_phase_upload-config.md" />}}
+{{< tab name="kubelet-config" include="generated/kubeadm_upgrade/kubeadm_upgrade_apply_phase_kubelet-config.md" />}}
+{{< tab name="bootstrap-token" include="generated/kubeadm_upgrade/kubeadm_upgrade_apply_phase_bootstrap-token.md" />}}
+{{< tab name="addon" include="generated/kubeadm_upgrade/kubeadm_upgrade_apply_phase_addon.md" />}}
+{{< tab name="post-upgrade" include="generated/kubeadm_upgrade/kubeadm_upgrade_apply_phase_post-upgrade.md" />}}
+{{< /tabs >}}
 
 <!--
 ## kubeadm upgrade node phase {#cmd-node-phase}
 -->
 ## kubeadm upgrade node 阶段    {#cmd-node-phase}
 
 <!--
-Using this phase you can choose to execute the separate steps of the upgrade of
-secondary control-plane or worker nodes. Please note that `kubeadm upgrade apply` still has to
-be called on a primary control-plane node.
+Using the phases of `kubeadm upgrade node` you can choose to execute the separate steps of the upgrade of
+secondary control-plane or worker nodes.
 -->
-使用此阶段，你可以选择执行辅助控制平面或工作节点升级的单独步骤。
-请注意，`kubeadm upgrade apply` 命令仍然必须在主控制平面节点上调用。
+使用 `kubeadm upgrade node` 的各个阶段，你可以选择执行次要控制平面节点或工作节点升级的单独步骤。
 
 {{< tabs name="tab-phase" >}}
 {{< tab name="phase" include="generated/kubeadm_upgrade/kubeadm_upgrade_node_phase.md" />}}
 {{< tab name="preflight" include="generated/kubeadm_upgrade/kubeadm_upgrade_node_phase_preflight.md" />}}
 {{< tab name="control-plane" include="generated/kubeadm_upgrade/kubeadm_upgrade_node_phase_control-plane.md" />}}
 {{< tab name="kubelet-config" include="generated/kubeadm_upgrade/kubeadm_upgrade_node_phase_kubelet-config.md" />}}
+{{< tab name="addon" include="generated/kubeadm_upgrade/kubeadm_upgrade_node_phase_addon.md" />}}
+{{< tab name="post-upgrade" include="generated/kubeadm_upgrade/kubeadm_upgrade_node_phase_post-upgrade.md" />}}
 {{< /tabs >}}
 
 ## {{% heading "whatsnext" %}}

content/zh-cn/docs/tasks/administer-cluster/topology-manager.md

@@ -92,13 +92,27 @@ the pod can be accepted or rejected from the node based on the selected hint.
 The hint is then stored in the Topology Manager for use by the *Hint Providers* when making the
 resource allocation decisions.
 -->
-拓扑管理器从 **建议提供者** 接收拓扑信息，作为表示可用的 NUMA 节点和首选分配指示的位掩码。
+拓扑管理器从**建议提供者**接收拓扑信息，作为表示可用的 NUMA 节点和首选分配指示的位掩码。
 拓扑管理器策略对所提供的建议执行一组操作，并根据策略对提示进行约减以得到最优解。
 如果存储了与预期不符的建议，则该建议的优选字段将被设置为 false。
 在当前策略中，首选是最窄的优选掩码。
 所选建议将被存储为拓扑管理器的一部分。
 取决于所配置的策略，所选建议可用来决定节点接受或拒绝 Pod。
-之后，建议���被存储在拓扑管理器中，供 **建议提供者** 在作资源分配决策时使用。
+之后，建议会被存储在拓扑管理器中，供**建议提供者**在作资源分配决策时使用。
+
+<!--
+## Windows Support
+-->
+## Windows 支持
+
+{{< feature-state feature_gate_name="WindowsCPUAndMemoryAffinity" >}}
+
+<!--
+The Topology Manager support can be enabled on Windows by using the `WindowsCPUAndMemoryAffinity` feature gate and
+it requires support in the container runtime.
+-->
+拓扑管理器支持可以通过使用 `WindowsCPUAndMemoryAffinity` 特性门控在 Windows 上启用，
+并且需要容器运行时的支持。
 
 <!--
 ## Topology manager scopes and policies
@@ -321,7 +335,7 @@ will result with **the same** topology alignment decision.
 -->
 如果拓扑管理器配置使用 **pod** 作用域，
 那么在策略评估一个容器时，该容器反映的是整个 Pod 的要求，
-所以该 Pod 里的每个容器都会应用 **相同的** 拓扑对齐决策。
+所以该 Pod 里的每个容器都会应用**相同的**拓扑对齐决策。
 {{< /note >}}
 
 <!--
@@ -403,7 +417,7 @@ admission failure.
 对于 Pod 中的每个容器，配置了 `single-numa-node` 拓扑管理策略的
 kubelet 调用每个建议提供者以确定其资源可用性。
 使用此信息，拓扑管理器确定是否支持单 NUMA 节点亲和性。
-如果支持，则拓扑管理器将存储此信息，然后 **建议提供者** 可以在做出资源分配决定时使用此信息。
+如果支持，则拓扑管理器将存储此信息，然后**建议提供者**可以在做出资源分配决定时使用此信息。
 如果不支持，则拓扑管理器将拒绝 Pod 运行于该节点。
 这将导致 Pod 处于 `Terminated` 状态，且 Pod 无法被节点接受。
 
@@ -446,19 +460,18 @@ You will still have to enable each option using the `TopologyManagerPolicyOption
 你仍然需要使用 `TopologyManagerPolicyOptions` kubelet 选项来启用每个选项。
 
 <!--
-### `prefer-closest-numa-nodes` (beta) {#policy-option-prefer-closest-numa-nodes}
+### `prefer-closest-numa-nodes` {#policy-option-prefer-closest-numa-nodes}
 
-The `prefer-closest-numa-nodes` option is beta since Kubernetes 1.28. In Kubernetes {{< skew currentVersion >}}
-this policy option is visible by default provided that the `TopologyManagerPolicyOptions` and
-`TopologyManagerPolicyBetaOptions` [feature gates](/docs/reference/command-line-tools-reference/feature-gates/)
-are enabled.
+The `prefer-closest-numa-nodes` option is GA since Kubernetes 1.32. In Kubernetes {{< skew currentVersion >}}
+this policy option is visible by default provided that the `TopologyManagerPolicyOptions`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled.
 -->
-### `prefer-closest-numa-nodes`（Beta） {#policy-option-prefer-closest-numa-nodes}
+### `prefer-closest-numa-nodes`   {#policy-option-prefer-closest-numa-nodes}
 
-自 Kubernetes 1.28 起，`prefer-closest-numa-nodes` 选项进入 Beta 阶段。
+自 Kubernetes 1.32 起，`prefer-closest-numa-nodes` 选项进入 GA 阶段。
 在 Kubernetes {{< skew currentVersion >}} 中，只要启用了
-`TopologyManagerPolicyOptions` 和 `TopologyManagerPolicyBetaOptions`
-[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，此策略选项默认可见。
+`TopologyManagerPolicyOptions` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
+此策略选项默认可见。
 
 <!--
 The Topology Manager is not aware by default of NUMA distances, and does not take them into account when making