Merge pull request #35462 from Sea-n/zh-ref-link

[zh-cn] Update /zh/ to /zh-cn/ for some pages

Author: k8s-ci-robot

content/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests.md

@@ -447,7 +447,7 @@ O is the group that this user will belong to. You can refer to
 
 下面的脚本展示了如何生成 PKI 私钥和 CSR。
 设置 CSR 的 CN 和 O 属性很重要。CN 是用户名，O 是该用户归属的组。
-你可以参考 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) 了解标准组的信息。
+你可以参考 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 了解标准组的信息。
 
 ```shell
 openssl genrsa -out myuser.key 2048
@@ -524,7 +524,7 @@ kubectl certificate approve myuser
 <!--
 ### Get the certificate
 
-Retrieve the certificate from the CSR.
+Retrieve the certificate from the CSR:
 -->
 ### 取得证书 {#get-the-certificate}
 
@@ -535,7 +535,7 @@ kubectl get csr/myuser -o yaml
 ```
 
 <!--
-The Certificate value is in Base64-encoded format under `status.certificate`.
+The certificate value is in Base64-encoded format under `status.certificate`.
 
 Export the issued certificate from the CertificateSigningRequest.
 
@@ -614,7 +614,7 @@ kubectl config use-context myuser
 ```
 
 <!--
-## Approval or rejection   {#approval-rejection}
+## Approval or rejection  {#approval-rejection}
 
 ### Control plane automated approval {#approval-rejection-control-plane}
 
@@ -699,6 +699,7 @@ status:
     reason: ApprovedByMyPolicy # You can set this to any string
     type: Approved
 ```
+
 <!--
 For `Denied` CSRs:
 -->
@@ -744,7 +745,7 @@ were marked as approved.
 ### 控制平面签名者    {#signer-control-plane}
 
 Kubernetes 控制平面实现了每一个
-[Kubernetes 签名者](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)，
+[Kubernetes 签名者](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)，
 每个签名者的实现都是 kube-controller-manager 的一部分。
 
 {{< note >}}
@@ -780,7 +781,7 @@ Example certificate content:
 
 REST API 的用户可以通过向待签名的 CSR 的 `status` 子资源提交更新请求来对 CSR 进行签名。
 
-作为这个请求的一部分， `status.certificate` 字段应设置为已签名的证书。
+作为这个请求的一部分，`status.certificate` 字段应设置为已签名的证书。
 此字段可包含一个或多个 PEM 编码的证书。
 
 所有的 PEM 块必须具备 "CERTIFICATE" 标签，且不包含文件头，且编码的数据必须是
@@ -841,7 +842,7 @@ status:
 * For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1
 * For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986)
 -->
-* 参阅 [管理集群中的 TLS 认证](/zh/docs/tasks/tls/managing-tls-in-a-cluster/)
+* 参阅 [管理集群中的 TLS 认证](/zh-cn/docs/tasks/tls/managing-tls-in-a-cluster/)
 * 查看 kube-controller-manager 中[签名者](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)部分的源代码
 * 查看 kube-controller-manager 中[批准者](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go)部分的源代码
 * 有关 X.509 本身的详细信息，请参阅 [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) 第3.1节

content/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md

@@ -35,14 +35,14 @@ This in turn, can make it challenging to initialize or scale a cluster.
 这也使得初始化或者扩缩一个集群的操作变得具有挑战性。
 
 <!--
-In order to simplify the process, beginning in version 1.4, Kubernetes introduced a certificate request and signing API to simplify the process. The proposal can be
+In order to simplify the process, beginning in version 1.4, Kubernetes introduced a certificate request and signing API. The proposal can be
 found [here](https://github.com/kubernetes/kubernetes/pull/20439).
 
 This document describes the process of node initialization, how to set up TLS client certificate bootstrapping for
 kubelets, and how it works.
 -->
 为了简化这一过程，从 1.4 版本开始，Kubernetes 引入了一个证书请求和签名
-API 以便简化此过程。该提案可在
+API。该提案可在
 [这里](https://github.com/kubernetes/kubernetes/pull/20439)看到。
 
 本文档描述节点初始化的过程，如何为 kubelet 配置 TLS 客户端证书启动引导，
@@ -255,7 +255,7 @@ You can use any [authenticator](/docs/reference/access-authn-authz/authenticatio
 
 为了让启动引导的 kubelet 能够连接到 kube-apiserver 并请求证书，
 它必须首先在服务器上认证自身身份。你可以使用任何一种能够对 kubelet 执行身份认证的
-[身份认证组件](/zh/docs/reference/access-authn-authz/authentication/)。
+[身份认证组件](/zh-cn/docs/reference/access-authn-authz/authentication/)。
 
 <!--
 While any authentication strategy can be used for the kubelet's initial
@@ -303,7 +303,7 @@ tokens to a group allows for great flexibility. For example, you could disable a
 particular bootstrap group's access when you are done provisioning the nodes.
 -->
 随着这个功能特性的逐渐成熟，你需要确保令牌绑定到某基于角色的访问控制（RBAC）
-策略上，从而严格限制请求（使用[启动引导令牌](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)）
+策略上，从而严格限制请求（使用[启动引导令牌](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/)）
 仅限于客户端申请提供证书。当 RBAC 被配置启用时，可以将令牌限制到某个组，
 从而提高灵活性。例如，你可以在准备节点期间禁止某特定启动引导组的访问。
 
@@ -315,7 +315,7 @@ and then issued to the individual kubelet. You can use a single token for an ent
 -->
 #### 启动引导令牌   {#bootstrap-tokens}
 
-启动引导令牌的细节在[这里](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)
+启动引导令牌的细节在[这里](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/)
 详述。启动引导令牌在 Kubernetes 集群中存储为 Secret 对象，被发放给各个 kubelet。
 你可以在整个集群中使用同一个令牌，也可以为每个节点发放单独的令牌。
 
@@ -347,7 +347,7 @@ The details for creating the secret are available [here](/docs/reference/access-
 
 If you want to use bootstrap tokens, you must enable it on kube-apiserver with the flag:
 -->
-关于创建 Secret 的进一步细节可访问[这里](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)。
+关于创建 Secret 的进一步细节可访问[这里](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/)。
 
 如果你希望使用启动引导令牌，你必须在 kube-apiserver 上使用下面的标志启用之：
 
@@ -397,7 +397,7 @@ further details.
 -->
 向 kube-apiserver 添加 `--token-auth-file=FILENAME` 标志（或许这要对 systemd
 的单元文件作修改）以启用令牌文件。参见
-[这里](/zh/docs/reference/access-authn-authz/authentication/#static-token-file)
+[这里](/zh-cn/docs/reference/access-authn-authz/authentication/#static-token-file)
 的文档以了解进一步的细节。
 
 <!--
@@ -501,7 +501,7 @@ kubelet 身份认证，很重要的一点是为控制器管理器所提供的 CA
 ```
 
 <!--
-For example:
+for example:
 -->
 例如：
 
@@ -603,7 +603,7 @@ collection.
 -->
 作为 [kube-controller-manager](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/)
 的一部分的 `csrapproving` 控制器是自动被启用的。
-该控制器使用 [`SubjectAccessReview` API](/zh/docs/reference/access-authn-authz/authorization/#checking-api-access)
+该控制器使用 [`SubjectAccessReview` API](/zh-cn/docs/reference/access-authn-authz/authorization/#checking-api-access)
 来确定给定用户是否被授权请求 CSR，之后基于鉴权结果执行批复操作。
 为了避免与其它批复组件发生冲突，内置的批复组件不会显式地拒绝任何 CSRs。
 该组件仅是忽略未被授权的请求。

content/zh-cn/docs/reference/access-authn-authz/webhook.md

@@ -15,13 +15,16 @@ weight: 95
 -->
 
 <!-- overview -->
+
 <!--
 A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen.
 -->
-WebHook 是一种 HTTP 回调：某些条件下触发的 HTTP POST 请求；通过 HTTP POST 发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL。
+WebHook 是一种 HTTP 回调：某些条件下触发的 HTTP POST 请求；通过 HTTP POST
+发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL。
 
 
 <!-- body -->
+
 <!--
 When specified, mode `Webhook` causes Kubernetes to query an outside REST
 service when determining user privileges.
@@ -37,14 +40,16 @@ service when determining user privileges.
 Mode `Webhook` requires a file for HTTP configuration, specify by the
 `--authorization-webhook-config-file=SOME_FILENAME` flag.
 -->
-`Webhook` 模式需要一个 HTTP 配置文件，通过 `--authorization-webhook-config-file=SOME_FILENAME` 的参数声明。
+`Webhook` 模式需要一个 HTTP 配置文件，通过
+`--authorization-webhook-config-file=SOME_FILENAME` 的参数声明。
 
 <!--
 The configuration file uses the [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
 file format. Within the file "users" refers to the API Server webhook and
 "clusters" refers to the remote service.
 -->
-配置文件的格式使用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。
+配置文件的格式使用
+[kubeconfig](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。
 在该文件中，“users” 代表着 API 服务器的 webhook，而 “cluster” 代表着远程服务。
 
 <!--
@@ -135,7 +140,8 @@ compatibility promises for beta objects and check the "apiVersion" field of the
 request to ensure correct deserialization. Additionally, the API Server must
 enable the `authorization.k8s.io/v1beta1` API extensions group (`--runtime-config=authorization.k8s.io/v1beta1=true`).
 -->
-需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都遵从[版本兼容规则](/zh/docs/concepts/overview/kubernetes-api/)。
+需要注意的是 webhook API 对象与其他 Kubernetes API
+对象一样都同样都遵从[版本兼容规则](/zh-cn/docs/concepts/overview/kubernetes-api/)。
 实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段能被正确地反序列化。
 此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--runtime-config=authorization.k8s.io/v1beta1=true`)。
 
@@ -267,5 +273,6 @@ to the REST api.
 For further documentation refer to the authorization.v1beta1 API objects and
 [webhook.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go).
 -->
-更多信息可以参考 authorization.v1beta1 API 对象和 [webhook.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go)。
+更多信息可以参考 authorization.v1beta1 API 对象和
+[webhook.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go)。
 

content/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler.md

@@ -19,14 +19,14 @@ each Pod in the scheduling queue according to constraints and available
 resources. The scheduler then ranks each valid Node and binds the Pod to a
 suitable Node. Multiple different schedulers may be used within a cluster;
 kube-scheduler is the reference implementation.
-See [scheduling](https://kubernetes.io/docs/concepts/scheduling-eviction/)
+See [scheduling](/docs/concepts/scheduling-eviction/)
 for more information about scheduling and the kube-scheduler component.
 -->
 Kubernetes 调度器是一个控制面进程，负责将 Pods 指派到节点上。
 调度器基于约束和可用资源为调度队列中每个 Pod 确定其可合法放置的节点。
 调度器之后对所有合法的节点进行排序，将 Pod 绑定到一个合适的节点。
 在同一个集群中可以使用多个不同的调度器；kube-scheduler 是其参考实现。
-参阅[调度](/zh/docs/concepts/scheduling-eviction/)以获得关于调度和
+参阅[调度](/zh-cn/docs/concepts/scheduling-eviction/)以获得关于调度和
 kube-scheduler 组件的更多信息。
 
 ```

content/zh-cn/docs/reference/glossary/affinity.md

@@ -2,7 +2,7 @@
 title: 亲和性（Affinity）
 id: affinity
 date: 2019-01-11
-full_link: zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity
+full_link: /zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity
 short_description: >
      调度程序用于确定在何处放置 Pods（亲和性）的规则
 aka: