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

content/zh-cn/docs/concepts/extend-kubernetes/_index.md

@@ -79,11 +79,11 @@ Customization approaches can be broadly divided into *configuration*, which only
 
 配置文件和参数标志的说明位于在线文档的参考章节，按可执行文件组织：
 
-* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
-* [kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/)
-* [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
-* [kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
-* [kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/).
+* [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/)
+* [kube-proxy](/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/)
+* [kube-apiserver](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)
+* [kube-controller-manager](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/)
+* [kube-scheduler](/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/).
 
 <!--
 Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.
@@ -97,16 +97,16 @@ Flags and configuration files may not always be changeable in a hosted Kubernete
 <!--
 *Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
 -->
-*内置的策略 API*，例如[ResourceQuota](/zh/docs/concepts/policy/resource-quotas/)、
-[PodSecurityPolicies](/zh/docs/concepts/security/pod-security-policy/)、
-[NetworkPolicy](/zh/docs/concepts/services-networking/network-policies/)
-和基于角色的访问控制（[RBAC](/zh/docs/reference/access-authn-authz/rbac/)）
+*内置的策略 API*，例如[ResourceQuota](/zh-cn/docs/concepts/policy/resource-quotas/)、
+[PodSecurityPolicies](/zh-cn/docs/concepts/security/pod-security-policy/)、
+[NetworkPolicy](/zh-cn/docs/concepts/services-networking/network-policies/)
+和基于角色的访问控制（[RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)）
 等等都是内置的 Kubernetes API。
 API 通常用于托管的 Kubernetes 服务和受控的 Kubernetes 安装环境中。
 这些 API 是声明式的，与 Pod 这类其他 Kubernetes 资源遵从相同的约定，
 所以新的集群配置是可复用的，并且可以当作应用程序来管理。
 此外，对于稳定版本的 API 而言，它们与其他 Kubernetes API 一样，
-采纳的是一种[预定义的支持策略](/zh/docs/reference/using-api/deprecation-policy/)。
+采纳的是一种[预定义的支持策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。
 出于以上原因，在条件允许的情况下，基于 API 的方案应该优先于配置文件和参数标志。
 
 <!--
@@ -178,8 +178,8 @@ Kubernetes control plane.
 在 Webhook 模式中，Kubernetes 向远程服务发起网络请求。
 在 **可执行文件插件（Binary Plugin）** 模式中，Kubernetes
 执行某个可执行文件（程序）。可执行文件插件在 kubelet （例如，
-[FlexVolume 插件](/zh/docs/concepts/storage/volumes/#flexvolume))
-和[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)）
+[FlexVolume 插件](/zh-cn/docs/concepts/storage/volumes/#flexvolume))
+和[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)）
 和 kubectl 中使用。
 
 下面的示意图中展示了这些扩展点如何与 Kubernetes 控制面交互。
@@ -217,7 +217,7 @@ This diagram shows the extension points in a Kubernetes system.
 If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.
 -->
 1. 用户通常使用 `kubectl` 与 Kubernetes API 交互。
-   [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/)能够扩展 kubectl 程序的行为。
+   [kubectl 插件](/zh-cn/docs/tasks/extend-kubectl/kubectl-plugins/)能够扩展 kubectl 程序的行为。
    这些插件只会影响到每个用户的本地环境，因此无法用来强制实施整个站点范围的策略。
 
 2. API 服务器处理所有请求。API 服务器中的几种扩展点能够使用户对请求执行身份认证、
@@ -273,7 +273,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/
 
 不要使用自定义资源来充当应用、用户或者监控数据的数据存储。
 
-关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
+关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
 
 <!--
 ### Combining New APIs with Automation
@@ -283,7 +283,7 @@ The combination of a custom resource API and a control loop is called the [Opera
 ### 结合使用新 API 与自动化组件 {#combinding-new-apis-with-automation}
 
 自定义资源 API 与控制回路的组合称作
-[Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/)。
+[Operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/)。
 Operator 模式用来管理特定的、通常是有状态的应用。
 这些自定义 API 和控制回路也可用来控制其他资源，如存储或策略。
 
@@ -313,14 +313,14 @@ Kubernetes has several built-in authentication methods that it supports. It can
 
 当请求到达 Kubernetes API 服务器时，首先要经过身份认证，之后是鉴权操作，
 再之后要经过若干类型的准入控制器的检查。
-参见[控制 Kubernetes API 访问](/zh/docs/concepts/security/controlling-access/)
+参见[控制 Kubernetes API 访问](/zh-cn/docs/concepts/security/controlling-access/)
 以了解此流程的细节。
 
 这些步骤中都存在扩展点。
 
 Kubernetes 提供若干内置的身份认证方法。它也可以运行在某种身份认证代理的后面，
 并且可以将来自鉴权头部的令牌发送到某个远程服务（Webhook）来执行验证操作。
-所有这些方法都在[身份认证文档](/zh/docs/reference/access-authn-authz/authentication/)
+所有这些方法都在[身份认证文档](/zh-cn/docs/reference/access-authn-authz/authentication/)
 中有详细论述。
 
 <!--
@@ -332,11 +332,11 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
 -->
 ### 身份认证    {#authentication}
 
-[身份认证](/zh/docs/reference/access-authn-authz/authentication/)负责将所有请求中
+[身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/)负责将所有请求中
 的头部或证书映射到发出该请求的客户端的用户名。
 
 Kubernetes 提供若干种内置的认证方法，以及
-[认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
+[认证 Webhook](/zh-cn/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
 方法以备内置方法无法满足你的要求。
 
 <!--
@@ -346,12 +346,12 @@ Kubernetes 提供若干种内置的认证方法，以及
 -->
 ### 鉴权    {#authorization}
 
-[鉴权](/zh/docs/reference/access-authn-authz/authorization/)
+[鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/)
 操作负责确定特定的用户是否可以读、写 API 资源或对其执行其他操作。
 此操作仅在整个资源集合的层面进行。
 换言之，它不会基于对象的特定字段作出不同的判决。
 如果内置的鉴权选项无法满足你的需要，你可以使用
-[鉴权 Webhook](/zh/docs/reference/access-authn-authz/webhook/)来调用用户提供
+[鉴权 Webhook](/zh-cn/docs/reference/access-authn-authz/webhook/)来调用用户提供
 的代码，执行定制的鉴权操作。
 
 <!--
@@ -365,13 +365,13 @@ After a request is authorized, if it is a write operation, it also goes through
 ### 动态准入控制  {#dynamic-admission-control}
 
 请求的鉴权操作结束之后，如果请求的是写操作，还会经过
-[准入控制](/zh/docs/reference/access-authn-authz/admission-controllers/)处理步骤。
+[准入控制](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)处理步骤。
 除了内置的处理步骤，还存在一些扩展点：
 
-* [镜像策略 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)
+* [镜像策略 Webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)
   能够限制容器中可以运行哪些镜像。
 * 为了执行任意的准入控制，可以使用一种通用的
-  [准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) 
+  [准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) 
   机制。这类 Webhook 可以拒绝对象创建或更新请求。
 
 <!--
@@ -412,12 +412,12 @@ Different networking fabrics can be supported via node-level [Network Plugins](/
 -->
 ### 设备插件    {#device-plugins}
 
-使用[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)，
+使用[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)，
 节点能够发现新的节点资源（除了内置的类似 CPU 和内存这类资源）。
 
 ### 网络插件   {#network-plugins}
 
-通过节点层面的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)，
+通过节点层面的[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)，
 可以支持不同的网络设施。
 
 <!--
@@ -442,7 +442,7 @@ the nodes chosen for a pod.
 调度器是一种特殊的控制器，负责监视 Pod 变化并将 Pod 分派给节点。
 默认的调度器可以被整体替换掉，同时继续使用其他 Kubernetes 组件。
 或者也可以在同一时刻使用
-[多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)。
+[多个调度器](/zh-cn/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)。
 
 这是一项非同小可的任务，几乎绝大多数 Kubernetes
 用户都会发现其实他们不需要修改调度器。
@@ -462,11 +462,11 @@ the nodes chosen for a pod.
 * Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
 * Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
 -->
-* 进一步了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
-* 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
+* 进一步了解[自定义资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* 了解[动态准入控制](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/)
 * 进一步了解基础设施扩展
-  * [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
-  * [设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
-* 了解 [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/)
-* 了解 [Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/)
+  * [网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+  * [设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
+* 了解 [kubectl 插件](/zh-cn/docs/tasks/extend-kubectl/kubectl-plugins/)
+* 了解 [Operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/)
 

content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md

@@ -32,7 +32,7 @@ The aggregation layer is different from [Custom Resources](/docs/concepts/extend
 或者你自己开发的 API。
 
 聚合层不同于
-[定制资源（Custom Resources）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
+[定制资源（Custom Resources）](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
 后者的目的是让 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
 能够认识新的对象类别（Kind）。
 
@@ -83,10 +83,10 @@ If your extension API server cannot achieve that latency requirement, consider m
 
 Alternatively: learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
 -->
-* 阅读[配置聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 文档，
+* 阅读[配置聚合层](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 文档，
   了解如何在自己的环境中启用聚合器。
-* 接下来，了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)，
+* 接下来，了解[安装扩展 API 服务器](/zh-cn/docs/tasks/extend-kubernetes/setup-extension-api-server/)，
   开始使用聚合层。
 * 从 API 参考资料中研究关于 [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/) 的内容。
 
-或者，学习如何[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
+或者，学习如何[使用自定义资源定义扩展 Kubernetes API](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。

content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md

@@ -37,9 +37,9 @@ collection of Pod objects.
 ## 定制资源
 
 *资源（Resource）* 是
-[Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) 中的一个端点，
+[Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/) 中的一个端点，
 其中存储的是某个类别的
-[API 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+[API 对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/)
 的一个集合。
 例如内置的 *pods* 资源包含一组 Pod 对象。
 
@@ -84,7 +84,7 @@ keep the current state of Kubernetes objects in sync with the desired state.
 The controller interprets the structured data as a record of the user's
 desired state, and continually maintains this state.
 -->
-使用[声明式 API](/zh/docs/concepts/overview/kubernetes-api/)，
+使用[声明式 API](/zh-cn/docs/concepts/overview/kubernetes-api/)，
 你可以 _声明_ 或者设定你的资源的期望状态，并尝试让 Kubernetes 对象的当前状态
 同步到其期望状态。控制器负责将结构化的数据解释为用户所期望状态的记录，并
 持续地维护该状态。
@@ -99,7 +99,7 @@ for specific applications into an extension of the Kubernetes API.
 -->
 你可以在一个运行中的集群上部署和更新定制控制器，这类操作与集群的生命周期无关。
 定制控制器可以用于任何类别的资源，不过它们与定制资源结合起来时最为有效。
-[Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/)就是将定制资源
+[Operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/)就是将定制资源
 与定制控制器相结合的。你可以使用定制控制器来将特定于某应用的领域知识组织
 起来，以编码的形式构造对 Kubernetes API 的扩展。
 
@@ -113,7 +113,7 @@ or let your API stand alone.
 ## 我是否应该向我的 Kubernetes 集群添加定制资源？
 
 在创建新的 API 时，请考虑是
-[将你的 API 与 Kubernetes 集群 API 聚合起来](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+[将你的 API 与 Kubernetes 集群 API 聚合起来](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
 还是让你的 API 独立运行。
 
 <!--
@@ -133,7 +133,7 @@ or let your API stand alone.
 | 你希望可以是使用 `kubectl` 来读写你的新资源类别。 | 不要求 `kubectl` 支持。 |
 | 你希望在 Kubernetes UI （如仪表板）中和其他内置类别一起查看你的新资源类别。 | 不需要 Kubernetes UI 支持。 |
 | 你在开发新的 API。 | 你已经有一个提供 API 服务的程序并且工作良好。 |
-| 你有意愿取接受 Kubernetes 对 REST 资源路径所作的格式限制，例如 API 组和名字空间。（参阅 [API 概述](/zh/docs/concepts/overview/kubernetes-api/)） | 你需要使用一些特殊的 REST 路径以便与已经定义的 REST API 保持兼容。 |
+| 你有意愿取接受 Kubernetes 对 REST 资源路径所作的格式限制，例如 API 组和名字空间。（参阅 [API 概述](/zh-cn/docs/concepts/overview/kubernetes-api/)） | 你需要使用一些特殊的 REST 路径以便与已经定义的 REST API 保持兼容。 |
 | 你的资源可以自然地界定为集群作用域或集群中某个名字空间作用域。 | 集群作用域或名字空间作用域这种二分法很不合适；你需要对资源路径的细节进行控制。 |
 | 你希望复用 [Kubernetes API 支持特性](#common-features)。  | 你不需要这类特性。 |
 
@@ -214,7 +214,7 @@ Use a ConfigMap if any of the following apply:
 Use a [secret](/docs/concepts/configuration/secret/) for sensitive data, which is similar to a configMap but more secure.
 -->
 {{< note >}}
-请使用 [Secret](/zh/docs/concepts/configuration/secret/) 来保存敏感数据。
+请使用 [Secret](/zh-cn/docs/concepts/configuration/secret/) 来保存敏感数据。
 Secret 类似于 configMap，但更为安全。
 {{< /note >}}
 
@@ -251,7 +251,7 @@ Kubernetes provides two ways to add custom resources to your cluster:
 Kubernetes 提供了两种方式供你向集群中添加定制资源：
 
 - CRD 相对简单，创建 CRD 可以不必编程。
-- [API 聚合](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+- [API 聚合](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
   需要编程，但支持对 API 行为进行更多的控制，例如数据如何存储以及在不同 API 版本间如何转换等。
 
 <!--
@@ -267,7 +267,7 @@ Kubernetes 提供这两种选项以满足不同用户的需求，这样就既不
 
 聚合 API 指的是一些下位的 API 服务器，运行在主 API 服务器后面；主 API
 服务器以代理的方式工作。这种组织形式称作
-[API 聚合（API Aggregation，AA）](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 。
+[API 聚合（API Aggregation，AA）](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 。
 对用户而言，看起来仅仅是 Kubernetes API 被扩展了。
 
 CRD 允许用户创建新的资源类别同时又不必添加新的 API 服务器。
@@ -288,12 +288,12 @@ The name of a CRD object must be a valid
 -->
 ## CustomResourceDefinitions
 
-[CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
+[CustomResourceDefinition](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
 API 资源允许你定义定制资源。
 定义 CRD 对象的操作会使用你所设定的名字和模式定义（Schema）创建一个新的定制资源，
 Kubernetes API 负责为你的定制资源提供存储和访问服务。
 CRD 对象的名称必须是合法的
-[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)。
 
 <!--
 This frees you from writing your own API server to handle the custom resource,
@@ -327,7 +327,7 @@ making them available to all of its clients.
 Kubernetes API 主服务器能够处理诸如 *pods* 和 *services* 这些内置资源，也可以
 按通用的方式通过 [CRD](#customresourcedefinitions) 来处理定制资源。
 
-[聚合层（Aggregation Layer）](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+[聚合层（Aggregation Layer）](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
 使得你可以通过编写和部署你自己的 API 服务器来为定制资源提供特殊的实现。
 主 API 服务器将针对你要处理的定制资源的请求全部委托给你自己的 API 服务器来处理，同时将这些资源
 提供给其所有客户端。
@@ -402,17 +402,17 @@ Aggregated APIs offer more advanced API features and customization of other feat
 -->
 | 特性    | 描述        | CRDs | 聚合 API       |
 | ------- | ----------- | ---- | -------------- |
-| 合法性检查 | 帮助用户避免错误，允许你独立于客户端版本演化 API。这些特性对于由很多无法同时更新的客户端的场合。| 可以。大多数验证可以使用 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 来设定。其他合法性检查操作可以通过添加[合法性检查 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)来实现。 | 可以，可执行任何合法性检查。|
-| 默认值设置 | 同上 | 可以。可通过 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)的 `default` 关键词（自 1.17 正式发布）或[更改性（Mutating）Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)来实现（不过从 etcd 中读取老的对象时不会执行这些 Webhook）。 | 可以。 |
-| 多版本支持 | 允许通过两个 API 版本同时提供同一对象。可帮助简化类似字段更名这类 API 操作。如果你能控制客户端版本，这一特性将不再重要。 | [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning)。 | 可以。 |
+| 合法性检查 | 帮助用户避免错误，允许你独立于客户端版本演化 API。这些特性对于由很多无法同时更新的客户端的场合。| 可以。大多数验证可以使用 [OpenAPI v3.0 合法性检查](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 来设定。其他合法性检查操作可以通过添加[合法性检查 Webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)来实现。 | 可以，可执行任何合法性检查。|
+| 默认值设置 | 同上 | 可以。可通过 [OpenAPI v3.0 合法性检查](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)的 `default` 关键词（自 1.17 正式发布）或[更改性（Mutating）Webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)来实现（不过从 etcd 中读取老的对象时不会执行这些 Webhook）。 | 可以。 |
+| 多版本支持 | 允许通过两个 API 版本同时提供同一对象。可帮助简化类似字段更名这类 API 操作。如果你能控制客户端版本，这一特性将不再重要。 | [可以](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning)。 | 可以。 |
 | 定制存储 | 支持使用具有不同性能模式的存储（例如，要使用时间序列数据库而不是键值存储），或者因安全性原因对存储进行隔离（例如对敏感信息执行加密）。 | 不可以。 | 可以。 |
-| 定制业务逻辑 | 在创建、读取、更新或删除对象时，执行任意的检查或操作。 | 可以。要使用 [Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 | 可以。 |
-| 支持 scale 子资源 | 允许 HorizontalPodAutoscaler 和 PodDisruptionBudget 这类子系统与你的新资源交互。 | [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)。 | 可以。 |
-| 支持 status 子资源 | 允许在用户写入 spec 部分而控制器写入 status 部分时执行细粒度的访问控制。允许在对定制资源的数据进行更改时增加对象的代际（Generation）；这需要资源对 spec 和 status 部分有明确划分。| [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource)。 | 可以。 |
+| 定制业务逻辑 | 在创建、读取、更新或删除对象时，执行任意的检查或操作。 | 可以。要使用 [Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 | 可以。 |
+| 支持 scale 子资源 | 允许 HorizontalPodAutoscaler 和 PodDisruptionBudget 这类子系统与你的新资源交互。 | [可以](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)。 | 可以。 |
+| 支持 status 子资源 | 允许在用户写入 spec 部分而控制器写入 status 部分时执行细粒度的访问控制。允许在对定制资源的数据进行更改时增加对象的代际（Generation）；这需要资源对 spec 和 status 部分有明确划分。| [可以](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource)。 | 可以。 |
 | 其他子资源 | 添加 CRUD 之外的操作，例如 "logs" 或 "exec"。 | 不可以。 | 可以。 |
-| strategic-merge-patch | 新的端点要支持标记了 `Content-Type: application/strategic-merge-patch+json` 的 PATCH 操作。对于更新既可在本地更改也可在服务器端更改的对象而言是有用的。要了解更多信息，可参见[使用 `kubectl patch` 来更新 API 对象](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 | 不可以。 | 可以。 |
+| strategic-merge-patch | 新的端点要支持标记了 `Content-Type: application/strategic-merge-patch+json` 的 PATCH 操作。对于更新既可在本地更改也可在服务器端更改的对象而言是有用的。要了解更多信息，可参见[使用 `kubectl patch` 来更新 API 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 | 不可以。 | 可以。 |
 | 支持协议缓冲区 | 新的资源要支持想要使用协议缓冲区（Protocol Buffer）的客户端。 | 不可以。 | 可以。 |
-| OpenAPI Schema | 是否存在新资源类别的 OpenAPI（Swagger）Schema 可供动态从服务器上读取？是否存在机制确保只能设置被允许的字段以避免用户犯字段拼写错误？是否实施了字段类型检查（换言之，不允许在 `string` 字段设置 `int` 值）？ | 可以，依据 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 模式（1.16 中进入正式发布状态）。 | 可以。|
+| OpenAPI Schema | 是否存在新资源类别的 OpenAPI（Swagger）Schema 可供动态从服务器上读取？是否存在机制确保只能设置被允许的字段以避免用户犯字段拼写错误？是否实施了字段类型检查（换言之，不允许在 `string` 字段设置 `int` 值）？ | 可以，依据 [OpenAPI v3.0 合法性检查](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 模式（1.16 中进入正式发布状态）。 | 可以。|
 
 <!--
 ### Common Features
@@ -535,7 +535,7 @@ When you add a custom resource, you can access it using:
 -->
 ## 访问定制资源
 
-Kubernetes [客户端库](/zh/docs/reference/using-api/client-libraries/)可用来访问定制资源。
+Kubernetes [客户端库](/zh-cn/docs/reference/using-api/client-libraries/)可用来访问定制资源。
 并非所有客户端库都支持定制资源。_Go_ 和 _Python_ 客户端库是支持的。
 
 当你添加了新的定制资源后，可以用如下方式之一访问它们：
@@ -553,6 +553,6 @@ Kubernetes [客户端库](/zh/docs/reference/using-api/client-libraries/)可用
 * Learn how to [Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
 * Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
 -->
-* 了解如何[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
-* 了解如何[使用 CustomResourceDefinition 来扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
+* 了解如何[使用聚合层扩展 Kubernetes API](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+* 了解如何[使用 CustomResourceDefinition 来扩展 Kubernetes API](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
 

content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md

@@ -67,7 +67,7 @@ to advertise that the node has 2 "Foo" devices installed and available.
 * 设备插件的 Unix 套接字。
 * 设备插件的 API 版本。
 * `ResourceName` 是需要公布的。这里 `ResourceName` 需要遵循
-  [扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources)，
+  [扩展资源命名方案](/zh-cn/docs/concepts/configuration/manage-resources-containers/#extended-resources)，
   类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。）
 
 成功注册后，设备插件就向 kubelet 发送它所管理的设备列表，然后 kubelet
@@ -86,7 +86,7 @@ other resources, with the following differences:
 * Devices cannot be shared between containers.
 -->
 然后，用户可以请求设备作为 Pod 规范的一部分，
-参见[Container](/zh/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)。
+参见[Container](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)。
 请求扩展资源类似于管理请求和限制的方式，
 其他资源，有以下区别：
 
@@ -441,7 +441,7 @@ it does (for example: hotplug/hotunplug, device health changes), client is expec
 However, calling `GetAllocatableResources` endpoint is not sufficient in case of cpu and/or memory
 update and Kubelet needs to be restarted to reflect the correct resource capacity and allocatable.
 -->
-`GetAllocatableResources` 应该仅被用于评估一个节点上的[可分配的](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
+`GetAllocatableResources` 应该仅被用于评估一个节点上的[可分配的](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
 资源。如果目标是评估空闲/未分配的资源，此调用应该与 List() 端点一起使用。
 除非暴露给 kubelet 的底层资源发生变化 否则 `GetAllocatableResources` 得到的结果将保持不变。
 这种情况很少发生，但当发生时（例如：热插拔，设备健康状况改变），客户端应该调用 `GetAlloctableResources` 端点。
@@ -471,7 +471,7 @@ Preceding Kubernetes v1.23, to enable this feature `kubelet` must be started wit
 -->
 从 Kubernetes v1.23 开始，`GetAllocatableResources` 被默认启用。
 你可以通过关闭 `KubeletPodResourcesGetAllocatable`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 来禁用。
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 来禁用。
 
 在 Kubernetes v1.23 之前，要启用这一功能，`kubelet` 必须用以下标志启动：
 
@@ -484,7 +484,7 @@ plugins report [when they register themselves to the kubelet](/docs/concepts/ext
 -->
 `ContainerDevices` 会向外提供各个设备所隶属的 NUMA 单元这类拓扑信息。
 NUMA 单元通过一个整数 ID 来标识，其取值与设备插件所报告的一致。
-[设备插件注册到 kubelet 时](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
+[设备插件注册到 kubelet 时](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
 会报告这类信息。
 
 <!--
@@ -509,7 +509,7 @@ gRPC 服务通过 `/var/lib/kubelet/pod-resources/kubelet.sock` 的 UNIX 套接
 {{< glossary_tooltip text="卷" term_id="volume" >}}的形式被挂载到设备监控代理中。
 
 对“PodResourcesLister 服务”的支持要求启用 `KubeletPodResources`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
 从 Kubernetes 1.15 开始默认启用，自从 Kubernetes 1.20 开始为 v1。
 
 <!--
@@ -596,7 +596,7 @@ Here are some examples of device plugin implementations:
 * Learn about the [Topology Manager](/docs/tasks/administer-cluster/topology-manager/)
 * Read about using [hardware acceleration for TLS ingress](/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
 -->
-* 查看[调度 GPU 资源](/zh/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件
-* 查看在上如何[公布节点上的扩展资源](/zh/docs/tasks/administer-cluster/extended-resource-node/)
-* 学习[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/)
-* 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](/zh/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/)
+* 查看[调度 GPU 资源](/zh-cn/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件
+* 查看在上如何[公布节点上的扩展资源](/zh-cn/docs/tasks/administer-cluster/extended-resource-node/)
+* 学习[拓扑管理器](/zh-cn/docs/tasks/administer-cluster/topology-manager/)
+* 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](/zh-cn/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/)

content/zh-cn/docs/concepts/extend-kubernetes/operator.md

@@ -19,9 +19,9 @@ to manage applications and their components. Operators follow
 Kubernetes principles, notably the [control loop](/docs/concepts/architecture/controller/).
 -->
 Operator 是 Kubernetes 的扩展软件，它利用
-[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+[定制资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 管理应用及其组件。
-Operator 遵循 Kubernetes 的理念，特别是在[控制器](/zh/docs/concepts/architecture/controller/)
+Operator 遵循 Kubernetes 的理念，特别是在[控制器](/zh-cn/docs/concepts/architecture/controller/)
 方面。
 
 <!-- body -->
@@ -67,7 +67,7 @@ Kubernetes 的 {{< glossary_tooltip text="Operator 模式" term_id="operator-pat
 Kubernetes 自身代码的情况下，通过为一个或多个自定义资源关联{{< glossary_tooltip text="控制器" term_id="controller" >}}
 来扩展集群的能力。
 Operator 是 Kubernetes API 的客户端，充当
-[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+[自定义资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 的控制器。
 
 <!--
@@ -202,7 +202,7 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
 
 如果生态系统中没可以实现你目标的 Operator，你可以自己编写代码。
 
-你还可以使用任何支持 [Kubernetes API 客户端](/zh/docs/reference/using-api/client-libraries/)
+你还可以使用任何支持 [Kubernetes API 客户端](/zh-cn/docs/reference/using-api/client-libraries/)
 的语言或运行时来实现 Operator（即控制器）。
 
 <!--
@@ -248,7 +248,7 @@ you implement yourself
 -->
 
 * 阅读 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} [Operator 白皮书](https://github.com/cncf/tag-app-delivery/blob/eece8f7307f2970f46f100f51932db106db46968/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md)。
-* 详细了解 [定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* 详细了解 [定制资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 * 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合你的 Operator
 * [发布](https://operatorhub.io/)你的 Operator，让别人也可以使用
 * 阅读 [CoreOS 原始文章](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html)，它介绍了 Operator 模式（这是一个存档版本的原始文章）。

content/zh-cn/docs/concepts/extend-kubernetes/service-catalog.md

@@ -66,7 +66,7 @@ It is implemented using a [CRDs-based](/docs/concepts/extend-kubernetes/api-exte
 与服务代理进行通信，并作为 Kubernetes API 服务器的中介，以便协商启动部署和获取
 应用程序使用托管服务时必须的凭据。
 
-它是[基于 CRDs](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources)
+它是[基于 CRDs](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources)
 架构实现的。
 
 ![服务目录架构](/images/docs/service-catalog-architecture.svg)
@@ -436,9 +436,9 @@ The following example describes how to map secret values into application enviro
 * Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project.
 -->
 * 如果你熟悉 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}，
-  可以[使用 Helm 安装服务目录](/zh/docs/tasks/service-catalog/install-service-catalog-using-helm/)
+  可以[使用 Helm 安装服务目录](/zh-cn/docs/tasks/service-catalog/install-service-catalog-using-helm/)
   到 Kubernetes 集群中。或者，你可以
-  [使用 SC 工具安装服务目录](/zh/docs/tasks/service-catalog/install-service-catalog-using-sc/)。
+  [使用 SC 工具安装服务目录](/zh-cn/docs/tasks/service-catalog/install-service-catalog-using-sc/)。
 * 查看[服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)
 * 浏览 [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 项目
 

content/zh-cn/docs/concepts/overview/components.md

@@ -63,7 +63,7 @@ for an example control plane setup that runs across multiple machines.
 控制平面组件可以在集群中的任何节点上运行。
 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件，
 并且不会在此计算机上运行用户容器。
-请参阅[使用 kubeadm 构建高可用性集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)
+请参阅[使用 kubeadm 构建高可用性集群](/zh-cn/docs/setup/production-environment/tools/kubeadm/high-availability/)
 中关于跨多机器控制平面设置的示例。
 
 ### kube-apiserver
@@ -177,7 +177,7 @@ Selected addons are described below; for an extended list of available addons, p
 see [Addons](/docs/concepts/cluster-administration/addons/).
 -->
 下面描述众多插件中的几种。有关可用插件的完整列表，请参见
-[插件（Addons）](/zh/docs/concepts/cluster-administration/addons/)。
+[插件（Addons）](/zh-cn/docs/concepts/cluster-administration/addons/)。
 
 <!--
 ### DNS
@@ -191,7 +191,7 @@ Containers started by Kubernetes automatically include this DNS server in their
 ### DNS   {#dns}
 
 尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该
-有[集群 DNS](/zh/docs/concepts/services-networking/dns-pod-service/)，
+有[集群 DNS](/zh-cn/docs/concepts/services-networking/dns-pod-service/)，
 因为很多示例都需要 DNS 服务。
 
 集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。
@@ -205,7 +205,7 @@ Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列
 -->
 ### Web 界面（仪表盘）   {#web-ui-dashboard}
 
-[Dashboard](/zh/docs/tasks/access-application-cluster/web-ui-dashboard/)
+[Dashboard](/zh-cn/docs/tasks/access-application-cluster/web-ui-dashboard/)
 是 Kubernetes 集群的通用的、基于 Web 的用户界面。
 它使用户可以管理集群中运行的应用程序以及集群本身，
 并进行故障排除。
@@ -218,7 +218,7 @@ about containers in a central database, and provides a UI for browsing that data
 -->
 ### 容器资源监控   {#container-resource-monitoring}
 
-[容器资源监控](/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
+[容器资源监控](/zh-cn/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，
 并提供浏览这些数据的界面。
 
@@ -230,7 +230,7 @@ saving container logs to a central log store with search/browsing interface.
 -->
 ### 集群层面日志   {#cluster-level-logging}
 
-[集群层面日志](/zh/docs/concepts/cluster-administration/logging/) 
+[集群层面日志](/zh-cn/docs/concepts/cluster-administration/logging/) 
 机制负责将容器的日志数据保存到一个集中的日志存储中，
 这种集中日志存储提供搜索和浏览接口。
 
@@ -242,7 +242,7 @@ saving container logs to a central log store with search/browsing interface.
 * Learn about [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/)
 * Read etcd's official [documentation](https://etcd.io/docs/)
 -->
-* 进一步了解[节点](/zh/docs/concepts/architecture/nodes/)
-* 进一步了解[控制器](/zh/docs/concepts/architecture/controller/)
-* 进一步了解 [kube-scheduler](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)
+* 进一步了解[节点](/zh-cn/docs/concepts/architecture/nodes/)
+* 进一步了解[控制器](/zh-cn/docs/concepts/architecture/controller/)
+* 进一步了解 [kube-scheduler](/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/)
 * 阅读 etcd 官方[文档](https://etcd.io/docs/)

content/zh-cn/docs/concepts/overview/kubernetes-api.md

@@ -35,8 +35,8 @@ API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和
 Kubernetes API 使你可以查询和操纵 Kubernetes API
 中对象（例如：Pod、Namespace、ConfigMap 和 Event）的状态。
 
-大部分操作都可以通过 [kubectl](/zh/docs/reference/kubectl/) 命令行接口或
-类似 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 这类命令行工具来执行，
+大部分操作都可以通过 [kubectl](/zh-cn/docs/reference/kubectl/) 命令行接口或
+类似 [kubeadm](/zh-cn/docs/reference/setup-tools/kubeadm/) 这类命令行工具来执行，
 这些工具在背后也是调用 API。不过，你也可以使用 REST 调用来访问这些 API。
 
 <!--
@@ -44,7 +44,7 @@ Consider using one of the [client libraries](/docs/reference/using-api/client-li
 if you are writing an application using the Kubernetes API.
 -->
 如果你正在编写程序来访问 Kubernetes API，可以考虑使用
-[客户端库](/zh/docs/reference/using-api/client-libraries/)之一。
+[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)之一。
 
 <!-- body -->
 
@@ -157,7 +157,7 @@ for the kube-apiserver component.
 Kubernetes {{< param "version" >}} 提供将其 API 以 OpenAPI v3 形式发布的 beta 支持；
 这一功能特性处于 beta 状态，默认被开启。
 你可以通过为 kube-apiserver 组件关闭 `OpenAPIV3`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)来禁用此 beta 特性。
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)来禁用此 beta 特性。
 
 <!--
 A discovery endpoint `/openapi/v3` is provided to see a list of all
@@ -257,7 +257,7 @@ Elimination of resources or fields requires following the
 -->
 一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。
 删除资源或者字段则要遵从
-[API 废弃策略](/zh/docs/reference/using-api/deprecation-policy/)。
+[API 废弃策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。
 
 <!--
 Kubernetes makes a strong commitment to maintain compatibility for official Kubernetes APIs
@@ -287,7 +287,7 @@ Refer to [API versions reference](/docs/reference/using-api/#api-versioning)
 for more details on the API version level definitions.
 -->
 关于 API 版本分级的定义细节，请参阅
-[API 版本参考](/zh/docs/reference/using-api/#api-versioning)页面。
+[API 版本参考](/zh-cn/docs/reference/using-api/#api-versioning)页面。
 
 <!--
 ## API Extension
@@ -304,10 +304,10 @@ The Kubernetes API can be extended in one of two ways:
 1. You can also extend the Kubernetes API by implementing an
    [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
 -->
-1. 你可以使用[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+1. 你可以使用[自定义资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
    来以声明式方式定义 API 服务器如何提供你所选择的资源 API。 
 1. 你也可以选择实现自己的
-   [聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+   [聚合层](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
    来扩展 Kubernetes API。
 
 ## {{% heading "whatsnext" %}}
@@ -323,11 +323,11 @@ The Kubernetes API can be extended in one of two ways:
   [API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme).
 -->
 - 了解如何通过添加你自己的
-  [CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
+  [CustomResourceDefinition](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
   来扩展 Kubernetes API。
-- [控制 Kubernetes API 访问](/zh/docs/concepts/security/controlling-access/)页面描述了集群如何针对
+- [控制 Kubernetes API 访问](/zh-cn/docs/concepts/security/controlling-access/)页面描述了集群如何针对
   API 访问管理身份认证和鉴权。
-- 通过阅读 [API 参考](/zh/docs/reference/kubernetes-api/)了解 API 端点、资源类型以及示例。
+- 通过阅读 [API 参考](/zh-cn/docs/reference/kubernetes-api/)了解 API 端点、资源类型以及示例。
 - 阅读 [API 变更（英文）](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)
   以了解什么是兼容性的变更以及如何变更 API。
 

content/zh-cn/docs/concepts/overview/what-is-kubernetes.md

@@ -273,5 +273,5 @@ Kubernetes：
 *   Take a look at the [Kubernetes Components](/docs/concepts/overview/components/)
 *   Ready to [Get Started](/docs/setup/)?
 -->
-* 查阅[Kubernetes 组件](/zh/docs/concepts/overview/components/)
-* 开始[Kubernetes 的建置](/zh/docs/setup/)吧！
+* 查阅[Kubernetes 组件](/zh-cn/docs/concepts/overview/components/)
+* 开始[Kubernetes 的建置](/zh-cn/docs/setup/)吧！

content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md

@@ -163,5 +163,5 @@ spec:
 <!--
 * Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/).
 -->
-* 进一步了解[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。
+* 进一步了解[标签和选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。
 

content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md

@@ -11,7 +11,7 @@ weight: 60
 _Field selectors_ let you [select Kubernetes resources](/docs/concepts/overview/working-with-objects/kubernetes-objects) based on the value of one or more resource fields. Here are some example field selector queries:
 -->
 “字段选择器（Field selectors）”允许你根据一个或多个资源字段的值
-[筛选 Kubernetes 资源](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects)。
+[筛选 Kubernetes 资源](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects)。
 下面是一些使用字段选择器查询的例子：
 
 * `metadata.name=my-service`
@@ -21,7 +21,7 @@ _Field selectors_ let you [select Kubernetes resources](/docs/concepts/overview/
 <!--
 This `kubectl` command selects all Pods for which the value of the [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) field is `Running`:
 -->
-下面这个 `kubectl` 命令将筛选出 [`status.phase`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)
+下面这个 `kubectl` 命令将筛选出 [`status.phase`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)
 字段值为 `Running` 的所有 Pod：
 
 ```shell
@@ -81,7 +81,7 @@ As with [label](/docs/concepts/overview/working-with-objects/labels) and other s
 -->
 ## 链式选择器   {#chained-selectors}
 
-同[标签](/zh/docs/concepts/overview/working-with-objects/labels/)和其他选择器一样，
+同[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)和其他选择器一样，
 字段选择器可以通过使用逗号分隔的列表组成一个选择链。
 下面这个 `kubectl` 命令将筛选 `status.phase` 字段不等于 `Running` 同时
 `spec.restartPolicy` 字段等于 `Always` 的所有 Pod：

content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md

@@ -99,7 +99,7 @@ any Pods in the cluster with the same label.
 ## 属主引用、标签和 Finalizers {#owners-labels-finalizers}
 
 与{{<glossary_tooltip text="标签" term_id="label">}}类似，
-[属主引用](/zh/concepts/overview/working-with-objects/owners-dependents/)
+[属主引用](/zh-cn/concepts/overview/working-with-objects/owners-dependents/)
 描述了 Kubernetes 中对象之间的关系，但它们作用不同。
 当一个{{<glossary_tooltip text="控制器" term_id="controller">}}
 管理类似于 Pod 的对象时，它使用标签来跟踪相关对象组的变化。

content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -64,7 +64,7 @@ Kubernetes 对象是“目标性记录”——一旦创建对象，Kubernetes
 这就是 Kubernetes 集群所谓的 **期望状态（Desired State）**。
 
 操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用
-[Kubernetes API](/zh/docs/concepts/overview/kubernetes-api)。
+[Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api)。
 比如，当使用 `kubectl` 命令行接口（CLI）时，CLI 会调用必要的 Kubernetes API；
 也可以在程序中使用[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)，
 来直接调用 Kubernetes API。
@@ -217,7 +217,7 @@ detail the structure of that `.status` field, and its content for each different
 另一个对象规约的例子是 StatefulSet API 中的
 [`spec` 字段](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec)。
 对于 StatefulSet 而言，其 `.spec` 字段设置了 StatefulSet 及其期望状态。
-在 StatefulSet 的 `.spec` 内，有一个为 Pod 对象提供的[模板](/zh/docs/concepts/workloads/pods/#pod-templates)。该模板描述了 StatefulSet 控制器为了满足 StatefulSet 规约而要创建的 Pod。
+在 StatefulSet 的 `.spec` 内，有一个为 Pod 对象提供的[模板](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。该模板描述了 StatefulSet 控制器为了满足 StatefulSet 规约而要创建的 Pod。
 不同类型的对象可以由不同的 `.status` 信息。API 参考页面给出了 `.status` 字段的详细结构，
 以及针对不同类型 API 对象的具体内容。
 
@@ -228,7 +228,7 @@ detail the structure of that `.status` field, and its content for each different
 * Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes.
 * [Using the Kubernetes API](/docs/reference/using-api/) explains some more API concepts.
 -->
-* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh/docs/concepts/workloads/pods/)。
-* 了解 Kubernetes 中的[控制器](/zh/docs/concepts/architecture/controller/)。
-* [使用 Kubernetes API](/zh/docs/reference/using-api/) 一节解释了一些 API 概念。
+* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh-cn/docs/concepts/workloads/pods/)。
+* 了解 Kubernetes 中的[控制器](/zh-cn/docs/concepts/architecture/controller/)。
+* [使用 Kubernetes API](/zh-cn/docs/reference/using-api/) 一节解释了一些 API 概念。
 

content/zh-cn/docs/concepts/overview/working-with-objects/labels.md

@@ -40,7 +40,7 @@ and CLIs. Non-identifying information should be recorded using
 [annotations](/docs/concepts/overview/working-with-objects/annotations/).
 -->
 标签能够支持高效的查询和监听操作，对于用户界面和命令行是很理想的。
-应使用[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)记录非识别信息。
+应使用[注解](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)记录非识别信息。
 
 <!-- body -->
 
@@ -72,7 +72,7 @@ Example labels:
 <!--
 These are examples of [commonly used labels](/docs/concepts/overview/working-with-objects/common-labels/); you are free to develop your own conventions. Keep in mind that label Key must be unique for a given object.
 -->
-有一些[常用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)的例子；你可以任意制定自己的约定。
+有一些[常用标签](/zh-cn/docs/concepts/overview/working-with-objects/common-labels/)的例子；你可以任意制定自己的约定。
 请记住，标签的 Key 对于给定对象必须是唯一的。
 
 <!--
@@ -96,7 +96,7 @@ _标签_ 是键值对。有效的标签键有两个段：可选的前缀和名
 向最终用户对象添加标签的自动系统组件（例如 `kube-scheduler`、`kube-controller-manager`、
 `kube-apiserver`、`kubectl` 或其他第三方自动化工具）必须指定前缀。
 
-`kubernetes.io/` 和 `k8s.io/` 前缀是为 Kubernetes 核心组件[保留的](/zh/docs/reference/labels-annotations-taints/)。
+`kubernetes.io/` 和 `k8s.io/` 前缀是为 Kubernetes 核心组件[保留的](/zh-cn/docs/reference/labels-annotations-taints/)。
 
 <!--
 Valid label value:
@@ -118,7 +118,7 @@ Unlike [names and UIDs](/docs/user-guide/identifiers), labels do not provide uni
 -->
 ## 标签选择算符   {#label-selectors}
 
-与[名称和 UID](/zh/docs/concepts/overview/working-with-objects/names/) 不同，
+与[名称和 UID](/zh-cn/docs/concepts/overview/working-with-objects/names/) 不同，
 标签不支持唯一性。通常，我们希望许多对象携带相同的标签。
 
 <!--
@@ -317,10 +317,10 @@ also use label selectors to specify sets of other resources, such as
 -->
 ### 在 API 对象中设置引用
 
-一些 Kubernetes 对象，例如 [`services`](/zh/docs/concepts/services-networking/service/)
-和 [`replicationcontrollers`](/zh/docs/concepts/workloads/controllers/replicationcontroller/) ，
+一些 Kubernetes 对象，例如 [`services`](/zh-cn/docs/concepts/services-networking/service/)
+和 [`replicationcontrollers`](/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/) ，
 也使用了标签选择算符去指定了其他资源的集合，例如
-[pods](/zh/docs/concepts/workloads/pods/)。
+[pods](/zh-cn/docs/concepts/workloads/pods/)。
 
 <!--
 #### Service and ReplicationController
@@ -363,10 +363,10 @@ Newer resources, such as [`Job`](/docs/concepts/jobs/run-to-completion-finite-wo
 -->
 #### 支持基于集合需求的资源
 
-比较新的资源，例如 [`Job`](/zh/docs/concepts/workloads/controllers/job/)、
-[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/)、
-[`Replica Set`](/zh/docs/concepts/workloads/controllers/replicaset/) 和
-[`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/)，
+比较新的资源，例如 [`Job`](/zh-cn/docs/concepts/workloads/controllers/job/)、
+[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/)、
+[`Replica Set`](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 和
+[`DaemonSet`](/zh-cn/docs/concepts/workloads/controllers/daemonset/)，
 也支持 _基于集合的_ 需求。
 
 ```yaml
@@ -400,5 +400,5 @@ See the documentation on [node selection](/docs/concepts/configuration/assign-po
 #### 选择节点集
 
 通过标签进行选择的一个用例是确定节点集，方便 Pod 调度。
-有关更多信息，请参阅[选择节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)文档。
+有关更多信息，请参阅[选择节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)文档。
 

content/zh-cn/docs/concepts/overview/working-with-objects/names.md

@@ -17,15 +17,15 @@ For example, you can only have one Pod named `myapp-1234` within the same [names
 
 每个 Kubernetes 对象也有一个 [_UID_](#uids) 来标识在整个集群中的唯一性。
 
-比如，在同一个[名字空间](/zh/docs/concepts/overview/working-with-objects/namespaces/)
+比如，在同一个[名字空间](/zh-cn/docs/concepts/overview/working-with-objects/namespaces/)
 中有一个名为 `myapp-1234` 的 Pod，但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`。
 
 <!--
 For non-unique user-provided attributes, Kubernetes provides [labels](/docs/user-guide/labels) and [annotations](/docs/concepts/overview/working-with-objects/annotations/).
 -->
 对于用户提供的非唯一性的属性，Kubernetes 提供了
-[标签（Labels）](/zh/docs/concepts/working-with-objects/labels)和
-[注解（Annotation）](/zh/docs/concepts/overview/working-with-objects/annotations/)机制。
+[标签（Labels）](/zh-cn/docs/concepts/working-with-objects/labels)和
+[注解（Annotation）](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)机制。
 
 <!-- body -->
 
@@ -173,7 +173,7 @@ UUIDs 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667。
 * Read about [labels](/docs/concepts/overview/working-with-objects/labels/) in Kubernetes.
 * See the [Identifiers and Names in Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) design document.
 -->
-* 进一步了解 Kubernetes [标签](/zh/docs/concepts/overview/working-with-objects/labels/)
+* 进一步了解 Kubernetes [标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)
 * 参阅 [Kubernetes 标识符和名称](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)的设计文档
 
 

content/zh-cn/docs/concepts/overview/working-with-objects/namespaces.md

@@ -49,7 +49,7 @@ resource can only be in one namespace.
 <!--
 Namespaces are a way to divide cluster resources between multiple users (via [resource quota](/docs/concepts/policy/resource-quotas/)).
 -->
-名字空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/zh/docs/concepts/policy/resource-quotas/)）。
+名字空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/)）。
 
 <!--
 It is not necessary to use multiple namespaces to separate slightly different
@@ -69,7 +69,7 @@ for namespaces](/docs/tasks/administer-cluster/namespaces/).
 -->
 ## 使用名字空间
 
-名字空间的创建和删除在[名字空间的管理指南文档](/zh/docs/tasks/administer-cluster/namespaces/)描述。
+名字空间的创建和删除在[名字空间的管理指南文档](/zh-cn/docs/tasks/administer-cluster/namespaces/)描述。
 
 <!--
 Avoid creating namespaces with the prefix `kube-`, since it is reserved for Kubernetes system namespaces.
@@ -118,7 +118,7 @@ Kubernetes 会创建四个初始名字空间：
       这个名字空间的公共方面只是一种约定，而不是要求。
    * `kube-node-lease` 此名字空间用于与各个节点相关的
      [租约（Lease）](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)对象。
-      节点租期允许 kubelet 发送[心跳](/zh/docs/concepts/architecture/nodes/#heartbeats)，由此控制面能够检测到节点故障。
+      节点租期允许 kubelet 发送[心跳](/zh-cn/docs/concepts/architecture/nodes/#heartbeats)，由此控制面能够检测到节点故障。
 
 <!--
 ### Setting the namespace for a request
@@ -161,8 +161,8 @@ When you create a [Service](/docs/user-guide/services), it creates a correspondi
 -->
 ## 名字空间和 DNS
 
-当你创建一个[服务](/zh/docs/concepts/services-networking/service/)时，
-Kubernetes 会创建一个相应的 [DNS 条目](/zh/docs/concepts/services-networking/dns-pod-service/)。
+当你创建一个[服务](/zh-cn/docs/concepts/services-networking/service/)时，
+Kubernetes 会创建一个相应的 [DNS 条目](/zh-cn/docs/concepts/services-networking/dns-pod-service/)。
 
 <!--
 This entry is of the form `<service-name>.<namespace-name>.svc.cluster.local`, which means
@@ -180,7 +180,7 @@ As a result, all namespace names must be valid
 [RFC 1123 DNS labels](/docs/concepts/overview/working-with-objects/names/#dns-label-names).
 -->
 因此，所有的名字空间名称都必须是合法的
-[RFC 1123 DNS 标签](/zh/docs/concepts/overview/working-with-objects/names/#dns-label-names)。
+[RFC 1123 DNS 标签](/zh-cn/docs/concepts/overview/working-with-objects/names/#dns-label-names)。
 
 {{< warning >}}
 <!--
@@ -206,7 +206,7 @@ TLDs](https://data.iana.org/TLD/tlds-alpha-by-domain.txt).
 -->
 为了缓解这类问题，需要将创建名字空间的权限授予可信的用户。
 如果需要，你可以额外部署第三方的安全控制机制，例如以
-[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
+[准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/)
 的形式，阻止用户创建与公共 [TLD](https://data.iana.org/TLD/tlds-alpha-by-domain.txt)
 同名的名字空间。
 {{< /warning >}}
@@ -224,7 +224,7 @@ persistentVolumes, are not in any namespace.
 -->
 大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些名字空间中。
 但是名字空间资源本身并不在名字空间中。而且底层资源，例如
-[节点](/zh/docs/concepts/architecture/nodes/)和持久化卷不属于任何名字空间。
+[节点](/zh-cn/docs/concepts/architecture/nodes/)和持久化卷不属于任何名字空间。
 
 <!--
 To see which Kubernetes resources are and aren't in a namespace:
@@ -255,7 +255,7 @@ The value of the label is the namespace name.
 Kubernetes 控制面会为所有名字空间设置一个不可变更的
 {{< glossary_tooltip text="标签" term_id="label" >}}
 `kubernetes.io/metadata.name`，只要 `NamespaceDefaultLabelName` 这一
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
 被启用。标签的值是名字空间的名称。
 
 ## {{% heading "whatsnext" %}}
@@ -264,5 +264,5 @@ Kubernetes 控制面会为所有名字空间设置一个不可变更的
 * Learn more about [creating a new namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace).
 * Learn more about [deleting a namespace](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace).
 -->
-* 进一步了解[建立新的名字空间](/zh/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)。
-* 进一步了解[删除名字空间](/zh/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)。
+* 进一步了解[建立新的名字空间](/zh-cn/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)。
+* 进一步了解[删除名字空间](/zh-cn/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)。

content/zh-cn/docs/concepts/overview/working-with-objects/object-management.md

@@ -325,10 +325,10 @@ Disadvantages compared to imperative object configuration:
 - [Kubectl Book](https://kubectl.docs.kubernetes.io)
 - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 -->
-- [使用指令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
-- [使用对象配置管理 Kubernetes 对象（指令式）](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/)
-- [使用对象配置管理 Kubernetes 对象（声明式）](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/)
-- [使用 Kustomize（声明式）管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/kustomization/)
+- [使用指令式命令管理 Kubernetes 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/imperative-command/)
+- [使用对象配置管理 Kubernetes 对象（指令式）](/zh-cn/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [使用对象配置管理 Kubernetes 对象（声明式）](/zh-cn/docs/tasks/manage-kubernetes-objects/declarative-config/)
+- [使用 Kustomize（声明式）管理 Kubernetes 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/kustomization/)
 - [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
 - [Kubectl Book](https://kubectl.docs.kubernetes.io)
 - [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)

content/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents.md

@@ -31,7 +31,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` 对象的 Service，
 该 Service 使用标签来让控制平面确定，哪些 `EndpointSlice` 对象属于该 Service。
 除开标签，每个代表 Service 所管理的 `EndpointSlice` 都有一个属主引用。
@@ -132,7 +132,7 @@ bound to a Pod.
 ## 属主关系与 Finalizer   {#ownership-and-finalizers}
 
 当你告诉 Kubernetes 删除一个资源，API 服务器允许管理控制器处理该资源的任何 
-[Finalizer 规则](/zh/docs/concepts/overview/working-with-objects/finalizers/)。
+[Finalizer 规则](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)。
 {{<glossary_tooltip text="Finalizer" term_id="finalizer">}} 
 防止意外删除你的集群所依赖的、用于正常运作的资源。
 例如，如果你试图删除一个仍被 Pod 使用的 `PersistentVolume`，该资源不会被立即删除，
@@ -150,7 +150,7 @@ specify an orphan deletion policy, Kubernetes adds the `orphan` finalizer so
 that the controller ignores dependent resources after it deletes the owner
 object. 
 -->
-当你使用[前台或孤立级联删除](/zh/docs/concepts/architecture/garbage-collection/#cascading-deletion)时，
+当你使用[前台或孤立级联删除](/zh-cn/docs/concepts/architecture/garbage-collection/#cascading-deletion)时，
 Kubernetes 也会向属主资源添加 Finalizer。
 在前台删除中，会添加 `foreground` Finalizer，这样控制器必须在删除了拥有 
 `ownerReferences.blockOwnerDeletion=true` 的附属资源后，才能删除属主对象。
@@ -164,6 +164,6 @@ Kubernetes 也会向属主资源添加 Finalizer。
 * Learn about [garbage collection](/docs/concepts/architecture/garbage-collection).
 * Read the API reference for [object metadata](/docs/reference/kubernetes-api/common-definitions/object-meta/#System).
 -->
-* 了解更多关于 [Kubernetes Finalizer](/zh/docs/concepts/overview/working-with-objects/finalizers/)。
-* 了解关于[垃圾收集](/zh/docs/concepts/architecture/garbage-collection)。
+* 了解更多关于 [Kubernetes Finalizer](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)。
+* 了解关于[垃圾收集](/zh-cn/docs/concepts/architecture/garbage-collection)。
 * 阅读[对象元数据](/docs/reference/kubernetes-api/common-definitions/object-meta/#System)的 API 参考文档。

content/zh-cn/docs/concepts/policy/limit-range.md

@@ -11,7 +11,7 @@ By default, containers run with unbounded [compute resources](/docs/concepts/con
 With resource quotas, cluster administrators can restrict resource consumption and creation on a {{< glossary_tooltip text="namespace" term_id="namespace" >}} basis.
 Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all available resources. A LimitRange is a policy to constrain resource allocations (to Pods or Containers) in a namespace.
 -->
-默认情况下， Kubernetes 集群上的容器运行使用的[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/)没有限制。
+默认情况下， Kubernetes 集群上的容器运行使用的[计算资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/)没有限制。
 使用资源配额，集群管理员可以以{{< glossary_tooltip text="名字空间" term_id="namespace" >}}为单位，限制其资源的使用与创建。
 在命名空间中，一个 Pod 或 Container 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。
 有人担心，一个 Pod 或 Container 会垄断所有可用的资源。
@@ -53,7 +53,7 @@ The name of a LimitRange object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 -->
 LimitRange 的名称必须是合法的
-[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)。
 
 <!--
 ### Overview of Limit Range
@@ -122,10 +122,10 @@ For examples on using limits, see:
 -->
 关于使用限值的例子，可参看
 
-- [如何配置每个命名空间最小和最大的 CPU 约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。
-- [如何配置每个命名空间最小和最大的内存约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。
-- [如何配置每个命名空间默认的 CPU 申请值和限制值](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。
-- [如何配置每个命名空间默认的内存申请值和限制值](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。
-- [如何配置每个命名空间最小和最大存储使用量](/zh/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。
-- [配置每个命名空间的配额的详细例子](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)。
+- [如何配置每个命名空间最小和最大的 CPU 约束](/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。
+- [如何配置每个命名空间最小和最大的内存约束](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。
+- [如何配置每个命名空间默认的 CPU 申请值和限制值](/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。
+- [如何配置每个命名空间默认的内存申请值和限制值](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。
+- [如何配置每个命名空间最小和最大存储使用量](/zh-cn/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。
+- [配置每个命名空间的配额的详细例子](/zh-cn/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)。
 

content/zh-cn/docs/concepts/policy/node-resource-managers.md

@@ -30,7 +30,7 @@ The main manager, the Topology Manager, is a Kubelet component that co-ordinates
 The configuration of individual managers is elaborated in dedicated documents:
 -->
 主管理器，也叫拓扑管理器（Topology Manager），是一个 Kubelet 组件，
-它通过[策略](/zh/docs/tasks/administer-cluster/topology-manager/)，
+它通过[策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)，
 协调全局的资源管理过程。
 
 各个管理器的配置方式会在专项文档中详细阐述：
@@ -40,6 +40,6 @@ The configuration of individual managers is elaborated in dedicated documents:
 - [Device Manager](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager)
 - [Memory Manager Policies](/docs/tasks/administer-cluster/memory-manager/)
 -->
-- [CPU 管理器策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/)
-- [设备管理器](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager)
-- [内存管理器策略](/zh/docs/tasks/administer-cluster/memory-manager/)
+- [CPU 管理器策略](/zh-cn/docs/tasks/administer-cluster/cpu-management-policies/)
+- [设备管理器](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager)
+- [内存管理器策略](/zh-cn/docs/tasks/administer-cluster/memory-manager/)

content/zh-cn/docs/concepts/policy/pid-limiting.md

@@ -105,7 +105,7 @@ and limits. However, you specify it in a different way: rather than defining a
 Pod's resource limit in the `.spec` for a Pod, you configure the limit as a
 setting on the kubelet. Pod-defined PID limits are not currently supported.
 -->
-PID 限制是与[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/)
+PID 限制是与[计算资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/)
 请求和限制相辅相成的一种机制。不过，你需要用一种不同的方式来设置这一限制：
 你需要将其设置到 kubelet 上而不是在 Pod 的 `.spec` 中为 Pod 设置资源限制。
 目前还不支持在 Pod 级别设置 PID 限制。
@@ -146,7 +146,7 @@ gate](/docs/reference/command-line-tools-reference/feature-gates/)
 `SupportNodePidsLimit` to work.
 -->
 在 Kubernetes 1.20 版本之前，在节点级别通过 PID 资源限制预留 PID 的能力
-需要启用[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+需要启用[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
 `SupportNodePidsLimit` 才行。
 {{< /note >}}
 
@@ -166,7 +166,7 @@ Kubernetes 允许你限制 Pod 中运行的进程个数。你可以在节点级
 而不是为特定的 Pod 来将其设置为资源限制。
 每个节点都可以有不同的 PID 限制设置。
 要设置限制值，你可以设置 kubelet 的命令行参数 `--pod-max-pids`，或者
-在 kubelet 的[配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)
+在 kubelet 的[配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/)
 中设置 `PodPidsLimit`。
 
 {{< note >}}
@@ -176,7 +176,7 @@ the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 `SupportPodPidsLimit` to work.
 -->
 在 Kubernetes 1.20 版本之前，为 Pod 设置 PID 资源限制的能力需要启用
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
 `SupportNodePidsLimit` 才行。
 {{< /note >}}
 
@@ -197,7 +197,7 @@ Eviction signal value is calculated periodically and does NOT enforce the limit.
 
 你可以配置 kubelet 使之在 Pod 行为不正常或者消耗不正常数量资源的时候将其终止。
 这一特性称作驱逐。你可以针对不同的驱逐信号
-[配置资源不足的处理](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。
+[配置资源不足的处理](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。
 使用 `pid.available` 驱逐信号来配置 Pod 使用的 PID 个数的阈值。
 你可以设置硬性的和软性的驱逐策略。不过，即使使用硬性的驱逐策略，
 如果 PID 个数增长过快，节点仍然可能因为触及节点 PID 限制而进入一种不稳定状态。
@@ -233,6 +233,6 @@ Pod 行为不正常而没有 PID 可用。
 - 关于历史背景，请阅读
   [Kubernetes 1.14 中限制进程 ID 以提升稳定性](/blog/2019/04/15/process-id-limiting-for-stability-improvements-in-kubernetes-1.14/)
   的博文。
-- 请阅读[为容器管理资源](/zh/docs/concepts/configuration/manage-resources-containers/)。
-- 学习如何[配置资源不足情况的处理](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。
+- 请阅读[为容器管理资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/)。
+- 学习如何[配置资源不足情况的处理](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。