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