[zh] fix links in concept section

2020-08-12 19:26:12 +08:00
parent 50007b21d2
commit 11cc9e007a
29 changed files with 82 additions and 82 deletions
@@ -97,7 +97,7 @@ API 通常用于托管的 Kubernetes 服务和受控的 Kubernetes 安装环境
 这些 API 是声明式的，与 Pod 这类其他 Kubernetes 资源遵从相同的约定，所以
 新的集群配置是可复用的，并且可以当作应用程序来管理。
 此外，对于稳定版本的 API 而言，它们与其他 Kubernetes API 一样，采纳的是
-一种[预定义的支持策略](/zh/docs/reference/using-api/deprecation-policy/)。
+一种[预定义的支持策略](/docs/reference/using-api/deprecation-policy/)。
 出于以上原因，在条件允许的情况下，基于 API 的方案应该优先于*配置文件*和*参数标志*。

 <!--
@@ -259,7 +259,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/

 不要使用自定义资源来充当应用、用户或者监控数据的数据存储。

-关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
+关于自定义资源的更多信息，可参见[自定义资源概念指南](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。

 <!--
 ### Combining New APIs with Automation
@@ -307,7 +307,7 @@ Kubernetes has several built-in authentication methods that it supports. It can
 Kubernetes 提供若干内置的身份认证方法。
 它也可以运行在某中身份认证代理的后面，并且可以将来自鉴权头部的令牌发送到
 某个远程服务（Webhook）来执行验证操作。
-所有这些方法都在[身份认证文档](/zh/docs/reference/access-authn-authz/authentication/)
+所有这些方法都在[身份认证文档](/docs/reference/access-authn-authz/authentication/)
 中详细论述。

 <!--
@@ -319,11 +319,11 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
 -->
 ### 身份认证    {#authentication}

-[身份认证](/zh/docs/reference/access-authn-authz/authentication/)负责将所有请求中
+[身份认证](/docs/reference/access-authn-authz/authentication/)负责将所有请求中
 的头部或证书映射到发出该请求的客户端的用户名。

 Kubernetes 提供若干种内置的认证方法，以及
-[认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
+[认证 Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
 方法以备内置方法无法满足你的要求。

 <!--
@@ -443,7 +443,7 @@ 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/)
+* 进一步了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 * 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
 * 进一步了解基础设施扩展
  * [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
@@ -91,6 +91,6 @@ to disable the timeout restriction. This deprecated feature gate will be removed
  了解如何在自己的环境中启用聚合器。
 * 接下来，了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)，
  开始使用聚合层。
-* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
+* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
 * 阅读 [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) 的规范

@@ -58,10 +58,10 @@ to advertise that the node has 2 “Foo” devices installed and available.
 -->
 设备插件可以通过此 gRPC 服务在 kubelet 进行注册。在注册期间，设备插件需要发送下面几样内容：
  
-* 设备插件的 Unix 套接字。
+* 设备插件的 Unix 套接字。s
 * 设备插件的 API 版本。
 * `ResourceName` 是需要公布的。这里 `ResourceName` 需要遵循
-  [扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-container/#extended-resources)，
+  [扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources)，
  类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。）

 成功注册后，设备插件就向 kubelet 发送他所管理的设备列表，然后 kubelet 负责将这些资源发布到 API 服务器，作为 kubelet 节点状态更新的一部分。
@@ -380,6 +380,6 @@ Here are some examples of device plugin implementations:
 * 查看[调度 GPU 资源](/zh/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件
 * 查看在上如何[公布节点上的扩展资源](/zh/docs/tasks/administer-cluster/extended-resource-node/)
 * 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 
-* 学习[拓扑管理器](/zh/docs/tasks/adminster-cluster/topology-manager/)
+* 学习[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/)


@@ -89,7 +89,7 @@ Flags and configuration files may not always be changeable in a hosted Kubernete
 它们是声明性的，并使用与其他 Kubernetes 资源（如 Pod ）相同的约定，所以新的集群配置可以重复使用，
 并以与应用程序相同的方式进行管理。
 而且，当它们变稳定后，也遵循和其他 Kubernetes API 一样的
-[支持政策](/zh/docs/reference/using-api/deprecation-policy/)。
+[支持政策](/docs/reference/using-api/deprecation-policy/)。
 出于这些原因，在合适的情况下它们优先于 *配置文件* 和 *标志* 被使用。

 <!--
@@ -243,7 +243,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/
 不要使用自定义资源作为应用、用户或者监控数据的数据存储。

 有关自定义资源的更多信息，请查看
-[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
+[自定义资源概念指南](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。

 <!--
 ### Combining New APIs with Automation
@@ -288,7 +288,7 @@ Kubernetes has several built-in authentication methods that it supports. It can

 Kubernetes 有几个它支持的内置认证方法。它还可以位于身份验证代理之后，并将 Authorziation 头部
 中的令牌发送给远程服务（webhook）进行验证。所有这些方法都在
-[身份验证文档](/zh/docs/reference/access-authn-authz/authentication/)中介绍。
+[身份验证文档](/docs/reference/access-authn-authz/authentication/)中介绍。

 <!--
 ### Authentication
@@ -299,11 +299,11 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
 -->
 ### 身份认证  {#authentication}

-[身份认证](/zh/docs/reference/access-authn-authz/authentication/)
+[身份认证](/docs/reference/access-authn-authz/authentication/)
 将所有请求中的头部字段或证书映射为发出请求的客户端的用户名。

 Kubernetes 提供了几种内置的身份认证方法，如果这些方法不符合你的需求，可以使用
-[身份认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。
+[身份认证 Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。

 <!--
 ### Authorization
@@ -420,7 +420,7 @@ 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/)
+* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 * 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
 * 详细了解基础设施扩展
  * [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
@@ -20,7 +20,7 @@ Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-con
 -->

 Operator 是 Kubernetes 的扩展软件，它利用
-[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。
+[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。
 Operator 遵循 Kubernetes 的理念，特别是在[控制回路](/zh/docs/concepts/#kubernetes-control-plane)方面。


@@ -66,7 +66,7 @@ Kubernetes 为自动化而生。无需任何修改，您即可以从 Kubernetes

 Kubernetes {{< glossary_tooltip text="控制器" term_id="controller" >}} 使您无需修改 Kubernetes 自身的代码，即可以扩展集群的行为。
 Operator 是 Kubernetes API 的客户端，充当
-[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)的控制器。
+[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)的控制器。

 <!--
 ## An example Operator {#example}
@@ -212,7 +212,7 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
 * Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
 -->

-* 详细了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 * 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合您的 Operator
 * 借助已有的工具来编写您自己的 Operator，例如：
  * [KUDO](https://kudo.dev/) (Kubernetes 通用声明式 Operator)