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

2022-06-23 20:00:14 +08:00
parent e0d6f94bf6
commit 2c087454ea
24 changed files with 153 additions and 153 deletions
@@ -40,8 +40,8 @@ For general background information, read
 describes how clients can authenticate to the Kubernetes API server, and how their
 requests are authorized.
 -->
-如需了解一般背景信息，请查阅 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/)。
-[Kubernetes API 控制访问](/zh/docs/concepts/security/controlling-access/)描述了客户端如何
+如需了解一般背景信息，请查阅 [Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/)。
+[Kubernetes API 控制访问](/zh-cn/docs/concepts/security/controlling-access/)描述了客户端如何
 向 Kubernetes API 服务器进行身份认证以及他们的请求如何被鉴权。


@@ -42,7 +42,7 @@ or read on to learn about the API in general.
 Kubernetes 支持通过 **watchs** 实现高效的资源变更通知。
 Kubernetes 还提供了一致的列表操作，以便 API 客户端可以有效地缓存、跟踪和同步资源的状态。

-你可以在线查看 [API 参考](/zh/docs/reference/kubernetes-api/)，
+你可以在线查看 [API 参考](/zh-cn/docs/reference/kubernetes-api/)，
 或继续阅读以了解 API 的一般信息。

 <!--
@@ -79,11 +79,11 @@ as a permission check
 [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/)).
 -->
 大多数 Kubernetes API 资源类型都是
-[对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)：
+[对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)：
 它们代表集群上某个概念的具体实例，例如 Pod 或命名空间。
 少数 API 资源类型是 “虚拟的”，它们通常代表的是操作而非对象本身，
 例如权限检查（使用带有 JSON 编码的 `SubjectAccessReview` 主体的 POST 到 `subjectaccessreviews` 资源），
-或 Pod 的子资源 `eviction`（用于触发 [API-发起的驱逐](/zh/docs/concepts/scheduling-eviction/api-eviction/)）。
+或 Pod 的子资源 `eviction`（用于触发 [API-发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)）。

 <!--
 ### Object names
@@ -198,7 +198,7 @@ virtual resource type would be used if that becomes necessary.
 * 集群作用域的子资源：`GET /apis/GROUP/VERSION/RESOURCETYPE/NAME/SUBRESOURCE`
 * 名字空间作用域的子资源：`GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME/SUBRESOURCE`

-取决于对象是什么，每个子资源所支持的动词有所不同 - 参见 [API 文档](/zh/docs/reference/kubernetes-api/)以了解更多信息。
+取决于对象是什么，每个子资源所支持的动词有所不同 - 参见 [API 文档](/zh-cn/docs/reference/kubernetes-api/)以了解更多信息。
 跨多个资源来访问其子资源是不可能的 - 如果需要这一能力，则通常意味着需要一种
 新的虚拟资源类型了。

@@ -385,7 +385,7 @@ into many smaller chunks while preserving the consistency of the total request.
 chunk can be returned sequentially which reduces both the total size of the request and
 allows user-oriented clients to display results incrementally to improve responsiveness.
 -->
-如果你没有明确禁用 `APIListChunking` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
+如果你没有明确禁用 `APIListChunking` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
 Kubernetes API 服务器支持将单个大型集合请求分解为许多较小块的能力，同时保持总请求的一致性。

 <!--
@@ -553,7 +553,7 @@ has `kind` set to

 当你查询特定类型的 API 时，该查询返回的所有项目都属于该类型。
 例如，当你 **list** Service 对象时，集合响应的 `kind` 设置为
-[`ServiceList`](/zh/docs/reference/kubernetes-api/service-resources/service-v1/#ServiceList)；
+[`ServiceList`](/zh-cn/docs/reference/kubernetes-api/service-resources/service-v1/#ServiceList)；
 该集合中的每个项目都代表一个 Service。例如：

 ```
@@ -591,7 +591,7 @@ multiple **list** operations at the API level, `kubectl` represents
 a list of items using `kind: List`. For example:
 -->
 Kubernetes API 中定义了数十种集合类型（如 `PodList`、`ServiceList` 和 `NodeList`）。
-你可以从 [Kubernetes API](/zh/docs/reference/kubernetes-api/) 文档中获取有关每种集合类型的更多信息。
+你可以从 [Kubernetes API](/zh-cn/docs/reference/kubernetes-api/) 文档中获取有关每种集合类型的更多信息。

 一些工具，例如 `kubectl`，对于 Kubernetes 集合的表现机制与 Kubernetes API 本身略有不同。
 因为 `kubectl` 的输出可能包含来自 API 级别的多个 **list** 操作的响应，
@@ -748,7 +748,7 @@ extensions, you should make requests that specify multiple content types in the
 -->
 并非所有 API 资源类型都支持 Table 响应；
 例如，{{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}} 可能没有定义字段到表的映射，
-[扩展核心 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+[扩展核心 Kubernetes API](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
 的 APIService 可能根本不提供 Table 响应。
 如果你正在实现使用 Table 信息并且必须针对所有资源类型（包括扩展）工作的客户端，
 你应该在 `Accept` 请求头中指定多种内容类型的请求。例如：
@@ -795,7 +795,7 @@ For example:
 如果不支持你请求的媒体类型，则返回 `406 Not Acceptable` 错误。
 所有内置资源类型都支持 `application/json` 媒体类型。

-有关每个 API 支持的内容类型列表，请参阅 Kubernetes [API 参考](/zh/docs/reference/kubernetes-api/)。
+有关每个 API 支持的内容类型列表，请参阅 Kubernetes [API 参考](/zh-cn/docs/reference/kubernetes-api/)。

 例如：

@@ -1152,7 +1152,7 @@ Some values of an object are typically generated before the object is persisted.

 * `name`：如果设置了 `generateName` 字段，则 `name` 会获得一个唯一的随机名称
 * `creationTimestamp` / `deletionTimestamp`：记录对象的创建/删除时间
-* `UID`：[唯一标识](/zh/docs/concepts/overview/working-with-objects/names/#uids)对象，
+* `UID`：[唯一标识](/zh-cn/docs/concepts/overview/working-with-objects/names/#uids)对象，
  取值随机生成（非确定性）
 * `resourceVersion`：跟踪对象的持久化（存储）版本
 * 变更性准入控制器所设置的字段
@@ -1187,7 +1187,7 @@ rules:
 <!--
 See [Authorization Overview](/docs/reference/access-authn-authz/authorization/).
 -->
-参阅[鉴权概述](/zh/docs/reference/access-authn-authz/authorization/)以了解鉴权细节。
+参阅[鉴权概述](/zh-cn/docs/reference/access-authn-authz/authorization/)以了解鉴权细节。

 <!--
 ## Server Side Apply
@@ -1204,12 +1204,12 @@ client-side functionality of `kubectl apply`.
 The API verb for Server-Side Apply is **apply**.
 See [Server Side Apply](/docs/reference/using-api/server-side-apply/) for more details.
 -->
-Kubernetes 的[服务器端应用](/zh/docs/reference/using-api/server-side-apply/)功能允许控制平面跟踪新创建对象的托管字段。
+Kubernetes 的[服务器端应用](/zh-cn/docs/reference/using-api/server-side-apply/)功能允许控制平面跟踪新创建对象的托管字段。
 服务端应用为管理字段冲突提供了清晰的模式，提供了服务器端 `Apply` 和 `Update` 操作，
 并替换了 `kubectl apply` 的客户端功能。

 服务端应用的 API 动词是 **apply**。有关详细信息，
-请参阅[服务器端应用](/zh/docs/reference/using-api/server-side-apply/)。
+请参阅[服务器端应用](/zh-cn/docs/reference/using-api/server-side-apply/)。

 <!--
 ## Resource Versions
@@ -26,7 +26,7 @@ To write applications using the [Kubernetes REST API](/docs/reference/using-api/
 you do not need to implement the API calls and request/response types yourself.
 You can use a client library for the programming language you are using.
 -->
-在使用 [Kubernetes REST API](/zh/docs/reference/using-api/) 编写应用程序时，
+在使用 [Kubernetes REST API](/zh-cn/docs/reference/using-api/) 编写应用程序时，
 你并不需要自己实现 API 调用和 “请求/响应” 类型。
 你可以根据自己的编程语言需要选择使用合适的客户端库。

@@ -39,7 +39,7 @@ format to read the credentials and the API Server address.
 -->
 客户端库通常为你处理诸如身份验证之类的常见任务。
 如果 API 客户端在 Kubernetes 集群中运行，大多数客户端库可以发现并使用 Kubernetes 服务帐户进行身份验证，
-或者能够理解 [kubeconfig 文件](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+或者能够理解 [kubeconfig 文件](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
 格式来读取凭据和 API 服务器地址。

 <!--
@@ -229,9 +229,9 @@ For more information on the deprecation, see [PodSecurityPolicy Deprecation: Pas
 **policy/v1beta1** API 版本中的 PodSecurityPolicy 将不会在 v1.25 中提供，
 并且 PodSecurityPolicy 准入控制器也会被删除。

-迁移到 [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/)或[第三方准入 webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)。
-有关迁移指南，请参阅[从 PodSecurityPolicy 迁移到内置 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/)。
-有关弃用的更多信息，请参阅 [PodSecurityPolicy 弃用：过去、现在和未来](/zh/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。
+迁移到 [Pod 安全准入](/zh-cn/docs/concepts/security/pod-security-admission/)或[第三方准入 webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/)。
+有关迁移指南，请参阅[从 PodSecurityPolicy 迁移到内置 PodSecurity 准入控制器](/zh-cn/docs/tasks/configure-pod-container/migrate-from-psp/)。
+有关弃用的更多信息，请参阅 [PodSecurityPolicy 弃用：过去、现在和未来](/zh-cn/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。

 #### RuntimeClass {#runtimeclass-v125}

@@ -335,7 +335,7 @@ The **apiextensions.k8s.io/v1beta1** API version of CustomResourceDefinition is
      `spec.conversion.webhook.conversionReviewVersions`
    * `spec.versions[*].schema.openAPIV3Schema` 在创建 v1 版本的
      CustomResourceDefinition 对象时变成必需字段，并且其取值必须是一个
-      [结构化的 Schema](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema)
+      [结构化的 Schema](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema)
    * `spec.preserveUnknownFields: true` 在创建 v1 版本的 CustomResourceDefinition
      对象时不允许指定；该配置必须在 Schema 定义中使用
      `x-kubernetes-preserve-unknown-fields: true` 来设置
@@ -421,7 +421,7 @@ v1.22 版本中继续提供。
 * `certificates.k8s.io/v1` 中需要额外注意的变更：
  * 对于请求证书的 API 客户端而言：
    * `spec.signerName` 现在变成必需字段（参阅
-      [已知的 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)），
      并且通过 `certificates.k8s.io/v1` API 不可以创建签署者为
      `kubernetes.io/legacy-unknown` 的请求
    * `spec.usages` 现在变成必需字段，其中不可以包含重复的字符串值，
@@ -764,4 +764,4 @@ Note that this may use non-ideal default values. To learn more about a specific
 resource, check the Kubernetes [API reference](/docs/reference/kubernetes-api/).
 -->
 注意这种操作生成的结果中可能使用的默认值并不理想。
-要进一步了解某个特定资源，可查阅 Kubernetes [API 参考](/zh/docs/reference/kubernetes-api/)。
+要进一步了解某个特定资源，可查阅 Kubernetes [API 参考](/zh-cn/docs/reference/kubernetes-api/)。
@@ -47,7 +47,7 @@ into 3 main tracks, each of which has different policies for deprecation:
 由于 Kubernetes 是一个 API 驱动的系统，API 会随着时间推移而演化，以反映
 人们对问题空间的认识的变化。Kubernetes API 实际上是一个 API 集合，其中每个
 成员称作“API 组（API Group）”，并且每个 API 组都是独立管理版本的。
-[API 版本](/zh/docs/reference/using-api/#api-versioning)会有
+[API 版本](/zh-cn/docs/reference/using-api/#api-versioning)会有
 三类，每类有不同的废弃策略：

 <!--
@@ -169,7 +169,7 @@ This ensures beta API support covers the [maximum supported version skew of 2 re
   * **Beta API 版本必须支持 9 个月或弃用后的 3 个版本（以较长者为准）**
   * **Alpha API 版本可能会在任何版本中被删除，不另行通知**

-这确保了 beta API 支持涵盖了[最多 2 个版本的支持版本偏差](/zh/releases/version-skew-policy/)。
+这确保了 beta API 支持涵盖了[最多 2 个版本的支持版本偏差](/zh-cn/releases/version-skew-policy/)。

 {{< note >}}
 <!--
@@ -450,7 +450,7 @@ Starting in Kubernetes v1.19, making an API request to a deprecated REST API end

 1. API 响应中会包含一个 `Warning` 头部字段（如 [RFC7234 5.5 节](https://tools.ietf.org/html/rfc7234#section-5.5)所定义）；
 2. 该请求会导致对应的 
-   [审计事件](/zh/docs/tasks/debug/debug-cluster/audit/)
+   [审计事件](/zh-cn/docs/tasks/debug/debug-cluster/audit/)
   中会增加一个注解 `"k8s.io/deprecated":"true"`。
 3. `kube-apiserver` 进程的 `apiserver_requested_deprecated_apis` 度量值会被
   设置为 `1`。
@@ -35,8 +35,8 @@ The more verbose options shown below are intended to be used by human operators
 -->
 Kubernetes API 服务器提供 3 个 API 端点（`healthz`、`livez` 和 `readyz`）来表明 API 服务器的当前状态。
 `healthz` 端点已被弃用（自 Kubernetes v1.16 起），你应该使用更为明确的 `livez` 和 `readyz` 端点。
-`livez` 端点可与 `--livez-grace-period` [标志](/zh/docs/reference/command-line-tools-reference/kube-apiserver)一起使用，来指定启动持续时间。
-为了正常关机，你可以使用 `/readyz` 端点并指定 `--shutdown-delay-duration` [标志](/zh/docs/reference/command-line-tools-reference/kube-apiserver)。
+`livez` 端点可与 `--livez-grace-period` [标志](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver)一起使用，来指定启动持续时间。
+为了正常关机，你可以使用 `/readyz` 端点并指定 `--shutdown-delay-duration` [标志](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver)。
 检查 API 服务器的 `healthz`/`livez`/`readyz` 端点的机器应依赖于 HTTP 状态代码。
 状态码 `200` 表示 API 服务器是 `healthy`、`live` 还是 `ready`，具体取决于所调用的端点。
 以下更详细的选项供操作人员使用，用来调试其集群或了解 API 服务器的状态。
@@ -33,7 +33,7 @@ declaratively by sending their fully specified intent.
 服务器端应用协助用户、控制器通过声明式配置的方式管理他们的资源。
 客户端可以发送完整描述的目标（A fully specified intent），
 声明式地创建和/或修改
-[对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)。
+[对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/)。

 <!--
 A fully specified intent is a partial object that only includes the fields and