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

content/zh-cn/docs/reference/using-api/api-concepts.md

@@ -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