Merge pull request #24066 from gaoguangze111/update-link-authorization

Update link in page authorization

content/zh/docs/reference/access-authn-authz/abac.md

@@ -73,7 +73,7 @@ properties:
 
 基于 `ABAC` 模式，可以这样指定策略文件 `--authorization-policy-file=SOME_FILENAME`。
 
-此文件格式是 [JSON Lines](http://jsonlines.org/)，不应存在封闭的列表或映射，每行一个映射。
+此文件格式是 [JSON Lines](https://jsonlines.org/)，不应存在封闭的列表或映射，每行一个映射。
 
 每一行都是一个策略对象，策略对象是具有以下属性的映射：
 
@@ -270,7 +270,7 @@ system:serviceaccount:<namespace>:<serviceaccountname>
 
 -->
 
-[完整文件示例](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
+[完整文件示例](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
 
 ## 服务帐户的快速说明
 
@@ -310,6 +310,3 @@ system:serviceaccount:<namespace>:default
 ```
 
 需要重新启动 apiserver 以获取新的策略行。
-
-
-

content/zh/docs/reference/access-authn-authz/admission-controllers.md

@@ -48,7 +48,7 @@ webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#a
 which are configured in the API.
 -->
 
-准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API 服务器的请求。控制器由下面的[列表](#what-does-each-admission-controller-do)组成，并编译进 `kube-apiserver` 二进制文件，并且只能由集群管理员配置。在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。它们根据 API 中的配置，分别执行变更和验证[准入控制 webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。
+准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API 服务器的请求。控制器由下面的[列表](#what-does-each-admission-controller-do)组成，并编译进 `kube-apiserver` 二进制文件，并且只能由集群管理员配置。在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。它们根据 API 中的配置，分别执行变更和验证[准入控制 webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。
 
 
 <!--
@@ -233,7 +233,7 @@ See [persistent volume](/docs/concepts/storage/persistent-volumes/) documentatio
 storage classes and how to mark a storage class as default.
 -->
 
-关于持久化卷和存储类，以及如何将存储类标记为默认，请参见[持久化卷](/docs/concepts/storage/persistent-volumes/)。
+关于持久化卷和存储类，以及如何将存储类标记为默认，请参见[持久化卷](/zh/docs/concepts/storage/persistent-volumes/)。
 
 ### DefaultTolerationSeconds {#defaulttolerationseconds}
 
@@ -400,7 +400,7 @@ add these tolerations.
 
 该插件有助于创建可扩展资源的专用节点。
 如果运营商想创建可扩展资源的专用节点（如 GPU、FPGA 等），
-那他们应该以扩展资源名称作为键名，[为节点设置污点](/docs/concepts/configuration/taint-and-toleration/#example-use-cases)。
+那他们应该以扩展资源名称作为键名，[为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
 如果启用了该准入控制器，会将此类污点的容忍自动添加到请求扩展资源的 Pod 中，用户不必再手动添加这些容忍。
 
 ### ImagePolicyWebhook {#imagepolicywebhook}
@@ -510,7 +510,7 @@ plugins:
 The ImagePolicyWebhook config file must reference a [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) formatted file which sets up the connection to the backend. It is required that the backend communicate over TLS.
 -->
 
-ImagePolicyWebhook 的配置文件必须引用 [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 格式的文件，该文件设置了到后端的连接，要求后端使用 TLS 进行通信。
+ImagePolicyWebhook 的配置文件必须引用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 格式的文件，该文件设置了到后端的连接，要求后端使用 TLS 进行通信。
 
 <!--
 The kubeconfig file's cluster field must point to the remote service, and the user field must contain the returned authorizer.
@@ -555,7 +555,7 @@ users:
 For additional HTTP configuration, refer to the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) documentation.
 -->
 
-HTTP 更多的配置，请参阅 [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 文档。
+HTTP 更多的配置，请参阅 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档。
 
 <!--
 #### Request Payloads
@@ -688,7 +688,7 @@ applies a 0.1 CPU requirement to all Pods in the `default` namespace.
 See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
 -->
 
-请查看 [limitRange 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) 和 [Limit Range 例子](/docs/tasks/configure-pod-container/limit-range/)了解更多细节。
+请查看 [limitRange 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) 和 [Limit Range 例子](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)了解更多细节。
 
 ### MutatingAdmissionWebhook {#mutatingadmissionwebhook} 
 {{< feature-state for_k8s_version="v1.13" state="beta" >}}
@@ -859,7 +859,7 @@ Starting from 1.11, this admission controller is disabled by default.
 该准入控制器会自动将区（region）或区域（zone）标签附加到由云提供商（如 GCE、AWS）定义的 PersistentVolumes 中。
 这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。
 如果准入控制器不支持为 PersistentVolumes 自动添加标签，那你可能需要手动添加标签，以防止 Pod 挂载其他区域的卷。
-PersistentVolumeLabel 已被废弃，标记持久卷已由[云管理控制器](/docs/tasks/administer-cluster/running-cloud-controller/)接管。
+PersistentVolumeLabel 已被废弃，标记持久卷已由[云管理控制器](/zh/docs/tasks/administer-cluster/running-cloud-controller/)接管。
 从 1.11 开始，默认情况下禁用此准入控制器。
 
 ### PodNodeSelector {#podnodeselector}
@@ -1012,7 +1012,7 @@ allowVolumeExpansion: true
 For more information about persistent volume claims, see [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
 -->
 
-关于持久化卷申领的更多信息，请参见 [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
+关于持久化卷申领的更多信息，请参见 [PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
 
 ### PodPreset {#podpreset}
 
@@ -1044,7 +1044,7 @@ extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`).
 See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/)
 for more information.
 -->
-查看 [Pod 安全策略文档](/docs/concepts/policy/pod-security-policy/)了解更多细节。
+查看 [Pod 安全策略文档](/zh/docs/concepts/policy/pod-security-policy/)了解更多细节。
 
 ### PodTolerationRestriction {#podtolerationrestriction}
 
@@ -1101,7 +1101,7 @@ objects in your Kubernetes deployment, you MUST use this admission controller to
 <!--
 See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details.
 -->
-请查看 [resourceQuota 设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md)和 [Resource Quota 例子](/docs/concepts/policy/resource-quotas/)了解更多细节。
+请查看 [resourceQuota 设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md)和 [Resource Quota 例子](/zh/docs/concepts/policy/resource-quotas/)了解更多细节。
 
 
 <!--
@@ -1117,17 +1117,17 @@ for more information.
 ### 容器运行时类 {#runtimeclass} 
 {{< feature-state for_k8s_version="v1.16" state="alpha" >}}
 
-[容器运行时类](/docs/concepts/containers/runtime-class/)定义描述了与运行 Pod 相关的开销。此准入控制器将相应地设置 pod.Spec.Overhead 字段。
+[容器运行时类](/zh/docs/concepts/containers/runtime-class/)定义描述了与运行 Pod 相关的开销。此准入控制器将相应地设置 pod.Spec.Overhead 字段。
 
-详情请参见 [Pod 开销](/docs/concepts/configuration/pod-overhead/)。
+详情请参见 [Pod 开销](/zh/docs/concepts/configuration/pod-overhead/)。
 
 ### SecurityContextDeny {#securitycontextdeny}
 
 <!--
 This admission controller will deny any pod that attempts to set certain escalating [SecurityContext](/docs/user-guide/security-context) fields. This should be enabled if a cluster doesn't utilize [pod security policies](/docs/user-guide/pod-security-policy) to restrict the set of values a security context can take.
 -->
-该准入控制器将拒绝任何试图设置特定提升 [SecurityContext](/docs/user-guide/security-context) 字段的 pod。
+该准入控制器将拒绝任何试图设置特定提升 [SecurityContext](/zh/docs/tasks/configure-pod-container/security-context/) 字段的 pod。
-如果集群没有使用 [pod 安全策略](/docs/user-guide/pod-security-policy)来限制安全上下文所能获取的值集，那么应该启用这个功能。
+如果集群没有使用 [pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)来限制安全上下文所能获取的值集，那么应该启用这个功能。
 
 ### ServiceAccount {#serviceaccount}
 
@@ -1135,7 +1135,7 @@ This admission controller will deny any pod that attempts to set certain escalat
 This admission controller implements automation for [serviceAccounts](/docs/user-guide/service-accounts).
 We strongly recommend using this admission controller if you intend to make use of Kubernetes `ServiceAccount` objects.
 -->
-该准入控制器实现了 [serviceAccounts](/docs/user-guide/service-accounts) 的自动化。
+该准入控制器实现了 [serviceAccounts](/zh/docs/tasks/configure-pod-container/configure-service-account/) 的自动化。
 如果您打算使用 Kubernetes 的 ServiceAccount 对象，我们强烈建议您使用这个准入控制器。
 
 ### StorageObjectInUseProtection
@@ -1143,7 +1143,7 @@ We strongly recommend using this admission controller if you intend to make use
 <!--
 The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information.
 -->
-`StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或 `kubernetes.io/pv-protection` finalizers 添加到新创建的持久化卷声明（PVC）或持久化卷（PV）中。 如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers，否则 PVC/PV 不会被删除。有关更多详细信息，请参考[保护使用中的存储对象](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。
+`StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或 `kubernetes.io/pv-protection` finalizers 添加到新创建的持久化卷声明（PVC）或持久化卷（PV）中。 如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers，否则 PVC/PV 不会被删除。有关更多详细信息，请参考[保护使用中的存储对象](/zh/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。
 
 ### TaintNodesByCondition {#taintnodesbycondition} 
 {{< feature-state for_k8s_version="v1.12" state="beta" >}}
@@ -1189,7 +1189,7 @@ Yes. For Kubernetes version 1.10 and later, the recommended admission controller
 -->
 ## 有推荐的准入控制器吗？
 
-有，对于 Kubernetes 1.10 以上的版本，推荐使用的准入控制器默认情况下都处于启用状态（查看[这里](/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。
+有，对于 Kubernetes 1.10 以上的版本，推荐使用的准入控制器默认情况下都处于启用状态（查看[这里](/zh/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。
 因此您无需显式指定它们。您可以使用 `--enable-admission-plugins` 标志（ **顺序不重要** ）来启用默认设置以外的其他准入控制器。
 
 {{< note >}}
@@ -1227,5 +1227,3 @@ in the mutating phase.
 admission controllers ran in the exact order specified.
 -->
     对于更早期版本，没有验证和变更的概念，并且准入控制器按照指定的确切顺序运行。
-
-

content/zh/docs/reference/access-authn-authz/authentication.md

@@ -66,7 +66,7 @@ for more details about this.
 使用证书中的 'subject' 的通用名称（Common Name）字段（例如，"/CN=bob"）来
 确定用户名。接下来，基于角色访问控制（RBAC）子系统会确定用户是否有权针对
 某资源执行特定的操作。进一步的细节可参阅
-[证书请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)
+[证书请求](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)
 下普通用户主题。
 
 <!--
@@ -814,7 +814,7 @@ The configuration file uses the [kubeconfig](/docs/concepts/configuration/organi
 file format. Within the file, `clusters` refers to the remote service and
 `users` refers to the API server webhook. An example would be:
 -->
-配置文件使用 [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+配置文件使用 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 文件的格式。文件中，`clusters` 指代远程服务，`users` 指代远程 API 服务
 Webhook。下面是一个例子：
 
@@ -1561,4 +1561,3 @@ RFC3339 timestamp. Presence or absence of an expiry has the following impact:
   }
 }
 ```
-

content/zh/docs/reference/access-authn-authz/authorization.md

@@ -29,7 +29,7 @@ cloud-provider-wide access control systems which may handle other APIs besides
 the Kubernetes API. -->
 
 在 Kubernetes 中，您必须在授权（授予访问权限）之前进行身份验证（登录），有关身份验证的信息，
-请参阅 [访问控制概述](/docs/reference/access-authn-authz/controlling-access/).
+请参阅 [访问控制概述](/zh/docs/reference/access-authn-authz/controlling-access/).
 
 Kubernetes 期望 REST API 请求中常见的属性。
 这意味着 Kubernetes 授权适用于现有的组织范围或云提供商范围的访问控制系统，
@@ -85,12 +85,12 @@ Kubernetes 仅审查以下 API 请求属性：
  * **extra** - 由身份验证层提供的任意字符串键到字符串值的映射。
  * **API** - 指示请求是否针对 API 资源。
  * **Request path** - 各种非资源端点的路径，如 `/api` 或 `/healthz`。
- * **API request verb** - API 动词 `get`，`list`，`create`，`update`，`patch`，`watch`，`proxy`，`redirect`，`delete` 和 `deletecollection` 用于资源请求。要确定资源 API 端点的请求动词，请参阅[确定请求动词](/docs/reference/access-authn-authz/authorization/#determine-whether-a-request-is-allowed-or-denied)。
+ * **API request verb** - API 动词 `get`，`list`，`create`，`update`，`patch`，`watch`，`proxy`，`redirect`，`delete` 和 `deletecollection` 用于资源请求。要确定资源 API 端点的请求动词，请参阅[确定请求动词](/zh/docs/reference/access-authn-authz/authorization/#determine-whether-a-request-is-allowed-or-denied)。
  * **HTTP request verb** - HTTP 动词 `get`，`post`，`put` 和 `delete` 用于非资源请求。
  * **Resource** - 正在访问的资源的 ID 或名称（仅限资源请求） - 对于使用 `get`，`update`，`patch` 和 `delete` 动词的资源请求，您必须提供资源名称。
  * **Subresource** - 正在访问的子资源（仅限资源请求）。
  * **Namespace** - 正在访问的对象的名称空间（仅适用于命名空间资源请求）。
- * **API group** - 正在访问的 API 组（仅限资源请求）。空字符串表示[核心 API 组](/docs/concepts/overview/kubernetes-api/)。
+ * **API group** - 正在访问的 API 组（仅限资源请求）。空字符串表示[核心 API 组](/zh/docs/concepts/overview/kubernetes-api/)。
 
 <!--
 ## Determine the Request Verb
@@ -128,9 +128,9 @@ DELETE    | delete (单个资源)，deletecollection (资源集合)
 
 Kubernetes 有时使用专门的动词检查授权以获得额外的权限。例如：
 
-* [Pod 安全策略](/docs/concepts/policy/pod-security-policy/) 检查 `policy` API 组中 `podsecuritypolicies` 资源的 `use` 动词的授权。
+* [Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/) 检查 `policy` API 组中 `podsecuritypolicies` 资源的 `use` 动词的授权。
-* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) 检查 `rbac.authorization.k8s.io` API 组中 `roles` 和 `clusterroles` 资源的 `bind` 动词的授权。
+* [RBAC](/zh/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) 检查 `rbac.authorization.k8s.io` API 组中 `roles` 和 `clusterroles` 资源的 `bind` 动词的授权。
-* [认证](/docs/reference/access-authn-authz/authentication/) layer 检查核心 API 组中 `users`，`groups` 和 `serviceaccounts` 的 `impersonate` 动词的授权，以及 `authentication.k8s.io` API 组中的 `userextras`。
+* [认证](/zh/docs/reference/access-authn-authz/authentication/) layer 检查核心 API 组中 `users`，`groups` 和 `serviceaccounts` 的 `impersonate` 动词的授权，以及 `authentication.k8s.io` API 组中的 `userextras`。
 
 <!--
 ## Authorization Modules
@@ -143,12 +143,12 @@ Kubernetes 有时使用专门的动词检查授权以获得额外的权限。例
  -->
 
 ## 授权模块
- * **Node** - 一个专用授权程序，根据计划运行的 pod 为 kubelet 授予权限。了解有关使用节点授权模式的更多信息，请参阅[节点授权](/docs/reference/access-authn-authz/node/).
+ * **Node** - 一个专用授权程序，根据计划运行的 pod 为 kubelet 授予权限。了解有关使用节点授权模式的更多信息，请参阅[节点授权](/zh/docs/reference/access-authn-authz/node/).
- * **ABAC** - 基于属性的访问控制（ABAC）定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅 [ABAC 模式](/docs/reference/access-authn-authz/abac/)。
+ * **ABAC** - 基于属性的访问控制（ABAC）定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅 [ABAC 模式](/zh/docs/reference/access-authn-authz/abac/)。
- * **RBAC** - 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力，例如查看，创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅 [RBAC 模式](/docs/reference/access-authn-authz/rbac/)。
+ * **RBAC** - 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力，例如查看，创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅 [RBAC 模式](/zh/docs/reference/access-authn-authz/rbac/)。
    * 当指定的 RBAC（基于角色的访问控制）使用 `rbac.authorization.k8s.io` API 组来驱动授权决策时，允许管理员通过 Kubernetes API 动态配置权限策略。
    * 要启用 RBAC，请使用 `--authorization-mode = RBAC` 启动 apiserver 。
- * **Webhook** - WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST；通过 HTTP POST 进行简单的事件通知。实现 WebHook 的 Web 应用程序会在发生某些事情时将消息发布到 URL。要了解有关使用 Webhook 模式的更多信息，请参阅 [Webhook 模式](/docs/reference/access-authn-authz/webhook/)。
+ * **Webhook** - WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST；通过 HTTP POST 进行简单的事件通知。实现 WebHook 的 Web 应用程序会在发生某些事情时将消息发布到 URL。要了解有关使用 Webhook 模式的更多信息，请参阅 [Webhook 模式](/zh/docs/reference/access-authn-authz/webhook/)。
 
 <!--
 #### Checking API Access
@@ -173,7 +173,7 @@ no
 Administrators can combine this with [user impersonation](/docs/reference/access-authn-authz/authentication/#user-impersonation)
 to determine what action other users can perform.
 -->
-管理员可以将此与[用户模拟](/docs/reference/access-authn-authz/authentication/#user-impersonation)结合使用，以确定其他用户可以执行的操作。
+管理员可以将此与[用户模拟](/zh/docs/reference/access-authn-authz/authentication/#user-impersonation)结合使用，以确定其他用户可以执行的操作。
 
 ```bash
 $ kubectl auth can-i list secrets --namespace dev --as dave
@@ -300,5 +300,5 @@ mode.
 * To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/).
 * To learn more about Admission Control, see [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/).
 -->
-* 要了解有关身份验证的更多信息，请参阅 **身份验证** [控制对 Kubernetes API 的访问](/docs/reference/access-authn-authz/controlling-access/)。
+* 要了解有关身份验证的更多信息，请参阅 **身份验证** [控制对 Kubernetes API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)。
-* 要了解有关准入控制的更多信息，请参阅 [使用准入控制器](/docs/reference/access-authn-authz/admission-controllers/)。
+* 要了解有关准入控制的更多信息，请参阅 [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)。

content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md

@@ -9,9 +9,9 @@ title: 使用启动引导令牌（Bootstrap Tokens）认证
 ## 概述
 
 启动引导令牌是一种简单的持有者令牌（Bearer Token），这种令牌是在新建集群或者在现有集群中添加新节点时使用的。
-它被设计成能够支持 [`kubeadm`](/docs/admin/kubeadm/)，但是也可以被用在其他的案例中以便用户在
+它被设计成能够支持 [`kubeadm`](/zh/docs/reference/setup-tools/kubeadm/)，但是也可以被用在其他的案例中以便用户在
 不使用 `kubeadm` 的情况下启动集群。它也被设计成可以通过 RBAC 策略，结合 [Kubelet TLS
-Bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 系统进行工作。
+Bootstrapping](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) 系统进行工作。
 
 启动引导令牌被定义成一个特定类型的 secrets(`bootstrap.kubernetes.io/token`)，并存在于
 `kube-system` 命名空间中。然后这些 secrets 会被 API 服务器上的启动引导的认证器读取。

content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md

@@ -18,7 +18,7 @@ In addition to [compiled-in admission plugins](/docs/reference/access-authn-auth
 admission plugins can be developed as extensions and run as webhooks configured at runtime.
 This page describes how to build, configure, use, and monitor admission webhooks.
 -->
-除了[内置的 admission 插件](/docs/reference/access-authn-authz/admission-controllers/)，admission 插件可以作为扩展独立开发，并以运行时所配置的 webhook 的形式运行。
+除了[内置的 admission 插件](/zh/docs/reference/access-authn-authz/admission-controllers/)，admission 插件可以作为扩展独立开发，并以运行时所配置的 webhook 的形式运行。
 此页面描述了如何构建、配置、使用和监视 admission webhook。
 
 
@@ -37,7 +37,7 @@ and
 Mutating admission Webhooks are invoked first, and can modify objects sent to the API server to enforce custom defaults.
 -->
 Admission webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。
-可以定义两种类型的 admission webhook，即 [validating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) 和 [mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)。
+可以定义两种类型的 admission webhook，即 [validating admission webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) 和 [mutating admission webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)。
 Mutating admission webhook 会先被调用。它们可以更改发送到 API 服务器的对象以执行自定义的设置默认值操作。
 
 <!--
@@ -67,7 +67,7 @@ In the following, we describe how to quickly experiment with admission webhooks.
 ### 尝试 admission webhook
 
 admission webhook 本质上是集群控制平面的一部分。您应该非常谨慎地编写和部署它们。
-如果您打算编写或者部署生产级 admission webhook，请阅读[用户指南](/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server)以获取相关说明。
+如果您打算编写或者部署生产级 admission webhook，请阅读[用户指南](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server)以获取相关说明。
 在下文中，我们将介绍如何快速试验 admission webhook。
 
 <!--
@@ -88,7 +88,7 @@ admission webhook 本质上是集群控制平面的一部分。您应该非常
 * 确保 Kubernetes 集群版本至少为 v1.16（以便使用 `admissionregistration.k8s.io/v1` API） 或者 v1.9 （以便使用 `admissionregistration.k8s.io/v1beta1` API）。
 
 * 确保启用 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 控制器。
-  [这里](/docs/reference/access-authn-authz/admission-controllers/#is-there-a-recommended-set-of-admission-controllers-to-use)
+  [这里](/zh/docs/reference/access-authn-authz/admission-controllers/#is-there-a-recommended-set-of-admission-controllers-to-use)
   是一组推荐的 admission 控制器，通常可以启用。
 
 * 确保启用了 `admissionregistration.k8s.io/v1beta1` API。
@@ -748,7 +748,7 @@ For `patchType: JSONPatch`, the `patch` field contains a base64-encoded array of
 当允许请求时，mutating admission webhook 也可以选择修改传入的对象。
 这是通过在响应中使用 `patch` 和 `patchType` 字段来完成的。
 当前唯一支持的 `patchType` 是 `JSONPatch`。
-有关更多详细信息，请参见 [JSON patch](http://jsonpatch.com/)。
+有关更多详细信息，请参见 [JSON patch](https://jsonpatch.com/)。
 对于 `patchType: JSONPatch`，`patch` 字段包含一个以 base64 编码的 JSON patch 操作数组。
 
 <!--
@@ -1060,7 +1060,7 @@ webhooks:
 <!--
 See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for more examples of label selectors.
 -->
-有关标签选择器的更多示例，请参见[标签](/docs/concepts/overview/working-with-objects/labels)。
+有关标签选择器的更多示例，请参见[标签](/zh/docs/concepts/overview/working-with-objects/labels)。
 
 <!--
 ### Matching requests: namespaceSelector
@@ -1187,7 +1187,7 @@ webhooks:
 <!--
 See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for more examples of label selectors.
 -->
-有关标签选择器的更多示例，请参见[标签](/docs/concepts/overview/working-with-objects/labels)。
+有关标签选择器的更多示例，请参见[标签](/zh/docs/concepts/overview/working-with-objects/labels)。
 
 <!--
 ### Matching requests: matchPolicy
@@ -1793,7 +1793,7 @@ capturing if a request object is mutated by the invocation, and optionally gener
 patch from the webhook admission response. The annotations are set in the audit event for given request on given stage of
 its execution, which is then pre-processed according to a certain policy and written to a backend.
 -->
-在 v1.16+ 中，kube-apiserver 针对每个 mutating webhook 调用执行[审计](/docs/tasks/debug-application-cluster/audit/)操作。
+在 v1.16+ 中，kube-apiserver 针对每个 mutating webhook 调用执行[审计](/zh/docs/tasks/debug-application-cluster/audit/)操作。
 每个调用都会生成一个审计注解，记述请求对象是否发生改变，可选地还可以根据 webhook 的准入响应生成一个注解，记述所应用的修补。
 针对给定请求的给定执行阶段，注解被添加到审计事件中，然后根据特定策略进行预处理并写入后端。
 
@@ -2173,5 +2173,3 @@ plane, exclude the `kube-system` namespace from being intercepted using a
 `kube-system` 命名空间包含由 Kubernetes 系统创建的对象，例如用于控制平面组件的服务账号，诸如 `kube-dns` 之类的 Pod 等。
 意外更改或拒绝 `kube-system` 命名空间中的请求可能会导致控制平面组件停止运行或者导致未知行为发生。
 如果您的 admission webhook 不想修改 Kubernetes 控制平面的行为，请使用 [`namespaceSelector`](#matching-requests-namespaceselector) 避免拦截 `kube-system` 命名空间。
-
-

content/zh/docs/reference/access-authn-authz/node.md

@@ -88,7 +88,7 @@ have the minimal set of permissions required to operate correctly.
 -->
 
 为了获得节点鉴权器的授权，kubelet 必须使用一个凭证以表示它在 `system:nodes` 组中，用户名为 `system:node:<nodeName>`。
-上述的组名和用户名格式要与 [kubelet TLS 启动引导](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)过程中为每个 kubelet 创建的标识相匹配。
+上述的组名和用户名格式要与 [kubelet TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)过程中为每个 kubelet 创建的标识相匹配。
 <!--
 In order to be authorized by the Node authorizer, kubelets must use a credential that identifies them as
 being in the `system:nodes` group, with a username of `system:node:<nodeName>`.
@@ -101,7 +101,7 @@ This group and user name format match the identity created for each kubelet as p
 To enable the Node authorizer, start the apiserver with `--authorization-mode=Node`.
 -->
 
-要限制 kubelet 具有写入权限的 API 对象，请使用 `--enable-admission-plugins=...,NodeRestriction,...` 启动 apiserver，从而启用 [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers#NodeRestriction) 准入插件。
+要限制 kubelet 具有写入权限的 API 对象，请使用 `--enable-admission-plugins=...,NodeRestriction,...` 启动 apiserver，从而启用 [NodeRestriction](/zh/docs/reference/access-authn-authz/admission-controllers#NodeRestriction) 准入插件。
 <!--
 To limit the API objects kubelets are able to write, enable the [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers#NodeRestriction) admission plugin by starting the apiserver with `--enable-admission-plugins=...,NodeRestriction,...`
  -->
@@ -150,7 +150,7 @@ since the default node identifier implementation would not consider that a node
 ### Upgrades from previous versions using RBAC
 -->
 
-升级的 1.7 之前的使用 [RBAC](/docs/reference/access-authn-authz/rbac/) 的集群将继续按原样运行，因为 `system:nodes` 组绑定已经存在。
+升级的 1.7 之前的使用 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) 的集群将继续按原样运行，因为 `system:nodes` 组绑定已经存在。
 <!--
 Upgraded pre-1.7 clusters using [RBAC](/docs/reference/access-authn-authz/rbac/) will continue functioning as-is because the `system:nodes` group binding will already exist.
 -->
@@ -177,7 +177,7 @@ to limit node access to the API, that can be done non-disruptively:
 ### RBAC Node Permissions
 -->
 
-在 1.6 版本中，当使用 [RBAC 鉴权模式](/docs/reference/access-authn-authz/rbac/) 时，`system:nodes` 集群角色会被自动绑定到 `system:node` 组。
+在 1.6 版本中，当使用 [RBAC 鉴权模式](/zh/docs/reference/access-authn-authz/rbac/) 时，`system:nodes` 集群角色会被自动绑定到 `system:node` 组。
 <!--
 In 1.6, the `system:node` cluster role was automatically bound to the `system:nodes` group when using the [RBAC Authorization mode](/docs/reference/access-authn-authz/rbac/).
 -->
@@ -201,4 +201,3 @@ In 1.8, the binding will not be created at all.
 When using RBAC, the `system:node` cluster role will continue to be created,
 for compatibility with deployment methods that bind other users or groups to that role.
 -->
-

content/zh/docs/reference/access-authn-authz/rbac.md

@@ -721,14 +721,14 @@ to groups with the `system:serviceaccounts:` prefix.
 主体可以是组，用户或者服务账户。
 
 用户是由字符串表示，它们可以是普通的用户名，像 "alice"，或者是
-邮件格式 "bob@example.com"，或者是数字ID。由 Kubernetes 管理员配置[身份认证模块](/docs/reference/access-authn-authz/authentication/)
+邮件格式 "bob@example.com"，或者是数字ID。由 Kubernetes 管理员配置[身份认证模块](/zh/docs/reference/access-authn-authz/authentication/)
 需要的格式。RBAC 鉴权系统不对格式作任何要求，但是前缀 `system:` 是 Kubernetes 系统保留的，
 所以管理员要确保配置的用户名不能出现上述前缀格式。
 
 用户组信息是 Kubernetes 现在提供的一种身份验证模块，与用户一样，对组的字符串没有格式要求，
 只是不能使用保留的前缀 `system:` 。
 
-[服务账号](/docs/tasks/configure-pod-container/configure-service-account/) 的用户名前缀为`system:serviceaccount:`，
+[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/) 的用户名前缀为`system:serviceaccount:`，
 属于前缀为 `system:serviceaccounts:` 的用户组。
 
 <!--
@@ -1355,7 +1355,7 @@ These roles include:
 -->
 ### 控制器角色   {#controller-roles}
 
-[Kubernetes 控制器管理器](/docs/admin/kube-controller-manager/) 运行核心控制环。
+[Kubernetes 控制器管理器](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 运行核心控制环。
 当使用 `--use-service-account-credentials` 参数时, 每个控制环使用一个单独的服务账号启动。
 每个控制环都有相应的、前缀为 `system:controller:` 的角色。
 如果控制管理器启动时未设置 `--use-service-account-credentials`，
@@ -2080,7 +2080,7 @@ in the server logs, you can remove the ABAC authorizer.
 ### 平行鉴权
 
 同时运行 RBAC 和 ABAC 鉴权模式, 并指定包含
-[现有的 ABAC 策略](/docs/reference/access-authn-authz/abac/#policy-file-format) 的策略文件：
+[现有的 ABAC 策略](/zh/docs/reference/access-authn-authz/abac/#policy-file-format) 的策略文件：
 
 ```
 --authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.json
@@ -2136,5 +2136,3 @@ kubectl create clusterrolebinding permissive-binding \
   --group=system:serviceaccounts
 ```
 {{< /warning >}}
-
-

content/zh/docs/reference/access-authn-authz/service-accounts-admin.md

@@ -7,7 +7,7 @@ approvers:
 title: 管理 Service Accounts
 ---
 
-*这是一篇针对service accounts（服务账户）的集群管理员指南。  它呈现了 [User Guide to Service Accounts](/docs/user-guide/service-accounts)中的信息。*
+*这是一篇针对service accounts（服务账户）的集群管理员指南。  它呈现了 [User Guide to Service Accounts](/zh/docs/tasks/configure-pod-container/configure-service-account/)中的信息。*
 
 *对授权和用户账户的支持已在规划中，当前并不完备，为了更好地描述 service accounts，有时这些不完善的特性也会被提及。*
 
@@ -32,7 +32,7 @@ Kubernetes 区分用户账户和服务账户的概念主要基于以下原因：
 
 ### 服务账户准入控制器
 
-对 pod 的改动通过一个被称为 [Admission Controller](/docs/admin/admission-controllers) 的插件来实现。它是 apiserver 的一部分。
+对 pod 的改动通过一个被称为 [Admission Controller](/zh/docs/reference/access-authn-authz/admission-controllers/) 的插件来实现。它是 apiserver 的一部分。
 当 pod 被创建或更新时，它会同步地修改 pod。 当该插件处于激活状态 ( 在大多数发行版中都是默认的 )，当 pod 被创建或更新时它会进行以下动作：
 
   1. 如果该 pod 没有 `ServiceAccount` 设置，将其 `ServiceAccount` 设为 `default`。

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

@@ -51,7 +51,7 @@ The configuration file uses the [kubeconfig](/docs/tasks/access-application-clus
 file format. Within the file "users" refers to the API Server webhook and
 "clusters" refers to the remote service.
 -->
-配置文件的格式使用 [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。在文件中，"users" 代表着 API 服务器的 webhook，而 "cluster" 代表着远程服务。
+配置文件的格式使用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。在文件中，"users" 代表着 API 服务器的 webhook，而 "cluster" 代表着远程服务。
 
 <!--
 A configuration example which uses HTTPS client auth:
@@ -140,7 +140,7 @@ 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 对象一样都同样都服从[版本兼容规则](/docs/concepts/overview/kubernetes-api/)。实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段能被正确地反序列化。此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--runtime-config=authorization.k8s.io/v1beta1=true`)。
+需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都服从[版本兼容规则](/zh/docs/concepts/overview/kubernetes-api/)。实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段能被正确地反序列化。此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--runtime-config=authorization.k8s.io/v1beta1=true`)。
 
 <!--
 An example request body:
@@ -269,7 +269,3 @@ For further documentation refer to the authorization.v1beta1 API objects and
 [webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go).
 -->
 更多信息可以参考 authorization.v1beta1 API 对象和[webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go)。
-
-
-
-