Merge pull request #34504 from howieyuen/concept-pages-1

[zh]Update concepts pages(part-1) for links with '/zh/' prefix, using new prefix '/zh-cn/'
2022-06-23 18:23:19 -07:00
parent eea83a544d 5e58c40edf
commit e45c8cab64
27 changed files with 219 additions and 219 deletions
@@ -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/)
 文档。

@@ -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 服务。

@@ -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)。
@@ -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 中单独配置。

@@ -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。

@@ -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/)。

@@ -25,7 +25,7 @@ The cluster administration overview is for anyone creating or administering a Ku
 It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
 -->
 集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。
-我们假设你大概了解一些核心的 Kubernetes [概念](/zh/docs/concepts/)。
+我们假设你大概了解一些核心的 Kubernetes [概念](/zh-cn/docs/concepts/)。


 <!-- body -->
@@ -40,7 +40,7 @@ Before choosing a guide, here are some considerations:
 -->
 ## 规划集群   {#planning-a-cluster}

-查阅[安装](/zh/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes
+查阅[安装](/zh-cn/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes
 集群的示例。本文所列的文章称为*发行版* 。

 {{< note >}}
@@ -68,12 +68,12 @@ Before choosing a guide, here are some considerations:
 - 你的集群是在**本地**还是**云（IaaS）** 上？Kubernetes 不能直接支持混合集群。
  作为代替，你可以建立多个集群。
 - **如果你在本地配置 Kubernetes**，需要考虑哪种
-  [网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。
+  [网络模型](/zh-cn/docs/concepts/cluster-administration/networking/)最适合。
 - 你的 Kubernetes 在**裸金属硬件**上还是**虚拟机（VMs）** 上运行？
 - 你是想**运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？
  如果是后者，请选择一个处于开发状态的发行版。
  某些发行版只提供二进制发布版，但提供更多的选择。
- 让你自己熟悉运行一个集群所需的[组件](/zh/docs/concepts/overview/components/)。
+- 让你自己熟悉运行一个集群所需的[组件](/zh-cn/docs/concepts/overview/components/)。

 <!--
 ## Managing a cluster
@@ -84,9 +84,9 @@ Before choosing a guide, here are some considerations:
 -->
 ## 管理集群   {#managing-a-cluster}

-* 学习如何[管理节点](/zh/docs/concepts/architecture/nodes/)。
+* 学习如何[管理节点](/zh-cn/docs/concepts/architecture/nodes/)。

-* 学习如何设定和管理集群共享的[资源配额](/zh/docs/concepts/policy/resource-quotas/) 。
+* 学习如何设定和管理集群共享的[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/) 。

 <!--
 ## Securing a cluster
@@ -102,21 +102,21 @@ Before choosing a guide, here are some considerations:
 -->
 ## 保护集群  {#securing-a-cluster}

-* [生成证书](/zh/docs/tasks/administer-cluster/certificates/)
+* [生成证书](/zh-cn/docs/tasks/administer-cluster/certificates/)
  节描述了使用不同的工具链生成证书的步骤。
-* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/)
+* [Kubernetes 容器环境](/zh-cn/docs/concepts/containers/container-environment/)
  描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
-* [控制到 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/)
+* [控制到 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access/)
  描述了如何为用户和 service accounts 建立权限许可。
-* [身份认证](/zh/docs/reference/access-authn-authz/authentication/)
+* [身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/)
  节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。
-* [鉴权](/zh/docs/reference/access-authn-authz/authorization/)
+* [鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/)
  与身份认证不同，用于控制如何处理 HTTP 请求。
-* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers)
+* [使用准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers)
  阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
-* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/)
+* [在 Kubernetes 集群中使用 Sysctls](/zh-cn/docs/tasks/administer-cluster/sysctl-cluster/)
  描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。
-* [审计](/zh/docs/tasks/debug/debug-cluster/audit/)
+* [审计](/zh-cn/docs/tasks/debug/debug-cluster/audit/)
  描述了如何与 Kubernetes 的审计日志交互。

 <!--
@@ -128,9 +128,9 @@ Before choosing a guide, here are some considerations:
 -->
 ### 保护 kubelet   {#securing-the-kubelet}

-* [主控节点通信](/zh/docs/concepts/architecture/control-plane-node-communication/)
-* [TLS 引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
-* [Kubelet 认证/授权](/zh/docs/reference/access-authn-authz/kubelet-authn-authz/)
+* [主控节点通信](/zh-cn/docs/concepts/architecture/control-plane-node-communication/)
+* [TLS 引导](/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
+* [Kubelet 认证/授权](/zh-cn/docs/reference/access-authn-authz/kubelet-authn-authz/)

 <!--
 ## Optional Cluster Services
@@ -140,8 +140,8 @@ Before choosing a guide, here are some considerations:
 -->
 ## 可选集群服务   {#optional-cluster-services}

-* [DNS 集成](/zh/docs/concepts/services-networking/dns-pod-service/)
+* [DNS 集成](/zh-cn/docs/concepts/services-networking/dns-pod-service/)
  描述了如何将一个 DNS 名解析到一个 Kubernetes service。
-* [记录和监控集群活动](/zh/docs/concepts/cluster-administration/logging/)
+* [记录和监控集群活动](/zh-cn/docs/concepts/cluster-administration/logging/)
  阐述了 Kubernetes 的日志如何工作以及怎样实现。

@@ -14,5 +14,5 @@ weight: 20
 <!--
 To learn how to generate certificates for your cluster, see [Certificates](/docs/tasks/administer-cluster/certificates/).
 -->
-要了解如何为集群生成证书，参阅[证书](/zh/docs/tasks/administer-cluster/certificates/)。
+要了解如何为集群生成证书，参阅[证书](/zh-cn/docs/tasks/administer-cluster/certificates/)。

@@ -86,7 +86,7 @@ command-line flags to your `kube-apiserver` invocation:
 -->
 API 优先级与公平性（APF）特性由特性门控控制，默认情况下启用。
 有关特性门控的一般性描述以及如何启用和禁用特性门控，
-请参见[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+请参见[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
 APF 的特性门控称为 `APIPriorityAndFairness`。
 此特性也与某个 {{< glossary_tooltip term_id="api-group" text="API 组" >}}
 相关：
@@ -478,7 +478,7 @@ a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to c
 -->
 下面是两个配置文件，可以用来实现一个带日志代理的边车容器。
 第一个文件包含用来配置 fluentd 的
-[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。
+[ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)。

 {{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}

@@ -12,8 +12,8 @@ You've deployed your application and exposed it via a service. Now what? Kuberne
 你已经部署了应用并通过服务暴露它。然后呢？
 Kubernetes 提供了一些工具来帮助管理你的应用部署，包括扩缩容和更新。
 我们将更深入讨论的特性包括
-[配置文件](/zh/docs/concepts/configuration/overview/)和
-[标签](/zh/docs/concepts/overview/working-with-objects/labels/)。
+[配置文件](/zh-cn/docs/concepts/configuration/overview/)和
+[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。

 <!-- body -->

@@ -85,7 +85,7 @@ A URL can also be specified as a configuration source, which is handy for deploy
 还可以使用 URL 作为配置源，便于直接使用已经提交到 Github 上的配置文件进行部署：

 ```shell
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/zh/examples/application/nginx/nginx-deployment.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/application/nginx/nginx-deployment.yaml
 ```

 ```
@@ -239,7 +239,7 @@ persistentvolumeclaim/my-pvc created
 If you're interested in learning more about `kubectl`, go ahead and read [Command line tool (kubectl)](/docs/reference/kubectl/).
 -->
 如果你有兴趣进一步学习关于 `kubectl` 的内容，请阅读
-[命令行工具（kubectl）](/zh/docs/reference/kubectl/)。
+[命令行工具（kubectl）](/zh-cn/docs/reference/kubectl/)。

 <!--
 ## Using labels effectively
@@ -445,7 +445,7 @@ For more information, please see [labels](/docs/concepts/overview/working-with-o
 （用参数 `-L` 或者 `--label-columns` 标明）。

 想要了解更多信息，请参考
-[标签](/zh/docs/concepts/overview/working-with-objects/labels/) 和
+[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/) 和
 [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands/#label)
 命令文档。

@@ -476,7 +476,7 @@ metadata:
 For more information, please see [annotations](/docs/concepts/overview/working-with-objects/annotations/) and [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate) document.
 -->
 想要了解更多信息，请参考
-[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)和
+[注解](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)和
 [`kubectl annotate`](/docs/reference/generated/kubectl/kubectl-commands/#annotate)
 命令文档。

@@ -535,7 +535,7 @@ For more information, please see [kubectl scale](/docs/reference/generated/kubec
 想要了解更多信息，请参考
 [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale)命令文档、
 [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 命令文档和
-[水平 Pod 自动伸缩](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) 文档。
+[水平 Pod 自动伸缩](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) 文档。

 <!--
 ## In-place updates of resources
@@ -648,7 +648,7 @@ and
 -->
 你可以使用 `kubectl patch` 来更新 API 对象。此命令支持 JSON patch、
 JSON merge patch、以及 strategic merge patch。 请参考
-[使用 kubectl patch 更新 API 对象](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
+[使用 kubectl patch 更新 API 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
 和
 [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch).

@@ -716,7 +716,7 @@ That's it! The Deployment will declaratively update the deployed nginx applicati
 -->
 没错，就是这样！Deployment 将在后台逐步更新已经部署的 nginx 应用。
 它确保在更新过程中，只有一定数量的旧副本被开闭，并且只有一定基于所需 Pod 数量的新副本被创建。
-想要了解更多细节，请参考 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。
+想要了解更多细节，请参考 [Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)。

 ## {{% heading "whatsnext" %}}

@@ -724,5 +724,5 @@ That's it! The Deployment will declaratively update the deployed nginx applicati
 - [Learn about how to use `kubectl` for application introspection and debugging.](/docs/tasks/debug/debug-application/debug-running-pod/)
 - [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/)
 -->
- 学习[如何使用 `kubectl` 观察和调试应用](/zh/docs/tasks/debug/debug-application/debug-running-pod/)
- 阅读[配置最佳实践和技巧](/zh/docs/concepts/configuration/overview/)
+- 学习[如何使用 `kubectl` 观察和调试应用](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/)
+- 阅读[配置最佳实践和技巧](/zh-cn/docs/concepts/configuration/overview/)
@@ -29,8 +29,8 @@ problems to address:
 1. 高度耦合的容器间通信：这个已经被 {{< glossary_tooltip text="Pods" term_id="pod" >}}
   和 `localhost` 通信解决了。
 2. Pod 间通信：本文档讲述重点。
-3. Pod 和服务间通信：由[服务](/zh/docs/concepts/services-networking/service/)负责。
-4. 外部和服务间通信：也由[服务](/zh/docs/concepts/services-networking/service/)负责。
+3. Pod 和服务间通信：由[服务](/zh-cn/docs/concepts/services-networking/service/)负责。
+4. 外部和服务间通信：也由[服务](/zh-cn/docs/concepts/services-networking/service/)负责。

 <!-- body -->

@@ -56,7 +56,7 @@ Kubernetes 的宗旨就是在应用之间共享机器。
 而 API 服务器还需要知道如何将动态端口数值插入到配置模块中，服务也需要知道如何找到对方等等。
 与其去解决这些问题，Kubernetes 选择了其他不同的方法。

-要了解 Kubernetes 网络模型，请参阅[此处](/zh/docs/concepts/services-networking/)。
+要了解 Kubernetes 网络模型，请参阅[此处](/zh-cn/docs/concepts/services-networking/)。
 <!--
 ## How to implement the Kubernetes networking model

@@ -36,7 +36,7 @@ There are several different proxies you may encounter when using Kubernetes:
    - locates apiserver
    - adds authentication headers
 -->
-1. [kubectl proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api)：
+1. [kubectl proxy](/zh-cn/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api)：

    - 运行在用户的桌面或 pod 中
    - 从本机地址到 Kubernetes apiserver 的代理
@@ -56,7 +56,7 @@ There are several different proxies you may encounter when using Kubernetes:
    - can be used to reach a Node, Pod, or Service
    - does load balancing when used to reach a Service
 -->
-2. [apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)：
+2. [apiserver proxy](/zh-cn/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)：

    - 是一个建立在 apiserver 内部的“堡垒”
    - 将集群外部的用户与集群 IP 相连接，这些IP是无法通过其他方式访问的
@@ -75,7 +75,7 @@ There are several different proxies you may encounter when using Kubernetes:
    - provides load balancing
    - is only used to reach services
 -->
-3. [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips)：
+3. [kube proxy](/zh-cn/docs/concepts/services-networking/service/#ips-and-vips)：

    - 在每个节点上运行
    - 代理 UDP、TCP 和 SCTP
@@ -38,7 +38,7 @@ klog 是 Kubernetes 的日志库。
 [klog](https://github.com/kubernetes/klog) 
 为 Kubernetes 系统组件生成日志消息。

-有关 klog 配置的更多信息，请参见[命令行工具参考](/zh/docs/reference/command-line-tools-reference/)。
+有关 klog 配置的更多信息，请参见[命令行工具参考](/zh-cn/docs/reference/command-line-tools-reference/)。

 <!--
 Kubernetes is in the process of simplifying logging in its components. The
@@ -284,7 +284,7 @@ Not all logs are guaranteed to be written in JSON format (for example, during pr
 Field names and JSON serialization are subject to change.
 -->
 JSON 输出并不支持太多标准 klog 参数。对于不受支持的 klog 参数的列表，
-请参见[命令行工具参考](/zh/docs/reference/command-line-tools-reference/)。
+请参见[命令行工具参考](/zh-cn/docs/reference/command-line-tools-reference/)。

 并不是所有日志都保证写成 JSON 格式（例如，在进程启动期间）。
 如果你打算解析日志，请确保可以处理非 JSON 格式的日志行。
@@ -388,7 +388,7 @@ The `logrotate` tool rotates logs daily, or once the log size is greater than 10
 * Read about [deprecation of klog flags](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
 * Read about the [Conventions for logging severity](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)
 -->
-* 阅读 [Kubernetes 日志架构](/zh/docs/concepts/cluster-administration/logging/)
+* 阅读 [Kubernetes 日志架构](/zh-cn/docs/concepts/cluster-administration/logging/)
 * 阅读[结构化日志提案（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging)
 * 阅读[上下文日志提案（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging)
 * 阅读 [klog 参数的废弃（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
@@ -204,7 +204,7 @@ kubelet 在驱动程序上保持打开状态。这意味着为了执行基础结
 现在，收集加速器指标的责任属于供应商，而不是 kubelet。供应商必须提供一个收集指标的容器，
 并将其公开给指标服务（例如 Prometheus）。

-[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+[`DisableAcceleratorUsageMetrics` 特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
 禁止由 kubelet 收集的指标。
 关于[何时会在默认情况下启用此功能也有一定规划](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)。

@@ -271,7 +271,7 @@ The kube-scheduler identifies the resource [requests and limits](/docs/concepts/
 - the unit of the resource if known (for example, `cores`)
 -->
 kube-scheduler 组件能够辩识各个 Pod 所配置的资源
-[请求和约束](/zh/docs/concepts/configuration/manage-resources-containers/)。
+[请求和约束](/zh-cn/docs/concepts/configuration/manage-resources-containers/)。
 在 Pod 的资源请求值或者约束值非零时，kube-scheduler 会以度量值时间序列的形式
 生成报告。该时间序列值包含以下标签：
 - 名字空间
@@ -341,4 +341,4 @@ Here is an example:
 * Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)
 -->
 * 阅读有关指标的 [Prometheus 文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)
-* 阅读有关 [Kubernetes 弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)
+* 阅读有关 [Kubernetes 弃用策略](/zh-cn/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)
@@ -114,7 +114,7 @@ with `--tracing-config-file=<path-to-config>`. This is an example config that re
 spans for 1 in 10000 requests, and uses the default OpenTelemetry endpoint:
 -->
 要启用追踪特性，需要启用 kube-apiserver 上的  `APIServerTracing`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
 然后，使用 `--tracing-config-file=<<配置文件路径>` 为 kube-apiserver 提供追踪配置文件。
 下面是一个示例配置，它为万分之一的请求记录 spans，并使用了默认的 OpenTelemetry 端口。

@@ -132,7 +132,7 @@ For more information about the `TracingConfiguration` struct, see
 -->

 有关 TracingConfiguration 结构体的更多信息，请参阅 
-[API 服务器配置 API (v1alpha1)](/zh/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)。
+[API 服务器配置 API (v1alpha1)](/zh-cn/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)。

 <!-- 
 ## Stability
@@ -73,7 +73,7 @@ The name of a ConfigMap must be a valid
 -->
 ## ConfigMap 对象

-ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)，
+ConfigMap 是一个 API [对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/)，
 让你可以存储其他对象所需要使用的配置。
 和其他 Kubernetes 对象都有一个 `spec` 不同的是，ConfigMap 使用 `data` 和
 `binaryData` 字段。这些字段能够接收键-值对作为其取值。`data` 和 `binaryData`
@@ -81,7 +81,7 @@ ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects
 则被设计用来保存二进制数据作为 base64 编码的字串。

 ConfigMap 的名字必须是一个合法的
-[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)。

 <!--
 Each key under the `data` or the `binaryData` field must consist of
@@ -367,7 +367,7 @@ the [KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1be
 kubelet 组件会在每次周期性同步时检查所挂载的 ConfigMap 是否为最新。
 不过，kubelet 使用的是其本地的高速缓存来获得 ConfigMap 的当前值。
 高速缓存的类型可以通过
-[KubeletConfiguration 结构](/zh/docs/reference/config-api/kubelet-config.v1beta1/).
+[KubeletConfiguration 结构](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/).
 的 `ConfigMapAndSecretChangeDetectionStrategy` 字段来配置。

 <!--
@@ -395,7 +395,7 @@ ConfigMaps consumed as environment variables are not updated automatically and r
 A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes#using-subpath) volume mount will not receive ConfigMap updates.
 -->
 {{< note >}}
-使用 ConfigMap 作为 [subPath](/zh/docs/concepts/storage/volumes#using-subpath) 卷挂载的容器将不会收到 ConfigMap 的更新。
+使用 ConfigMap 作为 [subPath](/zh-cn/docs/concepts/storage/volumes#using-subpath) 卷挂载的容器将不会收到 ConfigMap 的更新。
 {{< /note >}}

 <!--
@@ -432,7 +432,7 @@ You can create an immutable ConfigMap by setting the `immutable` field to `true`
 For example:
 -->
 此功能特性由 `ImmutableEphemeralVolumes`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)来控制。
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)来控制。
 你可以通过将 `immutable` 字段设置为 `true` 创建不可变更的 ConfigMap。
 例如：

@@ -465,7 +465,7 @@ to the deleted ConfigMap, it is recommended to recreate these pods.
 * Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for
  separating code from configuration.
 -->
-* 阅读 [Secret](/zh/docs/concepts/configuration/secret/)。
-* 阅读[配置 Pod 使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。
-* 阅读[修改 ConfigMap（或任何其他 Kubernetes 对象）](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。
+* 阅读 [Secret](/zh-cn/docs/concepts/configuration/secret/)。
+* 阅读[配置 Pod 使用 ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)。
+* 阅读[修改 ConfigMap（或任何其他 Kubernetes 对象）](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。
 * 阅读 [Twelve-Factor 应用](https://12factor.net/zh_cn/)来了解将代码和配置分开的动机。
@@ -145,8 +145,8 @@ through the Kubernetes API server.
 -->
 CPU 和内存统称为“计算资源”，或简称为“资源”。
 计算资源的数量是可测量的，可以被请求、被分配、被消耗。
-它们与 [API 资源](/zh/docs/concepts/overview/kubernetes-api/) 不同。
-API 资源（如 Pod 和 [Service](/zh/docs/concepts/services-networking/service/)）是可通过
+它们与 [API 资源](/zh-cn/docs/concepts/overview/kubernetes-api/) 不同。
+API 资源（如 Pod 和 [Service](/zh-cn/docs/concepts/services-networking/service/)）是可通过
 Kubernetes API 服务器读取和修改的对象。

 <!--
@@ -417,11 +417,11 @@ directly or from your monitoring tools.
 ## 监控计算和内存资源用量

 kubelet 会将 Pod 的资源使用情况作为 Pod
-[`status`](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status)
+[`status`](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status)
 的一部分来报告的。

-如果为集群配置了可选的[监控工具](/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)，
-则可以直接从[指标 API](/zh/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api) 
+如果为集群配置了可选的[监控工具](/zh-cn/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)，
+则可以直接从[指标 API](/zh-cn/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api) 
 或者监控工具获得 Pod 的资源使用情况。

 <!--
@@ -448,7 +448,7 @@ mount [`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir

 Pods 通常可以使用临时性本地存储来实现缓冲区、保存日志等功能。
 kubelet 可以为使用本地临时存储的 Pods 提供这种存储空间，允许后者使用
-[`emptyDir`](/zh/docs/concepts/storage/volumes/#emptydir) 类型的
+[`emptyDir`](/zh-cn/docs/concepts/storage/volumes/#emptydir) 类型的
 {{< glossary_tooltip term_id="volume" text="卷" >}}将其挂载到容器中。

 <!--
@@ -465,7 +465,7 @@ of ephemeral local storage a Pod can consume.
 -->

 kubelet 也使用此类存储来保存
-[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)，
+[节点层面的容器日志](/zh-cn/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)，
 容器镜像文件、以及运行中容器的可写入层。

 {{< caution >}}
@@ -502,7 +502,7 @@ Kubernetes 有两种方式支持节点上配置本地临时性存储：
 （kubelet）来保存数据的。

 kubelet 也会生成
-[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)，
+[节点层面的容器日志](/zh-cn/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)，
 并按临时性本地存储的方式对待之。

 <!--
@@ -553,7 +553,7 @@ as you like.
 无关的其他系统日志）；这个文件系统还可以是根文件系统。

 kubelet 也将
-[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
+[节点层面的容器日志](/zh-cn/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
 写入到第一个文件系统中，并按临时性本地存储的方式对待之。

 同时你使用另一个由不同逻辑存储设备支持的文件系统。在这种配置下，你会告诉
@@ -587,7 +587,7 @@ than as local ephemeral storage.
 kubelet 能够度量其本地存储的用量。实现度量机制的前提是：

 - `LocalStorageCapacityIsolation`
-  [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+  [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
  被启用（默认状态），并且
 - 你已经对节点进行了配置，使之使用所支持的本地临时性储存配置方式之一

@@ -688,7 +688,7 @@ The scheduler ensures that the sum of the resource requests of the scheduled con
 当你创建一个 Pod 时，Kubernetes 调度器会为 Pod 选择一个节点来运行之。
 每个节点都有一个本地临时性存储的上限，是其可提供给 Pods 使用的总量。
 欲了解更多信息，可参考
-[节点可分配资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
+[节点可分配资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
 节。

 调度器会确保所调度的容器的资源请求总和不会超出节点的资源容量。
@@ -873,8 +873,8 @@ If you want to use project quotas, you should:

 如果你希望使用项目配额，你需要：

-* 在 [kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/)中使用 `featureGates` 字段 或者使用 `--feature-gates` 命令行参数
-启用 `LocalStorageCapacityIsolationFSQuotaMonitoring=true` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 。
+* 在 [kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)中使用 `featureGates` 字段 或者使用 `--feature-gates` 命令行参数
+启用 `LocalStorageCapacityIsolationFSQuotaMonitoring=true` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 。

 * 确保根文件系统（或者可选的运行时文件系统）启用了项目配额。所有 XFS
  文件系统都支持项目配额。
@@ -933,7 +933,7 @@ for how to advertise device plugin managed resources on each node.
 ##### 设备插件管理的资源   {#device-plugin-managed-resources}

 有关如何颁布在各节点上由设备插件所管理的资源，请参阅
-[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。
+[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。

 <!--
 ##### Other resources
@@ -1011,7 +1011,7 @@ in [scheduler policy configuration](/docs/reference/config-api/kube-scheduler-co
 集群层面的扩展资源并不绑定到具体节点。
 它们通常由调度器扩展程序（Scheduler Extenders）管理，这些程序处理资源消耗和资源配额。

-你可以在[调度器策略配置](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/)
+你可以在[调度器策略配置](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/)
 中指定由调度器扩展程序处理的扩展资源。

 <!--
@@ -1139,7 +1139,7 @@ to limit the number of PIDs that a given Pod can consume. See
 ## PID 限制   {#pid-limiting}

 进程 ID（PID）限制允许对 kubelet 进行配置，以限制给定 Pod 可以消耗的 PID 数量。
-有关信息，请参见 [PID 限制](/zh/docs/concepts/policy/pid-limiting/)。
+有关信息，请参见 [PID 限制](/zh-cn/docs/concepts/policy/pid-limiting/)。

 <!--
 ## Troubleshooting
@@ -1264,7 +1264,7 @@ For more information on node allocatable resources in Kubernetes, see
 -->
 字段 `.status.allocatable` 描述节点上可以用于 Pod 的资源总量（例如：15 个虚拟
 CPU、7538 MiB 内存）。关于 Kubernetes 中节点可分配资源的信息，可参阅
-[为系统守护进程预留计算资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/)。
+[为系统守护进程预留计算资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/)。

 <!--
 You can configure [resource quotas](/docs/concepts/policy/resource-quotas/)
@@ -1279,7 +1279,7 @@ You should also consider what access you grant to that namespace:
 **full** write access to a namespace allows someone with that access to remove any
 resource, include a configured ResourceQuota.
 -->
-你可以配置[资源配额](/zh/docs/concepts/policy/resource-quotas/)功能特性以限制每个名字空间可以使用的资源总量。
+你可以配置[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/)功能特性以限制每个名字空间可以使用的资源总量。
 当某名字空间中存在 ResourceQuota 时，Kubernetes 会在该名字空间中的对象强制实施配额。
 例如，如果你为不同的团队分配名字空间，你可以为这些名字空间添加 ResourceQuota。
 设置资源配额有助于防止一个团队占用太多资源，以至于这种占用会影响其他团队。
@@ -1375,10 +1375,10 @@ memory limit (and possibly request) for that container.
 * Read about [project quotas](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS
 * Read more about the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
 -->
-* 获取[分配内存资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验
-* 获取[分配 CPU 资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验
+* 获取[分配内存资源给容器和 Pod ](/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验
+* 获取[分配 CPU 资源给容器和 Pod ](/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验
 * 阅读 API 参考中 [Container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)
  和其[资源请求](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)定义。
 * 阅读 XFS 中[配额](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)的文档
-* 进一步阅读 [kube-scheduler 配置参考 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/)
+* 进一步阅读 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/)

@@ -58,7 +58,7 @@ For step-by-step instructions on creating and specifying kubeconfig files, see
 [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
 -->
 有关创建和指定 kubeconfig 文件的分步说明，请参阅
-[配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。
+[配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。

 <!-- body -->

@@ -193,7 +193,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
   [Setting the KUBECONFIG environment variable](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
 -->
   有关设置 `KUBECONFIG` 环境变量的示例，请参阅
-   [设置 KUBECONFIG 环境变量](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。
+   [设置 KUBECONFIG 环境变量](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。

 <!--
   Otherwise, use the default kubeconfig file, `$HOME/.kube/config`, with no merging.
@@ -319,5 +319,5 @@ contexts:
 * [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
 * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
 --->
-* [配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+* [配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
 * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
@@ -77,8 +77,8 @@ This is a living document. If you think of something that is not on this list bu
 - Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure.
 -->
 - 如果可能，不要使用独立的 Pods（即，未绑定到
-[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) 或
-[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 的 Pod）。
+[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 或
+[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/) 的 Pod）。
 如果节点发生故障，将不会重新调度独立的 Pods。

 <!--
@@ -86,9 +86,9 @@ This is a living document. If you think of something that is not on this list bu
 -->

 Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终可用，也可以指定替换 Pod 的策略（例如
-[RollingUpdate](/zh/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)）。
-除了一些显式的 [`restartPolicy: Never`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
-场景外，Deployment 通常比直接创建 Pod 要好得多。[Job](/zh/docs/concepts/workloads/controllers/job/) 也可能是合适的选择。
+[RollingUpdate](/zh-cn/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)）。
+除了一些显式的 [`restartPolicy: Never`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
+场景外，Deployment 通常比直接创建 Pod 要好得多。[Job](/zh-cn/docs/concepts/workloads/controllers/job/) 也可能是合适的选择。

 <!--
 ## Services
@@ -99,7 +99,7 @@ Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终
 - Create a [Service](/docs/concepts/services-networking/service/) before its corresponding backend workloads (Deployments or ReplicaSets), and before any workloads that need to access it. When Kubernetes starts a container, it provides environment variables pointing to all the Services which were running when the container was started. For example, if a Service named `foo` exists, all containers will get the following variables in their initial environment:
 -->
 - 在创建相应的后端工作负载（Deployment 或 ReplicaSet），以及在需要访问它的任何工作负载之前创建
-  [服务](/zh/docs/concepts/services-networking/service/)。
+  [服务](/zh-cn/docs/concepts/services-networking/service/)。
  当 Kubernetes 启动容器时，它提供指向启动容器时正在运行的所有服务的环境变量。
  例如，如果存在名为 `foo` 的服务，则所有容器将在其初始环境中获得以下变量。

@@ -118,7 +118,7 @@ Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终
 - An optional (though strongly recommended) [cluster add-on](/docs/concepts/cluster-administration/addons/) is a DNS server.  The
 DNS server watches the Kubernetes API for new `Services` and creates a set of DNS records for each.  If DNS has been enabled throughout the cluster then all `Pods` should be able to do name resolution of `Services` automatically.
 -->
- 一个可选（尽管强烈推荐）的[集群插件](/zh/docs/concepts/cluster-administration/addons/)
+- 一个可选（尽管强烈推荐）的[集群插件](/zh-cn/docs/concepts/cluster-administration/addons/)
  是 DNS 服务器。DNS 服务器为新的 `Services` 监视 Kubernetes API，并为每个创建一组 DNS 记录。
  如果在整个集群中启用了 DNS，则所有 `Pods` 应该能够自动对 `Services` 进行名称解析。

@@ -135,14 +135,14 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN
  If you only need access to the port for debugging purposes, you can use the [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
 -->
  如果你只需要访问端口以进行调试，则可以使用
-  [apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或
-  [`kubectl port-forward`](/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。
+  [apiserver proxy](/zh-cn/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或
+  [`kubectl port-forward`](/zh-cn/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。

 <!--
  If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#type-nodeport) Service before resorting to `hostPort`.
 -->
  如果你明确需要在节点上公开 Pod 的端口，请在使用 `hostPort` 之前考虑使用
-  [NodePort](/zh/docs/concepts/services-networking/service/#type-nodeport) 服务。
+  [NodePort](/zh-cn/docs/concepts/services-networking/service/#type-nodeport) 服务。

 <!--
 - Avoid using `hostNetwork`, for the same reasons as `hostPort`.
@@ -154,7 +154,7 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN
 services) (which have a `ClusterIP` of `None`) for service discovery when you don't need `kube-proxy` load balancing.
 -->
 - 当你不需要 `kube-proxy` 负载均衡时，使用
-  [无头服务](/zh/docs/concepts/services-networking/service/#headless-services)  
+  [无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)  
  (`ClusterIP` 被设置为 `None`)以便于服务发现。

 <!--
@@ -165,7 +165,7 @@ services) (which have a `ClusterIP` of `None`) for service discovery when you do
 <!--
 - Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) app for examples of this approach.
 -->
- 定义并使用[标签](/zh/docs/concepts/overview/working-with-objects/labels/)来识别应用程序
+- 定义并使用[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)来识别应用程序
  或 Deployment 的 __语义属性__，例如`{ app: myapp, tier: frontend, phase: test, deployment: v3 }`。
  你可以使用这些标签为其他资源选择合适的 Pod；
  例如，一个选择所有 `tier: frontend` Pod 的服务，或者 `app: myapp` 的所有 `phase: test` 组件。
@@ -175,7 +175,7 @@ services) (which have a `ClusterIP` of `None`) for service discovery when you do
 A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. [Deployments](/docs/concepts/workloads/controllers/deployment/) make it easy to update a running service without downtime.
 -->
 通过从选择器中省略特定发行版的标签，可以使服务跨越多个 Deployment。
-当你需要不停机的情况下更新正在运行的服务，可以使用[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。
+当你需要不停机的情况下更新正在运行的服务，可以使用[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)。

 <!--
 A desired state of an object is described by a Deployment, and if changes to that spec are _applied_, the deployment controller changes the actual state to the desired state at a controlled rate.
@@ -187,9 +187,9 @@ Deployment 描述了对象的期望状态，并且如果对该规范的更改被
 - Use the [Kubernetes common labels](/docs/concepts/overview/working-with-objects/common-labels/) for common use cases. These standardized labels enrich the metadata in a way that allows tools, including `kubectl` and [dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard), to work in an interoperable way.
 -->

- 对于常见场景，应使用 [Kubernetes 通用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)。
+- 对于常见场景，应使用 [Kubernetes 通用标签](/zh-cn/docs/concepts/overview/working-with-objects/common-labels/)。
  这些标准化的标签丰富了对象的元数据，使得包括 `kubectl` 和
-  [仪表板（Dashboard）](/zh/docs/tasks/access-application-cluster/web-ui-dashboard)
+  [仪表板（Dashboard）](/zh-cn/docs/tasks/access-application-cluster/web-ui-dashboard)
  这些工具能够以可互操作的方式工作。

 <!--
@@ -217,13 +217,13 @@ Deployment 描述了对象的期望状态，并且如果对该规范的更改被
 - Use label selectors for `get` and `delete` operations instead of specific object names. See the sections on [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
 -->
 - 使用标签选择器进行 `get` 和 `delete` 操作，而不是特定的对象名称。
- 请参阅[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)和
-  [有效使用标签](/zh/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。
+- 请参阅[标签选择器](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)和
+  [有效使用标签](/zh-cn/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。

 <!--
 - Use `kubectl run` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example.
 -->
 - 使用`kubectl run`和`kubectl expose`来快速创建单容器部署和服务。
-  有关示例，请参阅[使用服务访问集群中的应用程序](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)。
+  有关示例，请参阅[使用服务访问集群中的应用程序](/zh-cn/docs/tasks/access-application-cluster/service-access-application-cluster/)。


@@ -74,8 +74,8 @@ In order to safely use Secrets, take at least the following steps:

 为了安全地使用 Secret，请至少执行以下步骤：

-1. 为 Secret [启用静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)；
-1. [启用或配置 RBAC 规则](/zh/docs/reference/access-authn-authz/authorization/)来限制读取和写入
+1. 为 Secret [启用静态加密](/zh-cn/docs/tasks/administer-cluster/encrypt-data/)；
+1. [启用或配置 RBAC 规则](/zh-cn/docs/reference/access-authn-authz/authorization/)来限制读取和写入
   Secret 的数据（包括通过间接方式）。需要注意的是，被准许创建 Pod 的人也隐式地被授权获取
   Secret 内容。
 1. 在适当的情况下，还可以使用 RBAC 等机制来限制允许哪些主体创建新 Secret 或替换现有 Secret。
@@ -139,7 +139,7 @@ Here are some of your options:
  token).
 -->
 - 如果你的云原生组件需要执行身份认证来访问你所知道的、在同一 Kubernetes 集群中运行的另一个应用，
-  你可以使用 [ServiceAccount](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)
+  你可以使用 [ServiceAccount](/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens)
  及其令牌来标识你的客户端身份。
 - 你可以运行的第三方工具也有很多，这些工具可以运行在集群内或集群外，提供机密数据管理。
  例如，这一工具可能是 Pod 通过 HTTPS 访问的一个服务，该服务在客户端能够正确地通过身份认证
@@ -153,9 +153,9 @@ Here are some of your options:
  trusted Pods onto nodes that provide a Trusted Platform Module, configured out-of-band.
 -->
 - 就身份认证而言，你可以为 X.509 证书实现一个定制的签名者，并使用
-  [CertificateSigningRequest](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)
+  [CertificateSigningRequest](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/)
  来让该签名者为需要证书的 Pod 发放证书。
- 你可以使用一个[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
+- 你可以使用一个[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
  来将节点本地的加密硬件暴露给特定的 Pod。例如，你可以将可信任的 Pod
  调度到提供可信平台模块（Trusted Platform Module，TPM）的节点上。
  这类节点是另行配置的。
@@ -191,9 +191,9 @@ There are several options to create a Secret:

 ### 创建 Secret  {#creating-a-secret}

- [使用 `kubectl` 命令来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- [基于配置文件来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- [使用 kustomize 来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
+- [使用 `kubectl` 命令来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- [基于配置文件来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- [使用 kustomize 来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize/)

 <!--
 #### Constraints on Secret names and data {#restriction-names-data}
@@ -204,7 +204,7 @@ The name of a Secret object must be a valid
 #### 对 Secret 名称与数据的约束 {#restriction-names-data}

 Secret 对象的名称必须是合法的
-[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)。

 <!--
 You can specify the `data` and/or the `stringData` field when creating a
@@ -242,7 +242,7 @@ number of Secrets (or other resources) in a namespace.

 每个 Secret 的尺寸最多为 1MiB。施加这一限制是为了避免用户创建非常大的 Secret，
 进而导致 API 服务器和 kubelet 内存耗尽。不过创建很多小的 Secret 也可能耗尽内存。
-你可以使用[资源配额](/zh/docs/concepts/policy/resource-quotas/)来约束每个名字空间中
+你可以使用[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/)来约束每个名字空间中
 Secret（或其他资源）的个数。

 <!--
@@ -438,7 +438,7 @@ Kubernetes v1.22 版本之前都会自动创建用来访问 Kubernetes API 的
 这一老的机制是基于创建可被挂载到 Pod 中的令牌 Secret 来实现的。
 在最近的版本中，包括 Kubernetes v{{< skew currentVersion >}} 中，API 凭据是直接通过
 [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
-API 来获得的，这一凭据会使用[投射卷](/zh/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)
+API 来获得的，这一凭据会使用[投射卷](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)
 挂载到 Pod 中。使用这种方式获得的令牌有确定的生命期，并且在挂载它们的 Pod
 被删除时自动作废。

@@ -450,7 +450,7 @@ subresource to obtain a token to access the API is recommended instead.
 You can use the [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-)
 command to obtain a token from the `TokenRequest` API.
 -->
-你仍然可以[手动创建](/zh/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)
+你仍然可以[手动创建](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)
 服务账号令牌。例如，当你需要一个永远都不过期的令牌时。
 不过，仍然建议使用 [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
 子资源来获得访问 API 服务器的令牌。
@@ -648,7 +648,7 @@ A container using a Secret as a
 [subPath](/docs/concepts/storage/volumes#using-subpath) volume mount does not receive
 automated Secret updates.
 -->
-对于以 [subPath](/zh/docs/concepts/storage/volumes#using-subpath) 形式挂载 Secret 卷的容器而言，
+对于以 [subPath](/zh-cn/docs/concepts/storage/volumes#using-subpath) 形式挂载 Secret 卷的容器而言，
 它们无法收到自动的 Secret 更新。
 {{< /note >}}

@@ -660,7 +660,7 @@ the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/)
 -->
 Kubelet 组件会维护一个缓存，在其中保存节点上 Pod 卷中使用的 Secret 的当前主键和取值。
 你可以配置 kubelet 如何检测所缓存数值的变化。
-[kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/)中的
+[kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)中的
 `configMapAndSecretChangeDetectionStrategy` 字段控制 kubelet 所采用的策略。
 默认的策略是 `Watch`。

@@ -886,7 +886,7 @@ documentation.
 -->
 ##### 手动设定 imagePullSecret {#manually-specifying-an-imagepullsecret}

-你可以通过阅读[容器镜像](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
+你可以通过阅读[容器镜像](/zh-cn/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
 文档了解如何设置 `imagePullSecrets`。

 <!--
@@ -904,7 +904,7 @@ See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-contai
 你可以手动创建 `imagePullSecret`，并在一个 ServiceAccount 中引用它。
 对使用该 ServiceAccount 创建的所有 Pod，或者默认使用该 ServiceAccount 创建的 Pod
 而言，其 `imagePullSecrets` 字段都会设置为该服务账号。
-请阅读[向服务账号添加 ImagePullSecrets](/zh/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
+请阅读[向服务账号添加 ImagePullSecrets](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
 来详细了解这一过程。

 <!--
@@ -1549,7 +1549,7 @@ You can also check the `automountServiceAccountToken` field and the
 [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
 for information on referencing service account credentials from within Pods.
 -->
-参考 [ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/)
+参考 [ServiceAccount](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)
 文档了解服务账号的工作原理。你也可以查看
 [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
 资源中的 `automountServiceAccountToken` 和 `serviceAccountName` 字段文档，
@@ -1814,7 +1814,7 @@ The following YAML contains an example config for a TLS Secret:

 Kubernetes 提供一种内置的 `kubernetes.io/tls` Secret 类型，用来存放 TLS
 场合通常要使用的证书及其相关密钥。
-TLS Secret 的一种典型用法是为 [Ingress](/zh/docs/concepts/services-networking/ingress/)
+TLS Secret 的一种典型用法是为 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)
 资源配置传输过程中的数据加密，不过也可以用于其他资源或者直接在负载中使用。
 当使用此类型的 Secret 时，Secret 配置中的 `data` （或 `stringData`）字段必须包含
 `tls.key` 和 `tls.crt` 主键，尽管 API 服务器实际上并不会对每个键的取值作进一步的合法性检查。
@@ -2164,8 +2164,8 @@ on that node.
  [authorization policies](/docs/reference/access-authn-authz/authorization/) such as
  [RBAC](/docs/reference/access-authn-authz/rbac/).
 -->
- 部署与 Secret API 交互的应用时，你应该使用 [RBAC](/zh/docs/reference/access-authn-authz/rbac/)
-  这类[鉴权策略](/zh/docs/reference/access-authn-authz/authorization/)来限制访问。
+- 部署与 Secret API 交互的应用时，你应该使用 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)
+  这类[鉴权策略](/zh-cn/docs/reference/access-authn-authz/authorization/)来限制访问。
 <!--
 - In the Kubernetes API, `watch` and `list` requests for Secrets within a namespace
  are extremely powerful capabilities. Avoid granting this access where feasible, since
@@ -2203,8 +2203,8 @@ Pod 来访问 Secret 的内容。
 - 保留（使用 Kubernetes API）对集群中所有 Secret 对象执行 `watch` 或 `list` 操作的能力，
  这样只有特权级最高、系统级别的组件能够执行这类操作。
 - 在部署需要通过 Secret API 交互的应用时，你应该通过使用
-  [RBAC](/zh/docs/reference/access-authn-authz/rbac/)
-  这类[鉴权策略](/zh/docs/reference/access-authn-authz/authorization/)来限制访问。
+  [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)
+  这类[鉴权策略](/zh-cn/docs/reference/access-authn-authz/authorization/)来限制访问。
 <!--
 - In the API server, objects (including Secrets) are persisted into
  {{< glossary_tooltip term_id="etcd" >}}; therefore:
@@ -2221,7 +2221,7 @@ Pod 来访问 Secret 的内容。
  因此：

  - 只应准许集群管理员访问 etcd（包括只读访问）；
-  - 为 Secret 对象启用[静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)，
+  - 为 Secret 对象启用[静态加密](/zh-cn/docs/tasks/administer-cluster/encrypt-data/)，
    这样这些 Secret 的数据就不会以明文的形式保存到
    {{< glossary_tooltip term_id="etcd" >}} 中；
  - 当 etcd 的持久化存储不再被使用时，请考虑彻底擦除存储介质；
@@ -2235,8 +2235,8 @@ Pod 来访问 Secret 的内容。
 - Learn how to [manage Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
 - Read the [API reference](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/) for `Secret`
 -->
- 学习如何[使用 `kubectl` 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- 学习如何[使用配置文件管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- 学习如何[使用 kustomize 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
- 阅读 [API 参考](/zh/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)了解 `Secret`
+- 学习如何[使用 `kubectl` 管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- 学习如何[使用配置文件管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- 学习如何[使用 kustomize 管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
+- 阅读 [API 参考](/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)了解 `Secret`

@@ -104,7 +104,7 @@ On Windows these values are only used to calculate the node's

 为了满足操作系统、容器运行时和 kubelet 等 Kubernetes 主机进程使用的内存和 CPU，
 你可以（且应该）用 `--kube-reserved` 和/或 `--system-reserved` kubelet 标志来预留内存和 CPU 资源。
-在 Windows 上，这些值仅用于计算节点的[可分配](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)资源。
+在 Windows 上，这些值仅用于计算节点的[可分配](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)资源。

 <!--
 As you deploy workloads, set resource memory and CPU limits on containers.
@@ -36,7 +36,7 @@ the change, then recreate the container to start from the updated image.
 -->

 ## 容器镜像 {#container-images}
-[容器镜像](/zh/docs/concepts/containers/images/)是一个随时可以运行的软件包，
+[容器镜像](/zh-cn/docs/concepts/containers/images/)是一个随时可以运行的软件包，
 包含运行应用程序所需的一切：代码和它需要的所有运行时、应用程序和系统库，以及一些基本设置的默认值。

 根据设计，容器是不可变的：你不能更改已经运行的容器的代码。
@@ -53,7 +53,7 @@ the change, then recreate the container to start from the updated image.
 * Read about [Pods](/docs/concepts/workloads/pods/)
 -->

-* 进一步阅读[容器镜像](/zh/docs/concepts/containers/images/)
-* 进一步阅读 [Pods](/zh/docs/concepts/workloads/pods/)
+* 进一步阅读[容器镜像](/zh-cn/docs/concepts/containers/images/)
+* 进一步阅读 [Pods](/zh-cn/docs/concepts/workloads/pods/)


@@ -34,8 +34,8 @@ The Kubernetes Container environment provides several important resources to Con

 Kubernetes 的容器环境给容器提供了几个重要的资源：

-* 文件系统，其中包含一个[镜像](/zh/docs/concepts/containers/images/)
-  和一个或多个的[卷](/zh/docs/concepts/storage/volumes/)
+* 文件系统，其中包含一个[镜像](/zh-cn/docs/concepts/containers/images/)
+  和一个或多个的[卷](/zh-cn/docs/concepts/storage/volumes/)
 * 容器自身的信息
 * 集群中其他对象的信息

@@ -59,7 +59,7 @@ as are any environment variables specified statically in the container image.
 [`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) 函数来获取。

 Pod 名称和命名空间可以通过
-[下行 API](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)
+[下行 API](/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)
 转换为环境变量。

 Pod 定义中的用户所定义的环境变量也可在容器中使用，就像在 container 镜像中静态指定的任何环境变量一样。
@@ -100,7 +100,7 @@ if [DNS addon](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addon
 * Get hands-on experience
  [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
 -->
-* 学习更多有关[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)的知识
-* 动手[为容器生命周期事件添加处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
+* 学习更多有关[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)的知识
+* 动手[为容器生命周期事件添加处理程序](/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)


@@ -80,7 +80,7 @@ A more detailed description of the termination behavior can be found in
 [Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
 -->
 有关终止行为的更详细描述，请参见
-[终止 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)。
+[终止 Pod](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)。

 <!--
 ### Hook handler implementations
@@ -250,6 +250,6 @@ Events:
  [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
 -->

-* 进一步了解[容器环境](/zh/docs/concepts/containers/container-environment/)
-* 动手实践，[为容器生命周期事件添加处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
+* 进一步了解[容器环境](/zh-cn/docs/concepts/containers/container-environment/)
+* 动手实践，[为容器生命周期事件添加处理程序](/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)

@@ -101,7 +101,7 @@ these values have:
 -->
 ### 镜像拉取策略   {#image-pull-policy}

-容器的 `imagePullPolicy` 和镜像的标签会影响 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 尝试拉取（下载）指定的镜像。
+容器的 `imagePullPolicy` 和镜像的标签会影响 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 尝试拉取（下载）指定的镜像。

 以下列表包含了 `imagePullPolicy` 可以设置的值，以及这些值的效果：

@@ -179,7 +179,7 @@ running the same code no matter what tag changes happen at the registry.
 镜像摘要唯一标识了镜像的特定版本，因此 Kubernetes 每次启动具有指定镜像名称和摘要的容器时，都会运行相同的代码。
 通过摘要指定镜像可固定你运行的代码，这样镜像仓库的变化就不会导致版本的混杂。

-有一些第三方的[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)
+有一些第三方的[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)
 在创建 Pod（和 Pod 模板）时产生变更，这样运行的工作负载就是根据镜像摘要，而不是标签来定义的。
 无论镜像仓库上的标签发生什么变化，你都想确保你所有的工作负载都运行相同的代码，那么指定镜像摘要会很有用。

@@ -247,7 +247,7 @@ If you would like to always force a pull, you can do one of the following:
  当你提交 Pod 时，Kubernetes 会将策略设置为 `Always`。
 - 省略 `imagePullPolicy` 和镜像的标签；
  当你提交 Pod 时，Kubernetes 会将策略设置为 `Always`。
- 启用准入控制器 [AlwaysPullImages](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。
+- 启用准入控制器 [AlwaysPullImages](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。


 <!--
@@ -260,7 +260,7 @@ state because of `ImagePullBackOff`.
 ### ImagePullBackOff

 当 kubelet 使用容器运行时创建 Pod 时，容器可能因为 `ImagePullBackOff` 导致状态为
-[Waiting](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-state-waiting)。
+[Waiting](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-state-waiting)。

 <!--
 The status `ImagePullBackOff` means that a container could not start because Kubernetes
@@ -366,7 +366,7 @@ For an example of configuring a private container image registry, see the
 task. That example uses a private registry in Docker Hub.
 -->
 有关配置私有容器镜像仓库的示例，请参阅任务
-[从私有镜像库中提取图像](/zh/docs/tasks/configure-pod-container/pull-image-private-registry)。
+[从私有镜像库中提取图像](/zh-cn/docs/tasks/configure-pod-container/pull-image-private-registry)。
 该示例使用 Docker Hub 中的私有注册表。

 <!--
@@ -560,7 +560,7 @@ command, you can import the credentials file as a Kubernetes
 如果你已经有 Docker 凭据文件，则可以将凭据文件导入为 Kubernetes
 {{< glossary_tooltip text="Secret" term_id="secret" >}}，
 而不是执行上面的命令。
-[基于已有的 Docker 凭据创建 Secret](/zh/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)
+[基于已有的 Docker 凭据创建 Secret](/zh-cn/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)
 解释了如何完成这一操作。

 <!--
@@ -628,10 +628,10 @@ will be merged.
 -->
 你需要对使用私有仓库的每个 Pod 执行以上操作。
 不过，设置该字段的过程也可以通过为
-[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/)
+[服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)
 资源设置 `imagePullSecrets` 来自动完成。
 有关详细指令可参见
-[将 ImagePullSecrets 添加到服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)。
+[将 ImagePullSecrets 添加到服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)。

 你也可以将此方法与节点级别的 `.docker/config.json` 配置结合使用。
 来自不同来源的凭据会被合并。
@@ -685,7 +685,7 @@ common use cases and suggested solutions.
   - Move sensitive data into a "Secret" resource, instead of packaging it in an image.
 -->
 3. 集群使用专有镜像，且有些镜像需要更严格的访问控制
-   - 确保 [AlwaysPullImages 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)被启用。否则，所有 Pod 都可以使用所有镜像。
+   - 确保 [AlwaysPullImages 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)被启用。否则，所有 Pod 都可以使用所有镜像。
   - 确保将敏感数据存储在 Secret 资源中，而不是将其打包在镜像里

 <!--
@@ -696,7 +696,7 @@ common use cases and suggested solutions.
   - The tenant adds that secret to imagePullSecrets of each namespace.
 -->
 4. 集群是多租户的并且每个租户需要自己的私有仓库
-   - 确保 [AlwaysPullImages 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。否则，所有租户的所有的 Pod 都可以使用所有镜像。
+   - 确保 [AlwaysPullImages 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。否则，所有租户的所有的 Pod 都可以使用所有镜像。
   - 为私有仓库启用鉴权
   - 为每个租户生成访问仓库的凭据，放置在 Secret 中，并将 Secrert 发布到各租户的命名空间下。
   - 租户将 Secret 添加到每个名字空间中的 imagePullSecrets
@@ -716,4 +716,4 @@ Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.
 * Learn about [container image garbage collection](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection).
 -->
 * 阅读 [OCI Image Manifest 规范](https://github.com/opencontainers/image-spec/blob/master/manifest.md)。
-* 了解[容器镜像垃圾收集](/zh/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)。
+* 了解[容器镜像垃圾收集](/zh-cn/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)。
@@ -92,7 +92,7 @@ The configurations have a corresponding `handler` name, referenced by the Runtim
 handler must be a valid [DNS label name](/docs/concepts/overview/working-with-objects/names/#dns-label-names).
 -->
 所有这些配置都具有相应的 `handler` 名，并被 RuntimeClass 引用。
-handler 必须是有效的 [DNS 标签名](/zh/docs/concepts/overview/working-with-objects/names/#dns-label-names)。
+handler 必须是有效的 [DNS 标签名](/zh-cn/docs/concepts/overview/working-with-objects/names/#dns-label-names)。

 <!--
 ### 2. Create the corresponding RuntimeClass resources
@@ -131,7 +131,7 @@ restricted to the cluster administrator. This is typically the default. See
 -->
 {{< note >}}
 建议将 RuntimeClass 写操作（create、update、patch 和 delete）限定于集群管理员使用。
-通常这是默认配置。参阅[授权概述](/zh/docs/reference/access-authn-authz/authorization/)了解更多信息。
+通常这是默认配置。参阅[授权概述](/zh-cn/docs/reference/access-authn-authz/authorization/)了解更多信息。
 {{< /note >}}

 <!--
@@ -164,8 +164,8 @@ error message.
 -->
 这一设置会告诉 kubelet 使用所指的 RuntimeClass 来运行该 pod。
 如果所指的 RuntimeClass 不存在或者 CRI 无法运行相应的 handler，
-那么 pod 将会进入 `Failed` 终止[阶段](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。
-你可以查看相应的[事件](/zh/docs/tasks/debug/debug-application/debug-running-pod/)，
+那么 pod 将会进入 `Failed` 终止[阶段](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。
+你可以查看相应的[事件](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/)，
 获取执行过程中的错误信息。

 <!--
@@ -182,7 +182,7 @@ For more details on setting up CRI runtimes, see [CRI installation](/docs/setup/
 ### CRI 配置   {#cri-configuration}

 关于如何安装 CRI 运行时，请查阅
-[CRI 安装](/zh/docs/setup/production-environment/container-runtimes/)。
+[CRI 安装](/zh-cn/docs/setup/production-environment/container-runtimes/)。

 #### {{< glossary_tooltip term_id="containerd" >}}

@@ -267,7 +267,7 @@ To learn more about configuring the node selector and tolerations, see
 [Assigning Pods to Nodes](/docs/concepts/configuration/assign-pod-node/).
 -->
 更多有关 node selector 和 tolerations 的配置信息，请查阅 
-[将 Pod 分派到节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)。
+[将 Pod 分派到节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)。

 <!-- 
 ### Pod Overhead
@@ -300,5 +300,5 @@ Pod 开销通过 RuntimeClass 的 `overhead` 字段定义。
 -->
 - [RuntimeClass 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
 - [RuntimeClass 调度设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
- 阅读关于 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) 的概念
+- 阅读关于 [Pod 开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/) 的概念
 - [PodOverhead 特性设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)