[zh]Update concepts pages(part-1) for links with '/zh/' prefix, using new prefix '/zh-cn/'

content/zh-cn/docs/concepts/architecture/cloud-controller.md

@@ -318,10 +318,10 @@ To upgrade a HA control plane to use the cloud controller manager, see [Migrate
 
 Want to know how to implement your own cloud controller manager, or extend an existing project?
 -->
-[云控制器管理器的管理](/zh/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
+[云控制器管理器的管理](/zh-cn/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
 给出了运行和管理云控制器管理器的指南。
 
-要升级 HA 控制平面以使用云控制器管理器，请参见 [将复制的控制平面迁移以使用云控制器管理器](/zh/docs/tasks/administer-cluster/controller-manager-leader-migration/)
+要升级 HA 控制平面以使用云控制器管理器，请参见 [将复制的控制平面迁移以使用云控制器管理器](/zh-cn/docs/tasks/administer-cluster/controller-manager-leader-migration/)
 
 想要了解如何实现自己的云控制器管理器，或者对现有项目进行扩展么？
 
@@ -343,6 +343,6 @@ For more information about developing plugins, see [Developing Cloud Controller
 特定于云驱动的实现虽不是 Kubernetes 核心成分，仍要实现 `CloudProvider` 接口。
 
 关于如何开发插件的详细信息，可参考
-[开发云控制器管理器](/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager/)
+[开发云控制器管理器](/zh-cn/docs/tasks/administer-cluster/developing-cloud-controller-manager/)
 文档。
 

content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md

@@ -33,17 +33,17 @@ Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。
 所有从集群（或所运行的 Pods）发出的 API 调用都终止于 API 服务器。
 其它控制面组件都没有被设计为可暴露远程服务。
 API 服务器被配置为在一个安全的 HTTPS 端口（通常为 443）上监听远程连接请求，
-并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。
-一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用，
-特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-authz/authentication/#anonymous-requests)
-或[服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。
+并启用一种或多种形式的客户端[身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/)机制。
+一种或多种客户端[鉴权机制](/zh-cn/docs/reference/access-authn-authz/authorization/)应该被启用，
+特别是在允许使用[匿名请求](/zh-cn/docs/reference/access-authn-authz/authentication/#anonymous-requests)
+或[服务账号令牌](/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。
 
 <!--
 Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
 -->
 应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 API 服务器。
 一种好的方法是以客户端证书的形式将客户端凭据提供给 kubelet。
-请查看 [kubelet TLS 启动引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
+请查看 [kubelet TLS 启动引导](/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
 以了解如何自动提供 kubelet 客户端证书。
 
 <!--
@@ -114,7 +114,7 @@ Finally, [Kubelet authentication and/or authorization](/docs/reference/access-au
 kubelet 之间使用 [SSH 隧道](#ssh-tunnels)。
 
 最后，应该启用
-[kubelet 用户认证和/或鉴权](/zh/docs/reference/access-authn-authz/kubelet-authn-authz/)
+[kubelet 用户认证和/或鉴权](/zh-cn/docs/reference/access-authn-authz/kubelet-authn-authz/)
 来保护 kubelet API。
 
 <!--
@@ -167,6 +167,6 @@ Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity
 控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。
 启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。
 
-请浏览 [Konnectivity 服务任务](/zh/docs/tasks/extend-kubernetes/setup-konnectivity/)
+请浏览 [Konnectivity 服务任务](/zh-cn/docs/tasks/extend-kubernetes/setup-konnectivity/)
 在你的集群中配置 Konnectivity 服务。
 

content/zh-cn/docs/concepts/architecture/controller.md

@@ -50,7 +50,7 @@ detail.
 ## 控制器模式 {#controller-pattern}
 
 一个控制器至少追踪一种类型的 Kubernetes 资源。这些
-[对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+[对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/)
 有一个代表期望状态的 `spec` 字段。
 该资源的控制器负责确保其当前状态接近期望状态。
 
@@ -96,7 +96,7 @@ and eventually the work is done.
 
 Job 是一种 Kubernetes 资源，它运行一个或者多个 {{< glossary_tooltip term_id="pod" >}}，
 来执行一个任务然后停止。
-（一旦[被调度了](/zh/docs/concepts/scheduling-eviction/)，对 `kubelet` 来说 Pod
+（一旦[被调度了](/zh-cn/docs/concepts/scheduling-eviction/)，对 `kubelet` 来说 Pod
 对象就会变成了期望状态的一部分）。
 
 在集群中，当 Job 控制器拿到新任务时，它会保证一组 Node 节点上的 `kubelet`
@@ -175,7 +175,7 @@ cloud provider APIs, and other services by
 -->
 在温度计的例子中，如果房间很冷，那么某个控制器可能还会启动一个防冻加热器。
 就 Kubernetes 集群而言，控制面间接地与 IP 地址管理工具、存储服务、云驱动
-APIs 以及其他服务协作，通过[扩展 Kubernetes](/zh/docs/concepts/extend-kubernetes/)
+APIs 以及其他服务协作，通过[扩展 Kubernetes](/zh-cn/docs/concepts/extend-kubernetes/)
 来实现这点。
 
 <!--
@@ -280,9 +280,9 @@ Kubernetes 允许你运行一个稳定的控制平面，这样即使某些内置
 * Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
 * If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes.
 -->
-* 阅读 [Kubernetes 控制平面组件](/zh/docs/concepts/overview/components/#control-plane-components)
-* 了解 [Kubernetes 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+* 阅读 [Kubernetes 控制平面组件](/zh-cn/docs/concepts/overview/components/#control-plane-components)
+* 了解 [Kubernetes 对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/)
   的一些基本知识
-* 进一步学习 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/)
+* 进一步学习 [Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/)
 * 如果你想编写自己的控制器，请看 Kubernetes 的
-  [扩展模式](/zh/docs/concepts/extend-kubernetes/#extension-patterns)。
+  [扩展模式](/zh-cn/docs/concepts/extend-kubernetes/#extension-patterns)。

content/zh-cn/docs/concepts/architecture/cri.md

@@ -46,7 +46,7 @@ flags](/docs/reference/command-line-tools-reference/kubelet)
 -->
 当通过 gRPC 连接到容器运行时时，kubelet 充当客户端。
 运行时和镜像服务端点必须在容器运行时中可用，可以使用
-[命令行标志](/zh/docs/reference/command-line-tools-reference/kubelet)的
+[命令行标志](/zh-cn/docs/reference/command-line-tools-reference/kubelet)的
 `--image-service-endpoint` 和 `--container-runtime-endpoint`
 在 kubelet 中单独配置。
 

content/zh-cn/docs/concepts/architecture/garbage-collection.md

@@ -32,16 +32,16 @@ allows the clean up of resources like the following:
     manager
 * [Node Lease objects](/docs/concepts/architecture/nodes/#heartbeats)
 -->
-* [失败的 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
-* [已完成的 Job](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)
+* [失败的 Pod](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
+* [已完成的 Job](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/)
 * [不再存在属主引用的对象](#owners-dependents)
 * [未使用的容器和容器镜像](#containers-images)
-* [动态制备的、StorageClass 回收策略为 Delete 的 PV 卷](/zh/docs/concepts/storage/persistent-volumes/#delete)
-* [阻滞或者过期的 CertificateSigningRequest (CSRs)](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
+* [动态制备的、StorageClass 回收策略为 Delete 的 PV 卷](/zh-cn/docs/concepts/storage/persistent-volumes/#delete)
+* [阻滞或者过期的 CertificateSigningRequest (CSRs)](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
 * 在以下情形中删除了的{{<glossary_tooltip text="节点" term_id="node">}}对象：
-  * 当集群使用[云控制器管理器](/zh/docs/concepts/architecture/cloud-controller/)运行于云端时；
+  * 当集群使用[云控制器管理器](/zh-cn/docs/concepts/architecture/cloud-controller/)运行于云端时；
   * 当集群使用类似于云控制器管理器的插件运行在本地环境中时。
-* [节点租约对象](/zh/docs/concepts/architecture/nodes/#heartbeats)
+* [节点租约对象](/zh-cn/docs/concepts/architecture/nodes/#heartbeats)
 
 <!--
 ## Owners and dependents {#owners-dependents}
@@ -54,7 +54,7 @@ object. In most cases, Kubernetes manages owner references automatically.
 -->
 ## 属主与依赖   {#owners-dependents}
 
-Kubernetes 中很多对象通过[*属主引用*](/zh/docs/concepts/overview/working-with-objects/owners-dependents/)
+Kubernetes 中很多对象通过[*属主引用*](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/)
 链接到彼此。属主引用（Owner Reference）可以告诉控制面哪些对象依赖于其他对象。
 Kubernetes 使用属主引用来为控制面以及其他 API 客户端在删除某对象时提供一个清理关联资源的机会。
 在大多数场合，Kubernetes 都是自动管理属主引用的。
@@ -69,7 +69,7 @@ to the labels, each `EndpointSlice` that is managed on behalf of a Service has
 an owner reference. Owner references help different parts of Kubernetes avoid
 interfering with objects they don’t control.
 -->
-属主关系与某些资源所使用的[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)不同。
+属主关系与某些资源所使用的[标签和选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)不同。
 例如，考虑一个创建 `EndpointSlice` 对象的 {{<glossary_tooltip text="Service" term_id="service">}}
 对象。Service 对象使用*标签*来允许控制面确定哪些 `EndpointSlice` 对象被该
 Service 使用。除了标签，每个被 Service 托管的 `EndpointSlice` 对象还有一个属主引用属性。
@@ -181,7 +181,7 @@ to learn more.
 
 在前台级联删除过程中，唯一可能阻止属主对象被删除的是那些带有
 `ownerReference.blockOwnerDeletion=true` 字段的依赖对象。
-参阅[使用前台级联删除](/zh/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)
+参阅[使用前台级联删除](/zh-cn/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)
 以了解进一步的细节。
 
 <!--
@@ -201,7 +201,7 @@ to learn more.
 默认情况下，Kubernetes 使用后台级联删除方案，除非你手动设置了要使用前台删除，
 或者选择遗弃依赖对象。
 
-参阅[使用后台级联删除](/zh/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)
+参阅[使用后台级联删除](/zh-cn/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)
 以了解进一步的细节。
 
 <!--
@@ -215,7 +215,7 @@ to override this behaviour, see [Delete owner objects and orphan dependents](/do
 
 当 Kubernetes 删除某个属主对象时，被留下来的依赖对象被称作被遗弃的（Orphaned）对象。
 默认情况下，Kubernetes 会删除依赖对象。要了解如何重载这种默认行为，可参阅
-[删除属主对象和遗弃依赖对象](/zh/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy)。
+[删除属主对象和遗弃依赖对象](/zh-cn/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy)。
 
 <!--
 ## Garbage collection of unused containers and images {#containers-images}
@@ -240,8 +240,8 @@ and change the parameters related to garbage collection using the
 resource type.
 -->
 要配置对未使用容器和镜像的垃圾收集选项，可以使用一个
-[配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)，基于
-[`KubeletConfiguration`](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 
+[配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/)，基于
+[`KubeletConfiguration`](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 
 资源类型来调整与垃圾搜集相关的 kubelet 行为。
 
 <!--
@@ -341,8 +341,8 @@ configure garbage collection:
 你可以通过配置特定于管理资源的控制器来调整资源的垃圾收集行为。
 下面的页面为你展示如何配置垃圾收集：
 
-* [配置 Kubernetes 对象的级联删除](/zh/docs/tasks/administer-cluster/use-cascading-deletion/)
-* [配置已完成 Job 的清理](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)
+* [配置 Kubernetes 对象的级联删除](/zh-cn/docs/tasks/administer-cluster/use-cascading-deletion/)
+* [配置已完成 Job 的清理](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/)
 
 <!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) -->
 
@@ -353,8 +353,8 @@ configure garbage collection:
 * Learn more about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/).
 * Learn about the [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs.
 -->
-* 进一步了解 [Kubernetes 对象的属主关系](/zh/docs/concepts/overview/working-with-objects/owners-dependents/)。
-* 进一步了解 Kubernetes [finalizers](/zh/docs/concepts/overview/working-with-objects/finalizers/)。
-* 进一步了解 [TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/) (beta)，
+* 进一步了解 [Kubernetes 对象的属主关系](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/)。
+* 进一步了解 Kubernetes [finalizers](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)。
+* 进一步了解 [TTL 控制器](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/) (beta)，
   该控制器负责清理已完成的 Job。
 

content/zh-cn/docs/concepts/architecture/nodes.md

@@ -38,7 +38,7 @@ Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行
 通常集群中会有若干个节点；而在一个学习用或者资源受限的环境中，你的集群中也可能
 只有一个节点。
 
-节点上的[组件](/zh/docs/concepts/overview/components/#node-components)包括
+节点上的[组件](/zh-cn/docs/concepts/overview/components/#node-components)包括
 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、
 {{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}以及
 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}。
@@ -110,7 +110,7 @@ The name of a Node object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 -->
 Node 对象的名称必须是合法的
-[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
+[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
 
 <!--
 ### Node name uniqueness
@@ -126,7 +126,7 @@ first and re-added after the update.
 -->
 ### 节点名称唯一性     {#node-name-uniqueness}
 
-节点的[名称](/zh/docs/concepts/overview/working-with-objects/names#names)用来标识 Node 对象。
+节点的[名称](/zh-cn/docs/concepts/overview/working-with-objects/names#names)用来标识 Node 对象。
 没有两个 Node 可以同时使用相同的名称。 Kubernetes 还假定名字相同的资源是同一个对象。
 就 Node 而言，隐式假定使用相同名称的实例会具有相同的状态（例如网络配置、根磁盘内容）
 和类似节点标签这类属性。这可能在节点被更改但其名称未变时导致系统状态不一致。
@@ -167,7 +167,7 @@ For self-registration, the kubelet is started with the following options:
   （逗号分隔的 `<key>=<value>:<effect>`）注册节点。当 `register-node` 为 false 时无效。
 - `--node-ip` - 节点 IP 地址。
 - `--node-labels` - 在集群中注册节点时要添加的{{< glossary_tooltip text="标签" term_id="label" >}}。
-  （参见 [NodeRestriction 准入控制插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)所实施的标签限制）。
+  （参见 [NodeRestriction 准入控制插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)所实施的标签限制）。
 - `--node-status-update-frequency` - 指定 kubelet 向控制面发送状态的频率。
 
 <!--
@@ -175,8 +175,8 @@ When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and
 [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled,
 kubelets are only authorized to create/modify their own Node resource.
 -->
-启用[Node 鉴权模式](/zh/docs/reference/access-authn-authz/node/)和
-[NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时，
+启用[Node 鉴权模式](/zh-cn/docs/reference/access-authn-authz/node/)和
+[NodeRestriction 准入插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时，
 仅授权 `kubelet` 创建或修改其自己的节点资源。
 
 {{< note >}}
@@ -256,7 +256,7 @@ kubectl cordon $NODENAME
 See [Safely Drain a Node](/docs/tasks/administer-cluster/safely-drain-node/)
 for more details.
 -->
-更多细节参考[安全地腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。
+更多细节参考[安全地腾空节点](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/)。
 
 {{< note >}}
 <!--
@@ -430,7 +430,7 @@ Pods can also have {{< glossary_tooltip text="tolerations" term_id="toleration"
 them run on a Node even though it has a specific taint.
 -->
 当节点上出现问题时，Kubernetes 控制面会自动创建与影响节点的状况对应的
-[污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
+[污点](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)。
 调度器在将 Pod 指派到某 Node 时会考虑 Node 上的污点设置。
 Pod 也可以设置{{< glossary_tooltip text="容忍度" term_id="toleration" >}}，
 以便能够在设置了特定污点的 Node 上运行。
@@ -439,7 +439,7 @@ Pod 也可以设置{{< glossary_tooltip text="容忍度" term_id="toleration" >}
 See [Taint Nodes by Condition](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)
 for more details.
 -->
-进一步的细节可参阅[根据状况为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)。
+进一步的细节可参阅[根据状况为节点设置污点](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)。
 
 <!--
 ### Capacity and Allocatable {#capacity}
@@ -463,7 +463,7 @@ Node that is available to be consumed by normal Pods.
 You may read more about capacity and allocatable resources while learning how
 to [reserve compute resources](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) on a Node.
 -->
-可以在学习如何在节点上[预留计算资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
+可以在学习如何在节点上[预留计算资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
 的时候了解有关容量和可分配资源的更多信息。
 
 <!--
@@ -588,7 +588,7 @@ This period can be configured using the `--node-monitor-period` flag on the
 - 在节点不可达的情况下，在 Node 的 `.status` 中更新 `Ready` 状况。
   在这种情况下，节点控制器将 NodeReady 状况更新为 `Unknown` 。
 - 如果节点仍然无法访问：对于不可达节点上的所有 Pod 触发
-  [API 发起的逐出](/zh/docs/concepts/scheduling-eviction/api-eviction/)操作。
+  [API 发起的逐出](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)操作。
   默认情况下，节点控制器在将节点标记为 `Unknown` 后等待 5 分钟提交第一个驱逐请求。
 
 默认情况下，节点控制器每 5 秒检查一次节点状态，可以使用 `kube-controller-manager`
@@ -708,7 +708,7 @@ If you want to explicitly reserve resources for non-Pod processes, follow this t
 [reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
 -->
 如果要为非 Pod 进程显式保留资源。
-请参考[为系统守护进程预留资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。
+请参考[为系统守护进程预留资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。
 {{< /note >}}
 
 <!--
@@ -725,9 +725,9 @@ the kubelet can use topology hints when making resource assignment decisions.
 See [Control Topology Management Policies on a Node](/docs/tasks/administer-cluster/topology-manager/)
 for more information.
 -->
-如果启用了 `TopologyManager` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
+如果启用了 `TopologyManager` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
 `kubelet` 可以在作出资源分配决策时使用拓扑提示。
-参考[控制节点上拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)了解详细信息。
+参考[控制节点上拓扑管理策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)了解详细信息。
 
 <!-- 
 ## Graceful node shutdown {#graceful-node-shutdown}
@@ -746,7 +746,7 @@ during the node shutdown.
 kubelet 会尝试检测节点系统关闭事件并终止在节点上运行的 Pods。
 
 在节点终止期间，kubelet 保证 Pod 遵从常规的
-[Pod 终止流程](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
+[Pod 终止流程](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
 
 <!-- 
 The graceful node shutdown feature depends on systemd since it takes advantage of
@@ -785,7 +785,7 @@ During a graceful shutdown, kubelet terminates pods in two phases:
 在体面关闭节点过程中，kubelet 分两个阶段来终止 Pod：
 
 1. 终止在节点上运行的常规 Pod。
-2. 终止在节点上运行的[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
+2. 终止在节点上运行的[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
 
 <!-- 
 Graceful Node Shutdown feature is configured with two [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options:
@@ -795,13 +795,13 @@ Graceful Node Shutdown feature is configured with two [`KubeletConfiguration`](/
   * Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This value should be less than `ShutdownGracePeriod`.
 -->
 节点体面关闭的特性对应两个
-[`KubeletConfiguration`](/zh/docs/tasks/administer-cluster/kubelet-config-file/) 选项：
+[`KubeletConfiguration`](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/) 选项：
 
 * `shutdownGracePeriod`：
   * 指定节点应延迟关闭的总持续时间。此时间是 Pod 体面终止的时间总和，不区分常规 Pod
-    还是[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
+    还是[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
 * `shutdownGracePeriodCriticalPods`：
-  * 在节点关闭期间指定用于终止[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)
+  * 在节点关闭期间指定用于终止[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)
     的持续时间。该值应小于 `shutdownGracePeriod`。
 
 <!--  
@@ -814,7 +814,7 @@ reserved for terminating [critical pods](/docs/tasks/administer-cluster/guarante
 例如，如果设置了 `shutdownGracePeriod=30s` 和 `shutdownGracePeriodCriticalPods=10s`，
 则 kubelet 将延迟 30 秒关闭节点。
 在关闭期间，将保留前 20（30 - 10）秒用于体面终止常规 Pod，
-而保留最后 10 秒用于终止[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
+而保留最后 10 秒用于终止[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
 
 <!--
 When pods were evicted during the graceful node shutdown, they are marked as failed.
@@ -889,7 +889,7 @@ different node.
 为了缓解上述情况，用户可以手动将具有 `NoExecute` 或 `NoSchedule` 效果的
 `node kubernetes.io/out-of-service` 污点添加到节点上，标记其无法提供服务。
 如果在 `kube-controller-manager` 上启用了 `NodeOutOfServiceVolumeDetach` 
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
 并且节点被通过污点标记为无法提供服务，如果节点 Pod 上没有设置对应的容忍度，
 那么这样的 Pod 将被强制删除，并且该在节点上被终止的 Pod 将立即进行卷分离操作。
 这样就允许那些在无法提供服务节点上的 Pod 能在其他节点上快速恢复。
@@ -938,7 +938,7 @@ during graceful node shutdown based on
 为了在节点体面关闭期间提供更多的灵活性，尤其是处理关闭期间的 Pod 排序问题，
 节点体面关闭机制能够关注 Pod 的 PriorityClass 设置，前提是你已经在集群中启用了此功能特性。
 此功能特性允许集群管理员基于 Pod
-的[优先级类（Priority Class）](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)
+的[优先级类（Priority Class）](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)
 显式地定义节点体面关闭期间 Pod 的处理顺序。
 
 <!--
@@ -969,7 +969,7 @@ Assuming the following custom pod
 in a cluster,
 -->
 假设集群中存在以下自定义的 Pod
-[优先级类](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)。
+[优先级类](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)。
 
 | Pod 优先级类名称        | Pod 优先级类数值       |
 |-------------------------|------------------------|
@@ -982,7 +982,7 @@ in a cluster,
 Within the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
 the settings for `shutdownGracePeriodByPodPriority` could look like:
 -->
-在 [kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)中，
+在 [kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)中，
 `shutdownGracePeriodByPodPriority` 可能看起来是这样：
 
 | Pod 优先级类数值       | 关闭期限  |
@@ -1059,8 +1059,8 @@ their respective shutdown periods.
 如果此功能特性被启用，但没有提供配置数据，则不会出现排序操作。
 
 使用此功能特性需要启用 `GracefulNodeShutdownBasedOnPodPriority` 
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
-并将 [kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/)
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
+并将 [kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)
 中的 `shutdownGracePeriodByPodPriority` 设置为期望的配置，
 其中包含 Pod 的优先级类数值以及对应的关闭期限。
 
@@ -1107,7 +1107,7 @@ must be set to false.
 -->
 要在节点上启用交换内存，必须启用kubelet 的 `NodeSwap` 特性门控，
 同时使用 `--fail-swap-on` 命令行参数或者将 `failSwapOn`
-[配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)设置为 false。
+[配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)设置为 false。
 
 <!--
 A user can also optionally configure `memorySwap.swapBehavior` in order to
@@ -1174,10 +1174,10 @@ see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its
   section of the architecture design document.
 * Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
 -->
-* 进一步了解节点[组件](/zh/docs/concepts/overview/components/#node-components)。
+* 进一步了解节点[组件](/zh-cn/docs/concepts/overview/components/#node-components)。
 * 阅读 [Node 的 API 定义](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)。
 * 阅读架构设计文档中有关
   [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
   的章节。
-* 了解[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
+* 了解[污点和容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)。