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

content/zh-cn/docs/concepts/workloads/controllers/deployment.md

@@ -1063,7 +1063,7 @@ Assuming [horizontal Pod autoscaling](/docs/tasks/run-application/horizontal-pod
 in your cluster, you can setup an autoscaler for your Deployment and choose the minimum and maximum number of
 Pods you want to run based on the CPU utilization of your existing Pods.
 -->
-假设集群启用了[Pod 的水平自动缩放](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)，
+假设集群启用了[Pod 的水平自动缩放](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)，
 你可以为 Deployment 设置自动缩放器，并基于现有 Pod 的 CPU 利用率选择要运行的
 Pod 个数下限和上限。
 
@@ -1854,7 +1854,7 @@ can create multiple Deployments, one for each release, following the canary patt
 ## 金丝雀部署 {#canary-deployment}
 
 如果要使用 Deployment 向用户子集或服务器子集上线版本，
-则可以遵循[资源管理](/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)
+则可以遵循[资源管理](/zh-cn/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)
 所描述的金丝雀模式，创建多个 Deployment，每个版本一个。
 
 <!--
@@ -1868,8 +1868,8 @@ configuring containers, and [using kubectl to manage resources](/docs/concepts/o
 ## 编写 Deployment 规约       {#writing-a-deployment-spec}
 
 同其他 Kubernetes 配置一样， Deployment 需要 `apiVersion`，`kind` 和 `metadata` 字段。
-有关配置文件的其他信息，请参考[部署 Deployment](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、
-配置容器和[使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/)等相关文档。
+有关配置文件的其他信息，请参考[部署 Deployment](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)、
+配置容器和[使用 kubectl 管理资源](/zh-cn/docs/concepts/overview/working-with-objects/object-management/)等相关文档。
 
 <!--
 The name of a Deployment object must be a valid
@@ -1878,7 +1878,7 @@ The name of a Deployment object must be a valid
 A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
 -->
 Deployment 对象的名称必须是合法的
-[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)。
 Deployment 还需要 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
 
 <!--
@@ -1894,7 +1894,7 @@ The `.spec.template` and `.spec.selector` are the only required field of the `.s
 
 The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
 -->
-`.spec.template` 是一个 [Pod 模板](/zh/docs/concepts/workloads/pods/#pod-templates)。
+`.spec.template` 是一个 [Pod 模板](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。
 它和 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的语法规则完全相同。
 只是这里它是嵌套的，因此不需要 `apiVersion` 或 `kind`。
 
@@ -1909,7 +1909,7 @@ labels and an appropriate restart policy. For labels, make sure not to overlap w
 Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Always` is
 allowed, which is the default if not specified.
 -->
-只有 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
+只有 [`.spec.template.spec.restartPolicy`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
 等于 `Always` 才是被允许的，这也是在没有指定时的默认设置。
 
 <!--
@@ -1936,7 +1936,7 @@ then applying that manifest overwrites the manual scaling that you previously di
 If a [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) (or any
 similar API for horizontal scaling) is managing scaling for a Deployment, don't set `.spec.replicas`.
 -->
-如果一个 [HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
+如果一个 [HorizontalPodAutoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/)
 （或者其他执行水平扩缩操作的类似 API）在管理 Deployment 的扩缩，
 则不要设置 `.spec.replicas`。
 
@@ -1960,7 +1960,7 @@ for the Pods targeted by this Deployment.
 ### 选择算符   {#selector}
 
 `.spec.selector` 是指定本 Deployment 的 Pod
-[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)的必需字段。
+[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)的必需字段。
 
 `.spec.selector` 必须匹配 `.spec.template.metadata.labels`，否则请求会被 API 拒绝。
 
@@ -2033,7 +2033,7 @@ replacement will be created immediately (even if the old Pod is still in a Termi
 才会创建新版本的 Pod。如果你手动删除一个 Pod，其生命周期是由 ReplicaSet 来控制的，
 后者会立即创建一个替换 Pod（即使旧的 Pod 仍然处于 Terminating 状态）。
 如果你需要一种“最多 n 个”的 Pod 个数保证，你需要考虑使用
-[StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)。
+[StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/)。
 {{< /note >}}
 
 <!--
@@ -2138,7 +2138,7 @@ a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/
 在没有任意容器崩溃情况下的最小就绪时间，
 只有超出这个时间 Pod 才被视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。
 要了解何时 Pod 被视为就绪，
-可参考[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
+可参考[容器探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
 
 <!--
 ### Revision History Limit
@@ -2192,11 +2192,11 @@ Deployment 在创建时是默认不会处于暂停状态。
 * Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how
   you can use it to manage application availability during disruptions.
 -->
-* 了解 [Pod](/zh/docs/concepts/workloads/pods)。
-* [使用 Deployment 运行一个无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。
+* 了解 [Pod](/zh-cn/docs/concepts/workloads/pods)。
+* [使用 Deployment 运行一个无状态应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)。
 * `Deployment` 是 Kubernetes REST API 中的一个顶层资源。
   阅读 {{< api-reference page="workload-resources/deployment-v1" >}}
   对象定义，以了解 Deployment 的 API 细节。
-* 阅读 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/)
+* 阅读 [PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/)
   了解如何使用它来在可能出现干扰的情况下管理应用的可用性。
 

content/zh-cn/docs/concepts/workloads/controllers/job.md

@@ -193,7 +193,7 @@ A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/d
 ## 编写 Job 规约    {#writing-a-job-spec}
 
 与 Kubernetes 中其他资源的配置类似，Job 也需要 `apiVersion`、`kind` 和 `metadata` 字段。
-Job 的名字必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
+Job 的名字必须是合法的 [DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
 
 Job 配置还需要一个 [`.spec` 节](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
 
@@ -213,14 +213,14 @@ Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-po
 
 Job 的 `.spec` 中只有 `.spec.template` 是必需的字段。
 
-字段 `.spec.template` 的值是一个 [Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)。
+字段 `.spec.template` 的值是一个 [Pod 模版](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。
 其定义规范与 {{< glossary_tooltip text="Pod" term_id="pod" >}}
 完全相同，只是其中不再需要 `apiVersion` 或 `kind` 字段。
 
 除了作为 Pod 所必需的字段之外，Job 中的 Pod 模版必需设置合适的标签
 （参见 [Pod 选择算符](#pod-selector)）和合适的重启策略。
 
-Job 中 Pod 的 [`RestartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
+Job 中 Pod 的 [`RestartPolicy`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
 只能设置为 `Never` 或 `OnFailure` 之一。
 
 <!--
@@ -386,7 +386,7 @@ Jobs with _fixed completion count_ - that is, jobs that have non null
 
   当每个索引都对应一个完成完成的 Pod 时，Job 被认为是已完成的。
   关于如何使用这种模式的更多信息，可参阅
-  [用带索引的 Job 执行基于静态任务分配的并行处理](/zh/docs/tasks/job/indexed-parallel-processing-static/)。
+  [用带索引的 Job 执行基于静态任务分配的并行处理](/zh-cn/docs/tasks/job/indexed-parallel-processing-static/)。
   需要注意的是，对同一索引值可能被启动的 Pod 不止一个，尽管这种情况很少发生。
   这时，只有一个会被记入完成计数中。
 
@@ -410,7 +410,7 @@ Pod 则继续留在当前节点，但容器会被重新运行。
 因此，你的程序需要能够处理在本地被重启的情况，或者要设置
 `.spec.template.spec.restartPolicy = "Never"`。
 关于 `restartPolicy` 的更多信息，可参阅
-[Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/#example-states)。
+[Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#example-states)。
 
 <!--
 An entire Pod can also fail, for a number of reasons, such as when the pod is kicked off the node
@@ -574,7 +574,7 @@ Keep in mind that the `restartPolicy` applies to the Pod, and not to the Job its
 That is, the Job termination mechanisms activated with `.spec.activeDeadlineSeconds` and `.spec.backoffLimit` result in a permanent Job failure that requires manual intervention to resolve.
 -->
 注意 Job 规约和 Job 中的
-[Pod 模版规约](/zh/docs/concepts/workloads/pods/init-containers/#detailed-behavior)
+[Pod 模版规约](/zh-cn/docs/concepts/workloads/pods/init-containers/#detailed-behavior)
 都有 `activeDeadlineSeconds` 字段。
 请确保你在合适的层次设置正确的字段。
 
@@ -599,7 +599,7 @@ cleaned up by CronJobs based on the specified capacity-based cleanup policy.
 完成的 Job 通常不需要留存在系统中。在系统中一直保留它们会给 API
 服务器带来额外的压力。
 如果 Job 由某种更高级别的控制器来管理，例如
-[CronJobs](/zh/docs/concepts/workloads/controllers/cron-jobs/)，
+[CronJobs](/zh-cn/docs/concepts/workloads/controllers/cron-jobs/)，
 则 Job 可以被 CronJob 基于特定的根据容量裁定的清理策略清理掉。
 
 ### 已完成 Job 的 TTL 机制  {#ttl-mechanisms-for-finished-jobs}
@@ -621,7 +621,7 @@ be honored.
 For example:
 -->
 自动清理已完成 Job （状态为 `Complete` 或 `Failed`）的另一种方式是使用由
-[TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)所提供
+[TTL 控制器](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/)所提供
 的 TTL 机制。
 通过设置 Job 的 `.spec.ttlSecondsAfterFinished` 字段，可以让该控制器清理掉
 已结束的资源。
@@ -720,10 +720,10 @@ The pattern names are also links to examples and more detailed description.
 
 | 模式  | 单个 Job 对象 | Pods 数少于工作条目数？ | 直接使用应用无需修改? |
 | ----- |:-------------:|:-----------------------:|:---------------------:|
-| [每工作条目一 Pod 的队列](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 有时 |
-| [Pod 数量可变的队列](/zh/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ |  |
-| [静态任务分派的带索引的 Job](/zh/docs/tasks/job/indexed-parallel-processing-static) | ✓ |  | ✓ |
-| [Job 模版扩展](/zh/docs/tasks/job/parallel-processing-expansion/)  |  |  | ✓ |
+| [每工作条目一 Pod 的队列](/zh-cn/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 有时 |
+| [Pod 数量可变的队列](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ |  |
+| [静态任务分派的带索引的 Job](/zh-cn/docs/tasks/job/indexed-parallel-processing-static) | ✓ |  | ✓ |
+| [Job 模版扩展](/zh-cn/docs/tasks/job/parallel-processing-expansion/)  |  |  | ✓ |
 
 <!--
 When you specify completions with `.spec.completions`, each Pod created by the Job controller
@@ -746,10 +746,10 @@ Here, `W` is the number of work items.
 
 | 模式  | `.spec.completions` |  `.spec.parallelism` |
 | ----- |:-------------------:|:--------------------:|
-| [每工作条目一 Pod 的队列](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意值 |
-| [Pod 个数可变的队列](/zh/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意值 |
-| [静态任务分派的带索引的 Job](/zh/docs/tasks/job/indexed-parallel-processing-static) | W |  | 任意值 |
-| [Job 模版扩展](/zh/docs/tasks/job/parallel-processing-expansion/) | 1 | 应该为 1 |
+| [每工作条目一 Pod 的队列](/zh-cn/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意值 |
+| [Pod 个数可变的队列](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意值 |
+| [静态任务分派的带索引的 Job](/zh-cn/docs/tasks/job/indexed-parallel-processing-static) | W |  | 任意值 |
+| [Job 模版扩展](/zh-cn/docs/tasks/job/parallel-processing-expansion/) | 1 | 应该为 1 |
 
 <!--
 ## Advanced usage
@@ -912,8 +912,8 @@ on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/
 It is enabled by default.
 -->
 {{< note >}}
-为了使用此功能，你必须在 [API 服务器](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)上启用
-`JobMutableNodeSchedulingDirectives` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+为了使用此功能，你必须在 [API 服务器](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)上启用
+`JobMutableNodeSchedulingDirectives` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
 默认情况下启用。
 {{< /note >}}
 
@@ -1084,10 +1084,10 @@ on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/
 and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/).
 It is enabled by default.
 -->
-要使用该行为，你必须为 [API 服务器](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
-和[控制器管理器](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
+要使用该行为，你必须为 [API 服务器](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)
+和[控制器管理器](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/)
 启用 `JobTrackingWithFinalizers`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
 默认是启用的。
 
 <!--
@@ -1175,11 +1175,11 @@ for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
 -->
 ### 副本控制器    {#replication-controller}
 
-Job 与[副本控制器](/zh/docs/concepts/workloads/controllers/replicationcontroller/)是彼此互补的。
+Job 与[副本控制器](/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/)是彼此互补的。
 副本控制器管理的是那些不希望被终止的 Pod （例如，Web 服务器），
 Job 管理的是那些希望被终止的 Pod（例如，批处理作业）。
 
-正如在 [Pod 生命期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 中讨论的，
+正如在 [Pod 生命期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/) 中讨论的，
 `Job` 仅适合于 `restartPolicy` 设置为 `OnFailure` 或 `Never` 的 Pod。
 注意：如果 `restartPolicy` 未设置，其默认值是 `Always`。
 
@@ -1230,13 +1230,13 @@ object, but maintains complete control over what Pods are created and how work i
   can use to define a series of Jobs that will run based on a schedule, similar to
   the UNIX tool `cron`.
 -->
-* 了解 [Pods](/zh/docs/concepts/workloads/pods)。
+* 了解 [Pods](/zh-cn/docs/concepts/workloads/pods)。
 * 了解运行 Job 的不同的方式：
-  * [使用工作队列进行粗粒度并行处理](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/)
-  * [使用工作队列进行精细的并行处理](/zh/docs/tasks/job/fine-parallel-processing-work-queue/)
-  * [使用索引作业完成静态工作分配下的并行处理](/zh/docs/tasks/job/indexed-parallel-processing-static/)（Beta 阶段）
-  * 基于一个模板运行多个 Job：[使用展开的方式进行并行处理](/zh/docs/tasks/job/parallel-processing-expansion/)
+  * [使用工作队列进行粗粒度并行处理](/zh-cn/docs/tasks/job/coarse-parallel-processing-work-queue/)
+  * [使用工作队列进行精细的并行处理](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/)
+  * [使用索引作业完成静态工作分配下的并行处理](/zh-cn/docs/tasks/job/indexed-parallel-processing-static/)（Beta 阶段）
+  * 基于一个模板运行多个 Job：[使用展开的方式进行并行处理](/zh-cn/docs/tasks/job/parallel-processing-expansion/)
 * 跟随[自动清理完成的 Job](#clean-up-finished-jobs-automatically) 文中的链接，了解你的集群如何清理完成和失败的任务。
 * `Job` 是 Kubernetes REST API 的一部分。阅读 {{< api-reference page="workload-resources/job-v1" >}}
    对象定义理解关于该资源的 API。
-* 阅读 [`CronJob`](/zh/docs/concepts/workloads/controllers/cron-jobs/)，它允许你定义一系列定期运行的 Job，类似于 UNIX 工具 `cron`。
+* 阅读 [`CronJob`](/zh-cn/docs/concepts/workloads/controllers/cron-jobs/)，它允许你定义一系列定期运行的 Job，类似于 UNIX 工具 `cron`。

content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md

@@ -30,8 +30,8 @@ weight: 90
 A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication.
 -->
 {{< note >}}
-现在推荐使用配置 [`ReplicaSet`](/zh/docs/concepts/workloads/controllers/replicaset/) 的
-[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 来建立副本管理机制。
+现在推荐使用配置 [`ReplicaSet`](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 的
+[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/) 来建立副本管理机制。
 {{< /note >}}
 
 <!--
@@ -196,7 +196,7 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun
 与所有其它 Kubernetes 配置一样，ReplicationController 需要 `apiVersion`、
 `kind` 和 `metadata` 字段。
 有关使用配置文件的常规信息，参考
-[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)。
+[对象管理](/zh-cn/docs/concepts/overview/working-with-objects/object-management/)。
 
 ReplicationController 也需要一个 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
 
@@ -211,8 +211,8 @@ The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overv
 
 `.spec.template` 是 `.spec` 的唯一必需字段。
 
-`.spec.template` 是一个 [Pod 模板](/zh/docs/concepts/workloads/pods/#pod-templates)。
-它的模式与 [Pod](/zh/docs/concepts/workloads/pods/) 完全相同，只是它是嵌套的，没有 `apiVersion` 或 `kind` 属性。
+`.spec.template` 是一个 [Pod 模板](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。
+它的模式与 [Pod](/zh-cn/docs/concepts/workloads/pods/) 完全相同，只是它是嵌套的，没有 `apiVersion` 或 `kind` 属性。
 
 <!--
 In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate
@@ -226,10 +226,10 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.
 除了 Pod 所需的字段外，ReplicationController 中的 Pod 模板必须指定适当的标签和适当的重新启动策略。
 对于标签，请确保不与其他控制器重叠。参考 [Pod 选择算符](#pod-selector)。
 
-只允许 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。
+只允许 [`.spec.template.spec.restartPolicy`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。
 
 对于本地容器重启，ReplicationController 委托给节点上的代理，
-例如 [Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 或 Docker。
+例如 [Kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 或 Docker。
 
 <!--
 ### Labels on the ReplicationController
@@ -256,7 +256,7 @@ deleted. This allows the ReplicationController to be replaced without affecting
 -->
 ### Pod 选择算符 {#pod-selector}
 
-`.spec.selector` 字段是一个[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 
+`.spec.selector` 字段是一个[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 
 ReplicationController 管理标签与选择算符匹配的所有 Pod。
 它不区分它创建或删除的 Pod 和其他人或进程创建或删除的 Pod。
 这允许在不影响正在运行的 Pod 的情况下替换 ReplicationController。
@@ -323,7 +323,7 @@ When using the REST API or [client library](/docs/reference/using-api/client-lib
 kubectl 将 ReplicationController 缩放为 0 并等待以便在删除 ReplicationController 本身之前删除每个 Pod。
 如果这个 kubectl 命令被中断，可以重新启动它。
 
-当使用 REST API 或[客户端库](/zh/docs/reference/using-api/client-libraries)时，你需要明确地执行这些步骤（缩放副本为 0、
+当使用 REST API 或[客户端库](/zh-cn/docs/reference/using-api/client-libraries)时，你需要明确地执行这些步骤（缩放副本为 0、
 等待 Pod 删除，之后删除 ReplicationController 资源）。
 
 <!--
@@ -341,7 +341,7 @@ When using the REST API or [client library](/docs/reference/using-api/client-lib
 
 使用 kubectl，为 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 指定 `--cascade=orphan` 选项。
 
-当使用 REST API 或客户端库(/zh/docs/reference/using-api/client-libraries)时，只需删除 ReplicationController 对象。
+当使用 REST API 或客户端库(/zh-cn/docs/reference/using-api/client-libraries)时，只需删除 ReplicationController 对象。
 
 <!--
 Once the original is deleted, you can create a new ReplicationController to replace it.  As long
@@ -416,7 +416,7 @@ Rolling update is implemented in the client tool
 这两个 ReplicationController 将需要创建至少具有一个不同标签的 Pod，比如 Pod 主要容器的镜像标签，因为通常是镜像更新触发滚动更新。
 
 滚动更新是在客户端工具 [`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)
-中实现的。访问 [`kubectl rolling-update` 任务](/zh/docs/tasks/run-application/rolling-update-replication-controller/)以获得更多的具体示例。
+中实现的。访问 [`kubectl rolling-update` 任务](/zh-cn/docs/tasks/run-application/rolling-update-replication-controller/)以获得更多的具体示例。
 
 <!--
 ### Multiple release tracks
@@ -534,9 +534,9 @@ Note that we recommend using Deployments instead of directly using Replica Sets,
 
 ### ReplicaSet
 
-[`ReplicaSet`](/zh/docs/concepts/workloads/controllers/replicaset/) 是下一代 ReplicationController，
-支持新的[基于集合的标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#set-based-requirement)。
-它主要被 [`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/)
+[`ReplicaSet`](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 是下一代 ReplicationController，
+支持新的[基于集合的标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#set-based-requirement)。
+它主要被 [`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/)
 用来作为一种编排 Pod 创建、删除及更新的机制。
 请注意，我们推荐使用 Deployment 而不是直接使用 ReplicaSet，除非
 你需要自定义更新编排或根本不需要更新。
@@ -550,7 +550,7 @@ because they are declarative, server-side, and have additional features.
 -->
 ### Deployment （推荐）
 
-[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象，用于更新其底层 ReplicaSet 及其 Pod。
+[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象，用于更新其底层 ReplicaSet 及其 Pod。
 如果你想要这种滚动更新功能，那么推荐使用 Deployment，因为它们是声明式的、服务端的，并且具有其它特性。
 
 <!--
@@ -575,7 +575,7 @@ Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead o
 ### Job
 
 对于预期会自行终止的 Pod (即批处理任务)，使用
-[`Job`](/zh/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。
+[`Job`](/zh-cn/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。
 
 <!--
 ### DaemonSet
@@ -588,7 +588,7 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
 ### DaemonSet
 
 对于提供机器级功能（例如机器监控或机器日志记录）的 Pod，
-使用 [`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) 而不是
+使用 [`DaemonSet`](/zh-cn/docs/concepts/workloads/controllers/daemonset/) 而不是
 ReplicationController。
 这些 Pod 的生命期与机器的生命期绑定：它们需要在其他 Pod 启动之前在机器上运行，
 并且在机器准备重新启动或者关闭时安全地终止。
@@ -605,8 +605,8 @@ ReplicationController。
 -->
 ## {{% heading "whatsnext" %}}
 
-- 了解 [Pods](/zh/docs/concepts/workloads/pods)。
-- 了解 [Depolyment](/zh/docs/concepts/workloads/controllers/deployment/)，ReplicationController 的替代品。
+- 了解 [Pods](/zh-cn/docs/concepts/workloads/pods)。
+- 了解 [Depolyment](/zh-cn/docs/concepts/workloads/controllers/deployment/)，ReplicationController 的替代品。
 - `ReplicationController` 是 Kubernetes REST API 的一部分，阅读 {{< api-reference page="workload-resources/replication-controller-v1" >}}
   对象定义以了解 replication controllers 的 API。
 

content/zh-cn/docs/concepts/workloads/controllers/statefulset.md

@@ -53,8 +53,8 @@ that provides a set of stateless replicas.
 在上面描述中，“稳定的”意味着 Pod 调度或重调度的整个过程是有持久性的。
 如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用
 由一组无状态的副本控制器提供的工作负载来部署应用程序，比如
-[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 或者
-[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)
+[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/) 或者
+[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/)
 可能更适用于你的无状态应用部署需要。
 
 <!--
@@ -77,7 +77,7 @@ that provides a set of stateless replicas.
   基于所请求的 `storage class` 来提供，或者由管理员预先提供。
 * 删除或者收缩 StatefulSet 并*不会*删除它关联的存储卷。
   这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。
-* StatefulSet 当前需要[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
+* StatefulSet 当前需要[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)
   来负责 Pod 的网络标识。你需要负责创建此服务。
 * 当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。
   为了实现 StatefulSet 中的 Pod 可以有序地且体面地终止，可以在删除之前将 StatefulSet
@@ -162,9 +162,9 @@ The name of a StatefulSet object must be a valid
 * 名为 `nginx` 的 Headless Service 用来控制网络域名。
 * 名为 `web` 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。
 * `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的
-  [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
+  [PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
 
-StatefulSet 的命名需要遵循[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)规范。
+StatefulSet 的命名需要遵循[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)规范。
 
 <!--
 ### Pod Selector
@@ -187,7 +187,7 @@ You can set the  `.spec.volumeClaimTemplates` which can provide stable storage u
 
 你可以设置 `.spec.volumeClaimTemplates`，
 它可以使用 PersistentVolume 制备程序所准备的
-[PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
+[PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
 
 <!-- ### Minimum ready seconds -->
 ### 最短就绪秒数 {#minimum-ready-seconds}
@@ -207,7 +207,7 @@ available as soon as it is ready). To learn more about when a Pod is considered
 请通过取消设置 StatefulSetMinReadySeconds 标志来选择退出。
 该字段默认为 0（Pod 准备就绪后将被视为可用）。
 要了解有关何时认为 Pod 准备就绪的更多信息，
-请参阅[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
+请参阅[容器探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
 
 <!--
 ## Pod Identity
@@ -252,7 +252,7 @@ by the `serviceName` field on the StatefulSet.
 StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。
 组合主机名的格式为`$(StatefulSet 名称)-$(序号)`。
 上例将会创建三个名称分别为 `web-0、web-1、web-2` 的 Pod。
-StatefulSet 可以使用 [无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
+StatefulSet 可以使用 [无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)
 控制它的 Pod 的网络域。管理域的这个服务的格式为：
 `$(服务名称).$(命名空间).svc.cluster.local`，其中 `cluster.local` 是集群域。
 一旦每个 Pod 创建成功，就会得到一个匹配的 DNS 子域，格式为：
@@ -286,7 +286,7 @@ responsible for the network identity of the pods.
 - 直接查询 Kubernetes API（比如，利用 watch 机制）而不是依赖于 DNS 查询
 - 缩短 Kubernetes DNS 驱动的缓存时长（通常这意味着修改 CoreDNS 的 ConfigMap，目前缓存时长为 30 秒）
 
-正如[限制](#limitations)中所述，你需要负责创建[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
+正如[限制](#limitations)中所述，你需要负责创建[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)
 以便为 Pod 提供网络标识。
 
 <!--
@@ -314,7 +314,7 @@ Cluster Domain will be set to `cluster.local` unless
 [otherwise configured](/docs/concepts/services-networking/dns-pod-service/#how-it-works).
 -->
 {{< note >}}
-集群域会被设置为 `cluster.local`，除非有[其他配置](/zh/docs/concepts/services-networking/dns-pod-service/)。
+集群域会被设置为 `cluster.local`，除非有[其他配置](/zh-cn/docs/concepts/services-networking/dns-pod-service/)。
 {{< /note >}}
 
 <!--
@@ -371,7 +371,7 @@ The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of
 -->
 StatefulSet 不应将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0。
 这种做法是不安全的，要强烈阻止。更多的解释请参考
-[强制删除 StatefulSet Pod](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/)。
+[强制删除 StatefulSet Pod](/zh-cn/docs/tasks/run-application/force-delete-stateful-set-pod/)。
 
 <!--
 When the nginx example above is created, three Pods will be deployed in the order
@@ -382,7 +382,7 @@ web-2 is launched, web-2 will not be launched until web-0 is successfully relaun
 becomes Running and Ready.
 -->
 在上面的 nginx 示例被创建后，会按照 web-0、web-1、web-2 的顺序部署三个 Pod。
-在 web-0 进入 [Running 和 Ready](/zh/docs/concepts/workloads/pods/pod-lifecycle/)
+在 web-0 进入 [Running 和 Ready](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)
 状态前不会部署 web-1。在 web-1 进入 Running 和 Ready 状态前不会部署 web-2。
 如果 web-1 已经处于 Running 和 Ready 状态，而 web-2 尚未部署，在此期间发生了
 web-0 运行失败，那么 web-2 将不会被部署，要等到 web-0 部署完成并进入 Running 和
@@ -553,7 +553,7 @@ enabled.
 -->
 {{< note >}}
 `maxUnavailable` 字段处于 Alpha 阶段，仅当 API 服务器启用了 `MaxUnavailableStatefulSet`
-[特性门控](/zh/docs/reference/commmand-line-tools-reference/feature-gates/)时才起作用。
+[特性门控](/zh-cn/docs/reference/commmand-line-tools-reference/feature-gates/)时才起作用。
 {{< /note >}}
 
 <!--
@@ -608,7 +608,7 @@ StatefulSet:
 在 StatefulSet 的生命周期中，可选字段 
 `.spec.persistentVolumeClaimRetentionPolicy` 控制是否删除以及如何删除 PVC。
 使用该字段，你必须启用 `StatefulSetAutoDeletePVC`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
 启用后，你可以为每个 StatefulSet 配置两个策略：
 
 <!-- 
@@ -692,7 +692,7 @@ policy to `Delete`, an owner reference to the StatefulSet instance is placed on
 associated with that StatefulSet. 
 -->
 StatefulSet {{<glossary_tooltip text="控制器" term_id="controller">}}为其 PVC 添加了
-[属主引用](/zh/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)，
+[属主引用](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)，
 这些 PVC 在 Pod 终止后被{{<glossary_tooltip text="垃圾回收器" term_id="garbage-collection">}}删除。
 这使 Pod 能够在删除 PVC 之前（以及在删除后备 PV 和卷之前，取决于保留策略）干净地卸载所有卷。
 当你设置 `whenDeleted` 删除策略，对 StatefulSet 实例的属主引用放置在与该 StatefulSet 关联的所有 PVC 上。
@@ -756,7 +756,7 @@ Statefulset, don't set `.spec.replicas`. Instead, allow the Kubernetes
 {{<glossary_tooltip text="control plane" term_id="control-plane" >}} to manage
 the `.spec.replicas` field automatically.
 -->
-如果 [HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
+如果 [HorizontalPodAutoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/)
 （或任何类似的水平缩放 API）正在管理 Statefulset 的缩放，
 请不要设置 `.spec.replicas`。
 相反，允许 Kubernetes 控制平面自动管理 `.spec.replicas` 字段。
@@ -779,15 +779,15 @@ the `.spec.replicas` field automatically.
 * Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how
   you can use it to manage application availability during disruptions.
 -->
-* 了解 [Pod](/zh/docs/concepts/workloads/pods)。
+* 了解 [Pod](/zh-cn/docs/concepts/workloads/pods)。
 * 了解如何使用 StatefulSet
-  * 跟随示例[部署有状态应用](/zh/docs/tutorials/stateful-application/basic-stateful-set/)。
-  * 跟随示例[使用 StatefulSet 部署 Cassandra](/zh/docs/tutorials/stateful-application/cassandra/)。
-  * 跟随示例[运行多副本的有状态应用程序](/zh/docs/tasks/run-application/run-replicated-stateful-application/)。
-  * 了解如何[扩缩 StatefulSet](/zh/docs/tasks/run-application/scale-stateful-set/)。
-  * 了解[删除 StatefulSet](/zh/docs/tasks/run-application/delete-stateful-set/)涉及到的操作。
-  * 了解如何[配置 Pod 以使用卷进行存储](/zh/docs/tasks/configure-pod-container/configure-volume-storage/)。
-  * 了解如何[配置 Pod 以使用 PersistentVolume 作为存储](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。
+  * 跟随示例[部署有状态应用](/zh-cn/docs/tutorials/stateful-application/basic-stateful-set/)。
+  * 跟随示例[使用 StatefulSet 部署 Cassandra](/zh-cn/docs/tutorials/stateful-application/cassandra/)。
+  * 跟随示例[运行多副本的有状态应用程序](/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/)。
+  * 了解如何[扩缩 StatefulSet](/zh-cn/docs/tasks/run-application/scale-stateful-set/)。
+  * 了解[删除 StatefulSet](/zh-cn/docs/tasks/run-application/delete-stateful-set/)涉及到的操作。
+  * 了解如何[配置 Pod 以使用卷进行存储](/zh-cn/docs/tasks/configure-pod-container/configure-volume-storage/)。
+  * 了解如何[配置 Pod 以使用 PersistentVolume 作为存储](/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。
 * `StatefulSet` 是 Kubernetes REST API 中的顶级资源。阅读 {{< api-reference page="workload-resources/stateful-set-v1" >}}
    对象定义理解关于该资源的 API。
-* 阅读 [Pod 干扰预算（Disruption Budget）](/zh/docs/concepts/workloads/pods/disruptions/)，了解如何在干扰下运行高度可用的应用。
+* 阅读 [Pod 干扰预算（Disruption Budget）](/zh-cn/docs/concepts/workloads/pods/disruptions/)，了解如何在干扰下运行高度可用的应用。

content/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished.md

@@ -37,7 +37,7 @@ up finished Jobs (either `Complete` or `Failed`) automatically by specifying the
 
 TTL-after-finished 控制器只支持 Job。集群操作员可以通过指定 Job 的 `.spec.ttlSecondsAfterFinished`
 字段来自动清理已结束的作业（`Complete` 或 `Failed`），如
-[示例](/zh/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
+[示例](/zh-cn/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
 所示。
 
 <!--
@@ -72,9 +72,9 @@ The TTL seconds can be set at any time. Here are some examples for setting the
 -->
 * 在作业清单（manifest）中指定此字段，以便 Job 在完成后的某个时间被自动清除。
 * 将此字段设置为现有的、已完成的作业，以采用此新功能。
-* 在创建作业时使用 [mutating admission webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
+* 在创建作业时使用 [mutating admission webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
   动态设置该字段。集群管理员可以使用它对完成的作业强制执行 TTL 策略。
-* 使用 [mutating admission webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
+* 使用 [mutating admission webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
   在作业完成后动态设置该字段，并根据作业状态、标签等选择不同的 TTL 值。
 
 <!--
@@ -123,6 +123,6 @@ very small. Please be aware of this risk when setting a non-zero TTL.
 * [Clean up Jobs automatically](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
 * [Design doc](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/592-ttl-after-finish/README.md)
 -->
-* [自动清理 Job](/zh/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
+* [自动清理 Job](/zh-cn/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
 * [设计文档](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/592-ttl-after-finish/README.md)