update markdown files in glossary dirctory.

content/zh/docs/reference/glossary/annotation.md

@@ -40,5 +40,7 @@ tags:
 The metadata in an annotation can be small or large, structured or unstructured, and can include characters not permitted by {{< glossary_tooltip text="labels" term_id="label" >}}. Clients such as tools and libraries can retrieve this metadata.
 -->
 
-注解中的元数据可大可小，可以是结构化的也可以是非结构化的，并且能包含 {{< glossary_tooltip text="标签" term_id="label" >}} 不允许使用的字符。像工具和软件库这样的客户端可以检索这些元数据。
+注解中的元数据可大可小，可以是结构化的也可以是非结构化的，
+并且能包含{{< glossary_tooltip text="标签" term_id="label" >}}不允许使用的字符。
+像工具和软件库这样的客户端可以检索这些元数据。
 

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

@@ -39,7 +39,10 @@ Kubernetes API 中的一组相关路径。
 <!-- 
 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 group 使扩展 Kubernetes API 更加的容易。 API group 在 REST 路径和序列化对象的 `apiVersion` 字段中指定。
+通过更改 API server 的配置，可以启用或禁用每个 API Group。
+你还可以禁用或启用指向特定资源的路径。
+API group 使扩展 Kubernetes API 更加的容易。
+API group 在 REST 路径和序列化对象的 `apiVersion` 字段中指定。
 
 <!-- 
 * Read [API Group](/docs/concepts/overview/kubernetes-api/#api-groups) for more information. 

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

@@ -42,5 +42,6 @@ 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" >}} 整体而言很重要的初始化细节，并且一旦应用容器启动，它不需要继续运行。
+初始化容器使您可以分离对于{{< glossary_tooltip text="工作负载" term_id="workload" >}}
+整体而言很重要的初始化细节，并且一旦应用容器启动，它不需要继续运行。
 如果 pod 没有配置任何初始化容器，则该 pod 中的所有容器都是应用程序容器。

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

@@ -39,5 +39,6 @@ tags:
 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/docs/reference/glossary/approver.md

@@ -37,4 +37,6 @@ tags:
 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 和参数约定、细微的性能和正确性问题、与系统其他部分的交互等。批准者状态的作用域是代码库的一部分。审批者以前被称为维护者。
+代码审核的重点是代码质量和正确性，而批准的重点是对贡献的整体接受。
+整体接受包括向后/向前兼容性、遵守 API 和参数约定、细微的性能和正确性问题、与系统其他部分的交互等。
+批准者状态的作用域是代码库的一部分。审批者以前被称为维护者。

content/zh/docs/reference/glossary/cidr.md

@@ -37,4 +37,7 @@ CIDR (无类域间路由) 是一种描述 IP 地址块的符号，被广泛使
 <!--
 In the context of Kubernetes, each {{< glossary_tooltip text="Node" term_id="node" >}} is assigned a range of IP addresses through the start address and a subnet mask using CIDR. This allows Nodes to assign each {{< glossary_tooltip text="Pod" term_id="pod" >}} a unique IP address. Although originally a concept for IPv4, CIDR has also been expanded to include IPv6. 
 -->
-在 Kubernetes 的上下文中，每个 {{< glossary_tooltip text="节点" term_id="node" >}} 以 CIDR 形式（含起始地址和子网掩码）获得一个 IP 地址段，从而能够为每个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 分配一个独一无二的 IP 地址。虽然其概念最初源自 IPv4，CIDR 已经被扩展为涵盖 IPv6。
+在 Kubernetes 的上下文中，每个{{< glossary_tooltip text="节点" term_id="node" >}}
+以 CIDR 形式（含起始地址和子网掩码）获得一个 IP 地址段，
+从而能够为每个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 分配一个独一无二的 IP 地址。
+虽然其概念最初源自 IPv4，CIDR 已经被扩展为涵盖 IPv6。

content/zh/docs/reference/glossary/cla.md

@@ -29,7 +29,7 @@ tags:
 <!--
  Terms under which a {{< glossary_tooltip text="contributor" term_id="contributor" >}} grants a license to an open source project for their contributions.
 -->
- {{< glossary_tooltip text="贡献者" term_id="contributor" >}} 对他们在开源项目中所贡献的代码的授权许可条款。
+ {{< glossary_tooltip text="贡献者" term_id="contributor" >}}对他们在开源项目中所贡献的代码的授权许可条款。
 
 <!--more--> 
 

content/zh/docs/reference/glossary/cloud-controller-manager.md

@@ -38,7 +38,10 @@ cluster into your cloud provider's API, and separates out the components that in
 with that cloud platform from components that just interact with your cluster.
 -->
 
-云控制器管理器是指嵌入特定云的控制逻辑的 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 组件。云控制器管理器允许您链接聚合到云提供商的应用编程接口中，并分离出相互作用的组件与您的集群交互的组件。
+云控制器管理器是指嵌入特定云的控制逻辑的
+{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}组件。
+云控制器管理器允许您链接聚合到云提供商的应用编程接口中，
+并分离出相互作用的组件与您的集群交互的组件。
 
 <!--more--> 
 
@@ -47,4 +50,5 @@ By decoupling the interoperability logic between Kubernetes and the underlying c
 infrastructure, the cloud-controller-manager component enables cloud providers to release
 features at a different pace compared to the main Kubernetes project.
 -->
-通过分离 Kubernetes 和底层云基础设置之间的互操作性逻辑，云控制器管理器组件使云提供商能够以不同于 Kubernetes 主项目的速度进行发布新特征。
+通过分离 Kubernetes 和底层云基础设置之间的互操作性逻辑，
+云控制器管理器组件使云提供商能够以不同于 Kubernetes 主项目的速度进行发布新特征。

content/zh/docs/reference/glossary/cloud-provider.md

@@ -58,8 +58,8 @@ elements such as load balancers.
 针对托管的基础设施，云供应商负责服务器、存储和网络，而用户（你）
 负责管理其上运行的各层软件，例如运行一个 Kubernetes 集群。
 
-你也会看到 Kubernetes 被作为托管服务提供；有时也称作平台即服务或 PaaS 。
-针对托管的 Kubernetes ，你的云供应商负责 Kubernetes 的控制面以及
+你也会看到 Kubernetes 被作为托管服务提供；有时也称作平台即服务或 PaaS。
+针对托管的 Kubernetes，你的云供应商负责 Kubernetes 的控制面以及
  {{< glossary_tooltip term_id="node" text="节点" >}} 及他们所依赖的基础设施：
 网络、存储以及其他一些诸如负载均衡器之类的元素。
 

content/zh/docs/reference/glossary/cluster-operations.md

@@ -30,7 +30,7 @@ tags:
  The work involved in managing a Kubernetes cluster: managing
 day-to-day operations, and co-ordinating upgrades.
 -->
- Kubernetes 管理相关工作包括：日常管理操作和协调升级。
+Kubernetes 管理相关工作包括：日常管理操作和协调升级。
 
 <!--
  Examples of cluster operations work include: deploying new Nodes to
@@ -38,4 +38,5 @@ scale the cluster; performing software upgrades; implementing security
 controls; adding or removing storage; configuring cluster networking;
 managing cluster-wide observability; and responding to events.
 -->															  
-群集操作工作的示例包括:部署新节点来扩容集群；执行软件升级；实施安全控制；添加或删除存储；配置集群网络；管理集群范围的可观测性；响应集群事件。
+群集操作工作的示例包括：部署新节点来扩容集群；执行软件升级；实施安全控制；
+添加或删除存储；配置集群网络；管理集群范围的可观测性；响应集群事件。

content/zh/docs/reference/glossary/cluster.md

@@ -43,4 +43,5 @@ nodes and the Pods in the cluster. In production environments, the control plane
 runs across multiple computers and a cluster usually runs multiple nodes, providing
 fault-tolerance and high availability.
 -->
-工作节点托管作为应用负载的组件的 Pod 。控制平面管理集群中的工作节点和 Pod 。为集群提供故障转移和高可用性，这些控制平面一般跨多主机运行，集群跨多个节点运行。
+工作节点托管作为应用负载的组件的 Pod 。控制平面管理集群中的工作节点和 Pod 。
+为集群提供故障转移和高可用性，这些控制平面一般跨多主机运行，集群跨多个节点运行。

content/zh/docs/reference/glossary/containerd.md

@@ -35,5 +35,5 @@ that runs as a daemon on Linux or Windows. containerd takes care of fetching and
 storing container images, executing containers, providing network access, and more.
 -->
 
-containerd 是一种 {{< glossary_tooltip text="容器" term_id="container" >}} 运行时，能在 Linux 或者 Windows 后台运行。
+containerd 是一种{{< glossary_tooltip text="容器" term_id="container" >}}运行时，能在 Linux 或者 Windows 后台运行。
 containerd 能取回、存储容器镜像，执行容器实例，提供网络访问等。

content/zh/docs/reference/glossary/contributor.md

@@ -35,5 +35,5 @@ tags:
 Contributions include pull requests (PRs), issues, feedback, {{< glossary_tooltip text="special interest groups (SIG)" term_id="sig" >}} participation, or organizing community events.
 -->
 
-贡献形式包括提交拉取请求（PRs）、问题报告（Issues）、反馈、参与 {{< glossary_tooltip text="特别兴趣小组（SIG）" term_id="sig" >}} 或者组织社区活动等等。
+贡献形式包括提交拉取请求（PRs）、问题报告（Issues）、反馈、参与{{< glossary_tooltip text="特别兴趣小组（SIG）" term_id="sig" >}}或者组织社区活动等等。
 

content/zh/docs/reference/glossary/controller.md

@@ -35,10 +35,9 @@ changes where needed.
 Each controller tries to move the current cluster state closer to the desired
 state.
 -->					 
-																			 
-	  
 
- 在 Kubernetes 中，控制器通过监控 {{< glossary_tooltip text="集群" term_id="cluster" >}} 的公共状态，并致力于将当前状态转变为期望的状态。
+在 Kubernetes 中，控制器通过监控{{< glossary_tooltip text="集群" term_id="cluster" >}}
+的公共状态，并致力于将当前状态转变为期望的状态。
 
 <!--more--> 
 																			   
@@ -48,7 +47,8 @@ Controllers watch the shared state of your cluster through the
 {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} (part of the
 {{< glossary_tooltip term_id="control-plane" >}}).
 -->
-控制器（{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的一部分）通过{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}}监控你的集群中的公共状态。
+控制器（{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的一部分）
+通过 {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} 监控你的集群中的公共状态。
 
 <!--
 Some controllers also run inside the control plane, providing control loops that
@@ -57,6 +57,8 @@ daemonset controller, the namespace controller, and the persistent volume
 controller (and others) all run within the
 {{< glossary_tooltip term_id="kube-controller-manager" >}}. 
 -->
-其中一些控制器是运行在控制平面内部的，对Kubernates来说，他们提供核心控制操作。比如：部署控制器（deployment controller）、守护控制器（daemonset controller）、命名空间控制器（namespace controller）、持久化数据卷控制器（persistent volume
-controller）（等）都是运行在{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}中的。
+其中一些控制器是运行在控制平面内部的，对 Kubernetes 来说，他们提供核心控制操作。
+比如：部署控制器（deployment controller）、守护控制器（daemonset controller）、
+命名空间控制器（namespace controller）、持久化数据卷控制器（persistent volume
+controller）（等）都是运行在 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} 中的。
 

content/zh/docs/reference/glossary/cri-o.md

@@ -44,4 +44,6 @@ Deploying CRI-O allows Kubernetes to use any OCI-compliant runtime as the contai
 runtime for running {{< glossary_tooltip text="Pods" term_id="pod" >}}, and to fetch
 OCI container images from remote registries.
 -->
-部署 CRI-O 允许 Kubernetes 使用任何符合 OCI 的运行时，作为容器运行环境去运行 {{< glossary_tooltip text="Pods" term_id="pod" >}}，并从远程注册表获取 OCI 容器镜像。
+部署 CRI-O 允许 Kubernetes 使用任何符合 OCI 的运行时，
+作为容器运行环境去运行 {{< glossary_tooltip text="Pods" term_id="pod" >}}，
+并从远程注册表获取 OCI 容器镜像。

content/zh/docs/reference/glossary/csi.md

@@ -42,7 +42,11 @@ CSI allows vendors to create custom storage plugins for Kubernetes without addin
 * [List of available CSI drivers](https://kubernetes-csi.github.io/docs/drivers.html)
 -->
 
-CSI 允许存储驱动提供商为 Kubernetes 创建定制化的存储插件，而无需将这些插件的代码添加到 Kubernetes 代码仓库（外部插件）。要使用某个存储提供商的 CSI 驱动，你首先要[将它部署到你的集群上](https://kubernetes-csi.github.io/docs/deploying.html)。然后你才能创建使用该 CSI 驱动的 {{< glossary_tooltip text="Storage Class" term_id="storage-class" >}} 。
+CSI 允许存储驱动提供商为 Kubernetes 创建定制化的存储插件，
+而无需将这些插件的代码添加到 Kubernetes 代码仓库（外部插件）。
+要使用某个存储提供商的 CSI 驱动，你首先要
+[将它部署到你的集群上](https://kubernetes-csi.github.io/docs/deploying.html)。
+然后你才能创建使用该 CSI 驱动的 {{< glossary_tooltip text="Storage Class" term_id="storage-class" >}} 。
 
 * [Kubernetes 文档中关于 CSI 的描述](/zh/docs/concepts/storage/volumes/#csi)
 * [可用的 CSI 驱动列表](https://kubernetes-csi.github.io/docs/drivers.html)

content/zh/docs/reference/glossary/deployment.md

@@ -44,4 +44,5 @@ Each replica is represented by a {{< glossary_tooltip term_id="pod" >}}, and the
 For workloads that do require local state, consider using a {{< glossary_tooltip term_id="StatefulSet" >}}.
 -->
 
-应用的每个副本就是一个 {{< glossary_tooltip text="Pod" term_id="pod" >}}，并且这些 Pod 会分散运行在集群的{{< glossary_tooltip text="节点" term_id="node" >}}上。
+应用的每个副本就是一个 {{< glossary_tooltip text="Pod" term_id="pod" >}}，
+并且这些 Pod 会分散运行在集群的{{< glossary_tooltip text="节点" term_id="node" >}}上。

content/zh/docs/reference/glossary/developer.md

@@ -28,7 +28,9 @@ tags:
 ---
 -->
 
- 指的是： {{< glossary_tooltip text="应用开发者" term_id="application-developer" >}}、 {{< glossary_tooltip text="代码贡献者" term_id="code-contributor" >}}、或 {{< glossary_tooltip text="平台开发者" term_id="platform-developer" >}}。
+ 指的是：{{< glossary_tooltip text="应用开发者" term_id="application-developer" >}}、
+ {{< glossary_tooltip text="代码贡献者" term_id="code-contributor" >}}、
+ 或{{< glossary_tooltip text="平台开发者" term_id="platform-developer" >}}。
 
 <!--more--> 
 

content/zh/docs/reference/glossary/docker.md

@@ -38,4 +38,5 @@ Docker (specifically, Docker Engine) is a software technology providing operatin
 Docker uses the resource isolation features of the Linux kernel such as cgroups and kernel namespaces, and a union-capable file system such as OverlayFS and others to allow independent "containers" to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines (VMs).
 -->
 
-Docker 使用了 Linux 内核中的资源隔离特性（如 cgroup 和内核命名空间）以及支持联合文件系统（如 OverlayFS 和其他），允许多个相互独立的“容器”一起运行在同一 Linux 实例上，从而避免启动和维护虚拟机（VMs）的开销。
+Docker 使用了 Linux 内核中的资源隔离特性（如 cgroup 和内核命名空间）以及支持联合文件系统（如 OverlayFS 和其他），
+允许多个相互独立的“容器”一起运行在同一 Linux 实例上，从而避免启动和维护虚拟机（VMs）的开销。

content/zh/docs/reference/glossary/dynamic-volume-provisioning.md

@@ -41,4 +41,6 @@ Dynamic provisioning eliminates the need for cluster administrators to pre-provi
 -->
 
 动态供应让集群管理员无需再预先供应存储。相反，它通过用户请求自动地供应存储。
-动态卷供应是基于 API 对象 {{< glossary_tooltip text="储存类别" term_id="storage-class" >}} 的， StorageClass 可以引用 {{< glossary_tooltip text="卷插件" term_id="volume-plugin" >}} 提供的 {{< glossary_tooltip text="卷" term_id="volume" >}} ，也可以引用传递给卷插件（Volume Plugin）的参数集。
+动态卷供应是基于 API 对象 {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} 的，
+StorageClass 可以引用 {{< glossary_tooltip text="卷插件" term_id="volume-plugin" >}} 提供的
+{{< glossary_tooltip text="卷" term_id="volume" >}}，也可以引用传递给卷插件（Volume Plugin）的参数集。

content/zh/docs/reference/glossary/endpoint-slice.md

@@ -37,4 +37,6 @@ establish network routes on each {{< glossary_tooltip text="node" term_id="node"
 -->
 
 
-一种将网络端点组合在一起的可扩缩、可扩展方式。它们将被 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} 用于在每个 {{< glossary_tooltip text="节点" term_id="node">}} 上建立网络路由。
+一种将网络端点组合在一起的可扩缩、可扩展方式。
+它们将被 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} 用于在
+每个 {{< glossary_tooltip text="节点" term_id="node">}} 上建立网络路由。

content/zh/docs/reference/glossary/ephemeral-container.md

@@ -9,7 +9,7 @@ aka:
 tags:
 - fundamental
 ---
-  您可以在 {{< glossary_tooltip term_id="pod" >}} 中临时运行的一种 {{< glossary_tooltip term_id="container" >}} 类型 
+  您可以在 {{< glossary_tooltip term_id="pod" >}} 中临时运行的一种 {{< glossary_tooltip term_id="container" >}} 类型。
 
 <!--
 ---
@@ -33,4 +33,5 @@ A {{< glossary_tooltip term_id="container" >}} type that you can temporarily run
 If you want to investigate a Pod that's running with problems, you can add an ephemeral container to that Pod and carry out diagnostics. Ephemeral containers have no resource or scheduling guarantees, and you should not use them to run any part of the workload itself.
 -->
 
-如果想要调查运行中有问题的 Pod，可以向该 Pod 添加一个临时容器并进行诊断。临时容器没有资源或调度保证，因此不应该使用它们来运行任何部分的工作负荷本身。
+如果想要调查运行中有问题的 Pod，可以向该 Pod 添加一个临时容器并进行诊断。
+临时容器没有资源或调度保证，因此不应该使用它们来运行任何部分的工作负荷本身。

content/zh/docs/reference/glossary/extensions.md

@@ -35,4 +35,6 @@ tags:
 Most cluster administrators will use a hosted or distribution instance of Kubernetes. As a result, most Kubernetes users will need to install [extensions](/docs/concepts/extend-kubernetes/extend-cluster/#extensions) and fewer will need to author new ones.
 -->
 
-大多数集群管理员会使用托管的 Kubernetes 或其某种发行包。因此，大多数 Kubernetes 用户将需要安装 [扩展组件](/docs/concepts/extend-kubernetes/extend-cluster/#extensions)，较少用户会需要编写新的扩展组件。
+大多数集群管理员会使用托管的 Kubernetes 或其某种发行包。因此，大多数 Kubernetes 用户将需要
+安装 [扩展组件](/docs/concepts/extend-kubernetes/extend-cluster/#extensions)，
+较少用户会需要编写新的扩展组件。

content/zh/docs/reference/glossary/flexvolume.md

@@ -35,7 +35,10 @@ tags:
 <!-- 
 FlexVolumes enable users to write their own drivers and add support for their volumes in Kubernetes. FlexVolume driver binaries and dependencies must be installed on host machines. This requires root access. The Storage SIG suggests implementing a {{< glossary_tooltip text="CSI" term_id="csi" >}} driver if possible since it addresses the limitations with FlexVolumes.
 -->
-Flexvolume 允许用户编写自己的驱动程序，并在 Kubernetes 中加入对用户自己的数据卷的支持。FlexVolume 驱动程序的二进制文件和依赖项必须安装在主机上。这需要 root 权限。如果可能的话，SIG Storage 建议实现 {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动程序，因为它解决了 Flexvolumes 的限制。
+Flexvolume 允许用户编写自己的驱动程序，并在 Kubernetes 中加入对用户自己的数据卷的支持。
+FlexVolume 驱动程序的二进制文件和依赖项必须安装在主机上。
+这需要 root 权限。如果可能的话，SIG Storage 建议实现 {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动程序，
+因为它解决了 Flexvolumes 的限制。
 
 <!-- 
 * [FlexVolume in the Kubernetes documentation](/docs/concepts/storage/volumes/#flexvolume)

content/zh/docs/reference/glossary/helm-chart.md

@@ -40,4 +40,5 @@ A single chart can be used to deploy something simple, like a memcached Pod, or
 -->
 
 Chart 提供了一种可重现的用来创建和共享 Kubernetes 应用的方法。
-单个 Chart 可用来部署简单的系统（例如一个 memcached Pod），也可以用来部署复杂的系统（例如包含 HTTP 服务器、数据库、缓存等组件的完整 Web 应用堆栈）。
+单个 Chart 可用来部署简单的系统（例如一个 memcached Pod），
+也可以用来部署复杂的系统（例如包含 HTTP 服务器、数据库、缓存等组件的完整 Web 应用堆栈）。

content/zh/docs/reference/glossary/horizontal-pod-autoscaler.md

@@ -36,4 +36,7 @@ tags:
 HPA is typically used with {{< glossary_tooltip text="ReplicationControllers" term_id="replication-controller" >}}, {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, or {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}. It cannot be applied to objects that cannot be scaled, for example {{< glossary_tooltip text="DaemonSets" term_id="daemonset" >}}.
 -->
 
-HPA 通常用于 {{< glossary_tooltip text="ReplicationControllers" term_id="replication-controller" >}}、{{< glossary_tooltip text="Deployments" term_id="deployment" >}} 或者 {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} 上。HPA 不能用于不支持扩缩的对象，例如 {{< glossary_tooltip text="DaemonSets" term_id="daemonset" >}}。
+HPA 通常用于 {{< glossary_tooltip text="ReplicationControllers" term_id="replication-controller" >}}
+、{{< glossary_tooltip text="Deployments" term_id="deployment" >}} 
+或者 {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} 上。
+HPA 不能用于不支持扩缩的对象，例如 {{< glossary_tooltip text="DaemonSets" term_id="daemonset" >}}。

content/zh/docs/reference/glossary/host-aliases.md

@@ -33,5 +33,6 @@ tags:
 <!-- 
 [HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) is an optional list of hostnames and IP addresses that will be injected into the Pod's hosts file if specified. This is only valid for non-hostNetwork Pods.
 -->
-[HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) 是一个包含主机名和 IP 地址的可选列表，配置后将被注入到 Pod 内的 hosts 文件中。
+[HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core)
+是一个包含主机名和 IP 地址的可选列表，配置后将被注入到 Pod 内的 hosts 文件中。
 该选项仅适用于没有配置 hostNetwork 的 Pod.

content/zh/docs/reference/glossary/init-container.md

@@ -38,4 +38,5 @@ tags:
 Initialization (init) containers are like regular app containers, with one difference: init containers must run to completion before any app containers can start. Init containers run in series: each init container must run to completion before the next init container begins.
 -->
 
-初始化（init）容器像常规应用容器一样，只有一点不同：初始化（init）容器必须在应用容器启动前运行完成。Init 容器的运行顺序：一个初始化（init）容器必须在下一个初始化（init）容器开始前运行完成。
+初始化（init）容器像常规应用容器一样，只有一点不同：初始化（init）容器必须在应用容器启动前运行完成。
+Init 容器的运行顺序：一个初始化（init）容器必须在下一个初始化（init）容器开始前运行完成。

content/zh/docs/reference/glossary/istio.md

@@ -41,5 +41,7 @@ Istio 是个开放平台（非 Kubernetes 特有），提供了一种统一的
 Adding Istio does not require changing application code. It is a layer of infrastructure between a service and the network, which when combined with service deployments, is commonly referred to as a service mesh. Istio's control plane abstracts away the underlying cluster management platform, which may be Kubernetes, Mesosphere, etc.
 -->
 
-添加 Istio 时不需要修改应用代码。它是基础设施的一层，介于服务和网络之间。当它和服务的 Deployment 相结合时，就构成了通常所谓的服务网格（Service Mesh）。Istio 的控制面抽象掉了底层的集群管理平台，这一集群管理平台可以是 Kubernetes、Mesosphere 等。
+添加 Istio 时不需要修改应用代码。它是基础设施的一层，介于服务和网络之间。
+当它和服务的 Deployment 相结合时，就构成了通常所谓的服务网格（Service Mesh）。
+Istio 的控制面抽象掉了底层的集群管理平台，这一集群管理平台可以是 Kubernetes、Mesosphere 等。
 

content/zh/docs/reference/glossary/job.md

@@ -42,4 +42,5 @@ tags:
 Creates one or more {{< glossary_tooltip term_id="pod" >}} objects and ensures that a specified number of them successfully terminate. As Pods successfully complete, the Job tracks the successful completions.
 -->
 
-Job 创建一个或多个 {{< glossary_tooltip term_id="Pod" >}} 对象，并确保指定数量的 Pod 成功终止。随着各 Pod 成功结束，Job 会跟踪记录成功完成的个数。
+Job 创建一个或多个 {{< glossary_tooltip term_id="Pod" >}} 对象，并确保指定数量的 Pod 成功终止。
+随着各 Pod 成功结束，Job 会跟踪记录成功完成的个数。

content/zh/docs/reference/glossary/kube-controller-manager.md

@@ -35,5 +35,6 @@ tags:
 
 <!--more--> 
 
-从逻辑上讲，每个 {{< glossary_tooltip text="控制器" term_id="controller" >}} 都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。
+从逻辑上讲，每个{{< glossary_tooltip text="控制器" term_id="controller" >}}都是一个单独的进程，
+但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。
 

content/zh/docs/reference/glossary/kube-proxy.md

@@ -27,7 +27,8 @@ tags:
  <!-- [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) is a
 network proxy that runs on each node in your cluster, implementing part of
 the Kubernetes {{< glossary_tooltip term_id="service">}} concept. -->
- [kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) 是集群中每个节点上运行的网络代理,实现 Kubernetes {{< glossary_tooltip term_id="service">}} 概念的一部分。
+[kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) 是集群中每个节点上运行的网络代理，
+实现 Kubernetes {{< glossary_tooltip term_id="service">}} 概念的一部分。
 
 <!--more-->
 

content/zh/docs/reference/glossary/security-context.md

@@ -32,7 +32,8 @@ a {{< glossary_tooltip text="Pod" term_id="pod" >}} or
 {{< glossary_tooltip text="container" term_id="container" >}}.
 -->
 
-securityContext 字段定义 {{< glossary_tooltip text="Pod" term_id="pod" >}} 或 {{< glossary_tooltip text="container（容器）" term_id="container" >}} 的特权和访问控制设置。
+securityContext 字段定义 {{< glossary_tooltip text="Pod" term_id="pod" >}} 或
+{{< glossary_tooltip text="容器" term_id="container" >}}的特权和访问控制设置。
 
 <!--more-->
 

content/zh/docs/reference/glossary/selector.md

@@ -32,7 +32,7 @@ tags:
  Allows users to filter a list of resources based on {{< glossary_tooltip text="labels" term_id="label" >}}.
 -->
 
-选择算符允许用户通过 {{< glossary_tooltip text="标签（labels）" term_id="label" >}} 对一组资源对象进行筛选过滤。
+选择算符允许用户通过{{< glossary_tooltip text="标签（labels）" term_id="label" >}}对一组资源对象进行筛选过滤。
 
 <!--more--> 
 

content/zh/docs/reference/glossary/service-account.md

@@ -39,5 +39,7 @@ tags:
 <!--
 When processes inside Pods access the cluster, they are authenticated by the API server as a particular service account, for example, `default`. When you create a Pod, if you do not specify a service account, it is automatically assigned the default service account in the same {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.
 -->
-当 Pod 中的进程访问集群时，API 服务器将它们作为特定的服务帐户进行身份验证，例如  `default` ，创建 Pod 时，如果你没有指定服务帐户，它将自动被赋予同一个 {{< glossary_tooltip text="名字空间" term_id="namespace" >}} 中的 default 服务账户。
+当 Pod 中的进程访问集群时，API 服务器将它们作为特定的服务帐户进行身份验证，
+例如  `default` ，创建 Pod 时，如果你没有指定服务帐户，它将自动被赋予同一个
+{{< glossary_tooltip text="名字空间" term_id="namespace" >}}中的 default 服务账户。
 

content/zh/docs/reference/glossary/service-broker.md

@@ -29,7 +29,7 @@ tags:
 <!--
  An endpoint for a set of {{< glossary_tooltip text="Managed Services" term_id="managed-service" >}} offered and maintained by a third-party.
 -->
-由第三方提供并维护的一组 {{< glossary_tooltip text="托管服务（Managed Services）" term_id="managed-service">}} 的访问端点。
+由第三方提供并维护的一组{{< glossary_tooltip text="托管服务" term_id="managed-service">}}的访问端点。
 
 <!--more--> 
 
@@ -41,7 +41,7 @@ and provide a standard interface for applications to use their Managed Services.
 list, provision, and bind with Managed Services offered by Service Brokers.
 -->
 
-{{< glossary_tooltip text="Service Brokers（服务代理）" term_id="service-broker">}}会实现
+{{< glossary_tooltip text="服务代理（Service Brokers）" term_id="service-broker">}}会实现
 [开放服务代理 API 规范](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)
 并为应用提供使用其托管服务的标准接口。
 [服务目录（Service Catalog）](/zh/docs/concepts/extend-kubernetes/service-catalog/)则提供一种方法，用来列举、供应和绑定服务代理商所提供的托管服务。

content/zh/docs/reference/glossary/service-catalog.md

@@ -39,5 +39,7 @@ tags:
 It provides a way to list, provision, and bind with external {{< glossary_tooltip text="Managed Services" term_id="managed-service" >}} from {{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} without needing detailed knowledge about how those services are created or managed.
 -->
 
-服务目录可以检索、供应、和绑定由 {{< glossary_tooltip text="Service Brokers（服务代理人）" term_id="service-broker" >}} 提供的外部 {{< glossary_tooltip text="托管服务（Managed Services）" term_id="managed-service" >}}，而无需知道那些服务具体是怎样创建和托管的。
+服务目录可以检索、供应、和绑定由 {{< glossary_tooltip text="服务代理人（Service Brokers）" term_id="service-broker" >}}
+提供的外部{{< glossary_tooltip text="托管服务（Managed Services）" term_id="managed-service" >}}，
+而无需知道那些服务具体是怎样创建和托管的。
 

content/zh/docs/reference/glossary/service.md

@@ -40,4 +40,6 @@ An abstract way to expose an application running on a set of {{< glossary_toolti
 <!--
  The set of Pods targeted by a Service is (usually) determined by a {{< glossary_tooltip text="selector" term_id="selector" >}}. If more Pods are added or removed, the set of Pods matching the selector will change. The Service makes sure that network traffic can be directed to the current set of Pods for the workload.
 -->
-服务所针对的 Pod 集（通常）由 {{< glossary_tooltip text="选择算符" term_id="selector" >}} 确定。 如果有 Pod 被添加或被删除，则与选择算符匹配的 Pod 集合将发生变化。服务确保可以将网络流量定向到该工作负载的当前 Pod 集合。
+服务所针对的 Pod 集（通常）由{{< glossary_tooltip text="选择算符" term_id="selector" >}}确定。
+如果有 Pod 被添加或被删除，则与选择算符匹配的 Pod 集合将发生变化。
+服务确保可以将网络流量定向到该工作负载的当前 Pod 集合。

content/zh/docs/reference/glossary/statefulset.md

@@ -34,16 +34,22 @@ tags:
 <!--
  Manages the deployment and scaling of a set of {{< glossary_tooltip text="Pods" term_id="pod" >}}, *and provides guarantees about the ordering and uniqueness* of these Pods.
 -->
-StatefulSet 用来管理某 {{< glossary_tooltip text="Pod" term_id="pod" >}} 集合的部署和扩缩，并为这些 Pod 提供持久存储和持久标识符。 
+StatefulSet 用来管理某 {{< glossary_tooltip text="Pod" term_id="pod" >}} 集合的部署和扩缩，
+并为这些 Pod 提供持久存储和持久标识符。 
 <!--more--> 
 
 <!--
 Like a {{< glossary_tooltip term_id="deployment" >}}, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable&#58; each has a persistent identifier that it maintains across any rescheduling.
 -->
 
-和 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 类似，StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是，StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的，但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。
+和 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 类似，
+StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是，
+StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的，
+但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。
 <!--
 If you want to use storage volumes to provide persistence for your workload, you can use a StatefulSet as part of the solution. Although individual Pods in a StatefulSet are susceptible to failure, the persistent Pod identifiers make it easier to match existing volumes to the new Pods that replace any that have failed.
 -->
 
-如果希望使用存储卷为工作负载提供持久存储，可以使用 StatefulSet 作为解决方案的一部分。尽管 StatefulSet 中的单个 Pod 仍可能出现故障，但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。
+如果希望使用存储卷为工作负载提供持久存储，可以使用 StatefulSet 作为解决方案的一部分。
+尽管 StatefulSet 中的单个 Pod 仍可能出现故障，
+但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。

content/zh/docs/reference/glossary/storage-class.md

@@ -40,4 +40,7 @@ tags:
 StorageClasses can map to quality-of-service levels, backup policies, or to arbitrary policies determined by cluster administrators. Each StorageClass contains the fields `provisioner`, `parameters`, and `reclaimPolicy`, which are used when a {{< glossary_tooltip text="Persistent Volume" term_id="persistent-volume" >}} belonging to the class needs to be dynamically provisioned. Users can request a particular class using the name of a StorageClass object.
 -->
 
-StorageClass 可以映射到服务质量等级（QoS）、备份策略、或者管理员任意定义的策略。每个 StorageClass 对象包含的字段有 `provisioner`、`parameters` 和 `reclaimPolicy`。动态制备该存储类别的 {{< glossary_tooltip text="持久卷" term_id="persistent-volume" >}}时需要用到这些字段值。通过设置 StorageClass 对象的名称，用户可以请求特定存储类别。
+StorageClass 可以映射到服务质量等级（QoS）、备份策略、或者管理员任意定义的策略。
+每个 StorageClass 对象包含的字段有 `provisioner`、`parameters` 和 `reclaimPolicy`。
+动态制备该存储类别的{{< glossary_tooltip text="持久卷" term_id="persistent-volume" >}}时需要用到这些字段值。
+通过设置 StorageClass 对象的名称，用户可以请求特定存储类别。

content/zh/docs/reference/glossary/sysctl.md

@@ -48,4 +48,4 @@ uses.
 network plugins may rely on `sysctl` values being set a certain way.
 -->
 
-{{< glossary_tooltip text="容器" term_id="container" >}} 运行时和网络插件可能对 `sysctl` 的取值有一定的要求。
+{{< glossary_tooltip text="容器" term_id="container" >}}运行时和网络插件可能对 `sysctl` 的取值有一定的要求。

content/zh/docs/reference/glossary/taint.md

@@ -30,7 +30,9 @@ tags:
 <!--
  A core object consisting of three required properties: key, value, and effect. Taints prevent the scheduling of {{< glossary_tooltip text="Pods" term_id="pod" >}} on {{< glossary_tooltip text="nodes" term_id="node" >}} or node groups.
 -->
-污点是一种一个核心对象，包含三个必需的属性：key、value 和 effect。污点会阻止在{{< glossary_tooltip text="节点" term_id="node" >}}或节点组上调度 {{< glossary_tooltip text="Pods" term_id="pod" >}}。 
+污点是一种一个核心对象，包含三个必需的属性：key、value 和 effect。
+污点会阻止在{{< glossary_tooltip text="节点" term_id="node" >}}
+或节点组上调度 {{< glossary_tooltip text="Pods" term_id="pod" >}}。 
 
 
 <!--more-->
@@ -39,4 +41,6 @@ tags:
 Taints and {{< glossary_tooltip text="tolerations" term_id="toleration" >}} work together to ensure that pods are not scheduled onto inappropriate nodes. One or more taints are applied to a node. A node should only schedule a Pod with the matching tolerations for the configured taints.
 -->
 
-污点和 {{< glossary_tooltip text="容忍度" term_id="toleration" >}} 一起工作，以确保不会将 Pod 调度到不适合的节点上。同一 {< glossary_tooltip text="节点" term_id="node" >}}上可应用一个或多个污点。节点应该仅调度那些带着能与污点相匹配容忍度的 Pod。
+污点和{{< glossary_tooltip text="容忍度" term_id="toleration" >}}一起工作，以确保不会将 Pod 调度到不适合的节点上。
+同一{< glossary_tooltip text="节点" term_id="node" >}}上可应用一个或多个污点。
+节点应该仅调度那些带着能与污点相匹配容忍度的 Pod。

content/zh/docs/reference/glossary/toleration.md

@@ -30,7 +30,8 @@ tags:
 <!--
  A core object consisting of three required properties: key, value, and effect. Tolerations enable the scheduling of pods on nodes or node groups that have matching {{< glossary_tooltip text="taints" term_id="taint" >}}.
 -->
- 一个核心对象，由三个必需的属性组成：key、value 和 effect。容忍度允许将 Pod 调度到具有匹配 {{< glossary_tooltip text="污点" term_id="taint" >}} 的节点或节点组上。
+ 一个核心对象，由三个必需的属性组成：key、value 和 effect。
+ 容忍度允许将 Pod 调度到具有匹配{{< glossary_tooltip text="污点" term_id="taint" >}}的节点或节点组上。
  
 
 
@@ -39,4 +40,7 @@ tags:
 <!--
 Tolerations and {{< glossary_tooltip text="taints" term_id="taint" >}} work together to ensure that pods are not scheduled onto inappropriate nodes. One or more tolerations are applied to a {{< glossary_tooltip text="pod" term_id="pod" >}}. A toleration indicates that the {{< glossary_tooltip text="pod" term_id="pod" >}} is allowed (but not required) to be scheduled on nodes or node groups with matching {{< glossary_tooltip text="taints" term_id="taint" >}}.
 -->
- 容忍度 和 {{< glossary_tooltip text="污点" term_id="taint" >}} 共同作用以确保不会将 Pod 调度在不适合的节点上。在同一 {{< glossary_tooltip text="pod" term_id="pod" >}} 上可以设置一个或者多个容忍度。容忍度表示在匹配节点或节点组上的 {{< glossary_tooltip text="污点" term_id="taint" >}} 调度 {{< glossary_tooltip text="pod" term_id="pod" >}} 是允许的（但不必要）。
+ 容忍度 和{{< glossary_tooltip text="污点" term_id="taint" >}}共同作用以确保不会将 Pod 调度在不适合的节点上。
+ 在同一 {{< glossary_tooltip text="pod" term_id="pod" >}} 上可以设置一个或者多个容忍度。
+ 容忍度表示在匹配节点或节点组上的{{< glossary_tooltip text="污点" term_id="taint" >}}
+ 调度 {{< glossary_tooltip text="pod" term_id="pod" >}} 是允许的（但不必要）。

content/zh/docs/reference/glossary/volume-plugin.md

@@ -40,5 +40,7 @@ tags:
 A Volume Plugin lets you attach and mount storage volumes for use by a {{< glossary_tooltip text="Pod" term_id="pod" >}}. Volume plugins can be _in tree_ or _out of tree_. _In tree_ plugins are part of the Kubernetes code repository and follow its release cycle. _Out of tree_ plugins are developed independently.
 -->
 
-卷插件让您能给 {{< glossary_tooltip text="Pod" term_id="pod" >}} 附加和挂载存储卷。卷插件既可以是 _in tree_ 也可以是 _out of tree_ 。_in tree_ 插件是 Kubernetes 代码库的一部分，并遵循其发布周期。而 _Out of tree_ 插件则是独立开发的。
+卷插件让您能给 {{< glossary_tooltip text="Pod" term_id="pod" >}} 附加和挂载存储卷。
+卷插件既可以是 _in tree_ 也可以是 _out of tree_ 。_in tree_ 插件是 Kubernetes 代码库的一部分，
+并遵循其发布周期。而 _Out of tree_ 插件则是独立开发的。
 

content/zh/docs/reference/glossary/workload.md

@@ -42,6 +42,7 @@ For example, a workload that has a web server and a database might run the
 database in one {{< glossary_tooltip term_id="StatefulSet" >}} and the web server
 in a {{< glossary_tooltip term_id="Deployment" >}}.
 -->
-代表不同类型或部分工作负载的各种核心对象包括 DaemonSet, Deployment, Job, ReplicaSet, and StatefulSet。
+代表不同类型或部分工作负载的各种核心对象包括 DaemonSet， Deployment， Job， ReplicaSet， and StatefulSet。
 
-例如，具有 Web 服务器和数据库的工作负载可能在一个 {{< glossary_tooltip term_id="StatefulSet" >}} 中运行数据库，而 Web 服务器运行在 {{< glossary_tooltip term_id="Deployment" >}}。
+例如，具有 Web 服务器和数据库的工作负载可能在一个 {{< glossary_tooltip term_id="StatefulSet" >}} 中运行数据库，
+而 Web 服务器运行在 {{< glossary_tooltip term_id="Deployment" >}}。