Merge pull request #36305 from ydFu/update-reference-glossary-2

[zh] Update reference\glossary (2)

Author: k8s-ci-robot

content/zh-cn/docs/reference/glossary/api-eviction.md

@@ -1,5 +1,5 @@
 ---
-title: API 发起的驱逐
+title: API 发起的驱逐（API-initiated eviction）
 id: api-eviction
 date: 2021-04-27
 full_link: /zh-cn/docs/concepts/scheduling-eviction/api-eviction/
@@ -54,4 +54,4 @@ API 发起的驱逐不同于
 <!--
 * See [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/) for more information.
 -->
-* 有关详细信息，请参阅 [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)。
+* 有关详细信息，请参阅 [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)。

content/zh-cn/docs/reference/glossary/api-group.md

@@ -1,19 +1,17 @@
 ---
-title: API Group
+title: API Group (API 组)
 id: api-group
 date: 2019-09-02
 full_link: /zh-cn/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning
 short_description: >
-  Kubernetes API 中的一组相关路径
+  Kubernetes API 中的一组相关路径。
 
 aka:
 tags:
 - fundamental
 - architecture
 ---
-
 <!-- 
----
 title: API Group
 id: api-group
 date: 2019-09-02
@@ -24,27 +22,24 @@ short_description: >
 aka:
 tags:
 - fundamental
-- architecture
----										  
+- architecture									  
 -->
 
-
 <!-- 
 A set of related paths in Kubernetes API.  
 -->
 Kubernetes API 中的一组相关路径。
 
 <!--more-->																																																																											  
-
 <!-- 
 You can enable or disable each API group by changing the configuration of your API server. You can also disable or enable paths to specific resources. API group makes it easier to extend the Kubernetes API. The API group is specified in a REST path and in the `apiVersion` field of a serialized object. 
 -->
-通过更改 API server 的配置，可以启用或禁用每个 API Group。
+通过更改 API 服务器的配置，可以启用或禁用每个 API 组 (API Group)。
 你还可以禁用或启用指向特定资源的路径。
-API group 使扩展 Kubernetes API 更加的容易。
-API group 在 REST 路径和序列化对象的 `apiVersion` 字段中指定。
+API 组使扩展 Kubernetes API 更加的容易。
+API 组在 REST 路径和序列化对象的 `apiVersion` 字段中指定。
 
 <!-- 
 * Read [API Group](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) for more information. 
 -->
-* 阅读 [API Group](/zh-cn/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) 了解更多信息。
+* 阅读 [API 组](/zh-cn/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) 了解更多信息。

content/zh-cn/docs/reference/glossary/app-container.md

@@ -4,15 +4,13 @@ id: app-container
 date: 2019-02-12
 full_link:
 short_description: >
-  用于运行部分工作负载的容器。与初始化容器比较而言。
+  用于运行部分工作负载的容器。与 Init 容器比较而言。
 
 aka:
 tags:
 - workload
 ---
-
 <!--
----
 title: App Container
 id: app-container
 date: 2019-02-12
@@ -23,15 +21,14 @@ short_description: >
 aka:
 tags:
 - workload
----
 -->
 
 <!--
  Application containers (or app containers) are the {{< glossary_tooltip text="containers" term_id="container" >}} in a {{< glossary_tooltip text="pod" term_id="pod" >}} that are started after any {{< glossary_tooltip text="init containers" term_id="init-container" >}} have completed.
 -->
-  应用程序 {{< glossary_tooltip text="容器" term_id="container" >}} （或 app 容器）在 {{< glossary_tooltip text="pod" term_id="pod" >}} 中，在 {{< glossary_tooltip text="初始化容器" term_id="init-container" >}} 启动完毕后才开始启动。
-
-
+应用程序容器是在 {{< glossary_tooltip text="Pod" term_id="pod" >}}
+中的{{< glossary_tooltip text="容器" term_id="container" >}}（或 app 容器），
+在 {{< glossary_tooltip text="Init 容器" term_id="init-container" >}}启动完毕后才开始启动。
 
 <!--more-->
 
@@ -41,7 +38,6 @@ An init container lets you separate initialization details that are important fo
 once the application container has started.
 If a pod doesn't have any init containers configured, all the containers in that pod are app containers.
 -->
-
-初始化容器使你可以分离对于{{< glossary_tooltip text="工作负载" term_id="workload" >}}
-整体而言很重要的初始化细节，并且一旦应用容器启动，它不需要继续运行。
-如果 pod 没有配置任何初始化容器，则该 pod 中的所有容器都是应用程序容器。
+Init 容器使你可以分离对于{{< glossary_tooltip text="工作负载" term_id="workload" >}}整体而言很重要的初始化细节，
+并且一旦应用容器启动，它不需要继续运行。
+如果 Pod 没有配置 Init 容器，则该 Pod 中的所有容器都是应用程序容器。

content/zh-cn/docs/reference/glossary/application-architect.md

@@ -10,9 +10,7 @@ aka:
 tags:
 - user-type
 ---
-
 <!--
----
 title: Application Architect
 id: application-architect
 date: 2018-04-12
@@ -23,22 +21,17 @@ short_description: >
 aka: 
 tags:
 - user-type
----
 -->
 
 <!--
  A person responsible for the high-level design of an application.
 -->
  应用架构师是负责应用高级设计的人。
 
-			
+<!--more-->
 
-
-<!--more--> 
 <!--
 An architect ensures that an app's implementation allows it to interact with its surrounding components in a scalable, maintainable way. Surrounding components include databases, logging infrastructure, and other microservices.
 -->
-
 应用架构师确保应用的实现允许它和周边组件进行可扩展的、可持续的交互。
 周边组件包括数据库、日志基础设施和其他微服务。
-

content/zh-cn/docs/reference/glossary/application-developer.md

@@ -10,9 +10,7 @@ aka:
 tags:
 - user-type
 ---
-
 <!--
----
 title: Application Developer
 id: application-developer
 date: 2018-04-12
@@ -23,20 +21,16 @@ short_description: >
 aka: 
 tags:
 - user-type
----
 -->
 
-
 <!--
  A person who writes an application that runs in a Kubernetes cluster.
 -->
-
 编写可以在 Kubernetes 集群上运行的应用的人。
 
 <!--more--> 
 
 <!--
 An application developer focuses on one part of an application. The scale of their focus may vary significantly in size.
 -->
-
 应用开发者专注于应用的某一部分。他们工作范围的大小有明显的差异。

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

@@ -11,7 +11,6 @@ tags:
 ---
 
 <!--
----
 title: Applications
 id: applications
 date: 2019-05-12
@@ -21,10 +20,8 @@ short_description: >
 aka:
 tags:
 - fundamental
----
 -->
 
-
 <!--
  The layer where various containerized applications run.
 -->

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

@@ -10,9 +10,7 @@ aka:
 tags:
 - community
 ---
-
 <!--
----
 title: Approver
 id: approver
 date: 2018-04-12
@@ -23,20 +21,18 @@ short_description: >
 aka: 
 tags:
 - community
----
 -->
 
 <!--
  A person who can review and approve Kubernetes code contributions.
 -->
- 可以审核并批准 Kubernetes 代码贡献的人。
+ 能够审核并批准 Kubernetes 代码贡献的人。
 
 <!--more--> 
 
 <!--
 While code review is focused on code quality and correctness, approval is focused on the holistic acceptance of a contribution. Holistic acceptance includes backwards/forwards compatibility, adhering to API and flag conventions, subtle performance and correctness issues, interactions with other parts of the system, and others. Approver status is scoped to a part of the codebase. Approvers were previously referred to as maintainers.
 -->
-
 代码审核的重点是代码质量和正确性，而批准的重点是对贡献的整体接受。
 整体接受包括向后/向前兼容性、遵守 API 和参数约定、细微的性能和正确性问题、与系统其他部分的交互等。
 批准者状态的作用域是代码库的一部分。审批者以前被称为维护者。