[zh]update content/zh/docs/concepts/overview

Author: jckling

content/zh/docs/concepts/overview/components.md

@@ -33,7 +33,7 @@ a complete and working Kubernetes cluster.
 
 -->
 <!-- overview -->
-当你部署完 Kubernetes, 即拥有了一个完整的集群。
+当你部署完 Kubernetes，即拥有了一个完整的集群。
 {{< glossary_definition term_id="cluster" length="all" prepend="一个 Kubernetes">}}
 
 本文档概述了交付正常运行的 Kubernetes 集群所需的各种组件。
@@ -49,7 +49,7 @@ The control plane's components make global decisions about the cluster (for exam
  -->
 ## 控制平面组件（Control Plane Components）    {#control-plane-components}
 
-控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的
+控制平面的组件对集群做出全局决策（比如调度），以及检测和响应集群事件（例如，当不满足部署的
 `replicas` 字段时，启动新的 {{< glossary_tooltip text="pod" term_id="pod">}}）。
 
 <!--
@@ -62,7 +62,7 @@ for an example control plane setup that runs across multiple machines.
 控制平面组件可以在集群中的任何节点上运行。
 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件，
 并且不会在此计算机上运行用户容器。
-请参阅[使用 kubeadm 构建高可用性集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)
+请参阅 [使用 kubeadm 构建高可用性集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)
 中关于跨多机器控制平面设置的示例。
 
 ### kube-apiserver
@@ -90,12 +90,12 @@ Some types of these controllers are:
   * Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods).
   * Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.
 -->
-这些控制器包括:
+这些控制器包括：
 
-* 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应
-* 任务控制器（Job controller）: 监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
-* 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)
-* 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌
+* 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
+* 任务控制器（Job controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
+* 端点控制器（Endpoints Controller）：填充端点（Endpoints）对象（即加入 Service 与 Pod）
+* 服务帐户和令牌控制器（Service Account & Token Controllers）：为新的命名空间创建默认帐户和 API 访问令牌
 
 <!--
 ### cloud-controller-manager
@@ -128,9 +128,9 @@ The following controllers can have cloud provider dependencies:
 
 下面的控制器都包含对云平台驱动的依赖：
 
-  * 节点控制器（Node Controller）: 用于在节点终止响应后检查云提供商以确定节点是否已被删除
-  * 路由控制器（Route Controller）: 用于在底层云基础架构中设置路由
-  * 服务控制器（Service Controller）: 用于创建、更新和删除云提供商负载均衡器
+  * 节点控制器（Node Controller）：用于在节点终止响应后检查云提供商以确定节点是否已被删除
+  * 路由控制器（Route Controller）：用于在底层云基础架构中设置路由
+  * 服务控制器（Service Controller）：用于创建、更新和删除云提供商负载均衡器
 
 <!--
 ## Node Components
@@ -167,7 +167,7 @@ for addons belong within the `kube-system` namespace.
 ## 插件（Addons）    {#addons}
 
 插件使用 Kubernetes 资源（{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}、
-{{< glossary_tooltip text="Deployment" term_id="deployment" >}}等）实现集群功能。
+{{< glossary_tooltip text="Deployment" term_id="deployment" >}} 等）实现集群功能。
 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 `kube-system` 命名空间。
 
 <!--
@@ -189,7 +189,7 @@ Containers started by Kubernetes automatically include this DNS server in their
 ### DNS   {#dns}
 
 尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该
-有[集群 DNS](/zh/docs/concepts/services-networking/dns-pod-service/)，
+有 [集群 DNS](/zh/docs/concepts/services-networking/dns-pod-service/)，
 因为很多示例都需要 DNS 服务。
 
 集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。
@@ -237,7 +237,7 @@ saving container logs to a central log store with search/browsing interface.
 * Learn about [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/)
 * Read etcd's official [documentation](https://etcd.io/docs/)
 -->
-* 进一步了解[节点](/zh/docs/concepts/architecture/nodes/)
-* 进一步了解[控制器](/zh/docs/concepts/architecture/controller/)
+* 进一步了解 [节点](/zh/docs/concepts/architecture/nodes/)
+* 进一步了解 [控制器](/zh/docs/concepts/architecture/controller/)
 * 进一步了解 [kube-scheduler](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)
-* 阅读 etcd 官方[文档](https://etcd.io/docs/)
+* 阅读 etcd 官方 [文档](https://etcd.io/docs/)

content/zh/docs/concepts/overview/kubernetes-api.md

@@ -44,7 +44,7 @@ Consider using one of the [client libraries](/docs/reference/using-api/client-li
 if you are writing an application using the Kubernetes API.
 -->
 如果你正在编写程序来访问 Kubernetes API，可以考虑使用
-[客户端库](/zh/docs/reference/using-api/client-libraries/)之一。
+[客户端库](/zh/docs/reference/using-api/client-libraries/) 之一。
 
 <!-- body -->
 
@@ -157,7 +157,7 @@ for the kube-apiserver component.
 Kubernetes v1.23 提供将其 API 以 OpenAPI v3 形式发布的初始支持；这一功能特性处于 Alpha
 状态，默认被禁用。
 你可以通过为 kube-apiserver 组件启用 `OpenAPIV3`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)来启用此
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 来启用此
 Alpha 特性。
 
 <!--
@@ -260,7 +260,7 @@ Refer to [API versions reference](/docs/reference/using-api/#api-versioning)
 for more details on the API version level definitions.
 -->
 关于 API 版本分级的定义细节，请参阅
-[API 版本参考](/zh/docs/reference/using-api/#api-versioning)页面。
+[API 版本参考](/zh/docs/reference/using-api/#api-versioning) 页面。
 
 <!--
 ## API Extension
@@ -277,7 +277,7 @@ The Kubernetes API can be extended in one of two ways:
 1. You can also extend the Kubernetes API by implementing an
    [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
 -->
-1. 你可以使用[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+1. 你可以使用 [自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
    来以声明式方式定义 API 服务器如何提供你所选择的资源 API。 
 1. 你也可以选择实现自己的
    [聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
@@ -298,9 +298,9 @@ The Kubernetes API can be extended in one of two ways:
 - 了解如何通过添加你自己的
   [CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
   来扩展 Kubernetes API。
-- [控制 Kubernetes API 访问](/zh/docs/concepts/security/controlling-access/)页面描述了集群如何针对
+- [控制 Kubernetes API 访问](/zh/docs/concepts/security/controlling-access/) 页面描述了集群如何针对
   API 访问管理身份认证和鉴权。
-- 通过阅读 [API 参考](/zh/docs/reference/kubernetes-api/)了解 API 端点、资源类型以及示例。
+- 通过阅读 [API 参考](/zh/docs/reference/kubernetes-api/) 了解 API 端点、资源类型以及示例。
 - 阅读 [API 变更（英文）](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)
   以了解什么是兼容性的变更以及如何变更 API。
 

content/zh/docs/concepts/overview/what-is-kubernetes.md

@@ -237,9 +237,9 @@ Kubernetes：
   Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。
   如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。
 * 不部署源代码，也不构建你的应用程序。
-  持续集成(CI)、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。
+  持续集成（CI）、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。
 * 不提供应用程序级别的服务作为内置服务，例如中间件（例如，消息中间件）、
-  数据处理框架（例如，Spark）、数据库（例如，mysql）、缓存、集群存储系统
+  数据处理框架（例如，Spark）、数据库（例如，MySQL）、缓存、集群存储系统
   （例如，Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在
   Kubernetes 上的应用程序通过可移植机制（例如，
   [开放服务代理](https://openservicebrokerapi.org/)）来访问。
@@ -268,4 +268,4 @@ Kubernetes：
 *   Ready to [Get Started](/docs/setup/)?
 -->
 * 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/)
-* 开始 [Kubernetes 入门](/zh/docs/setup/)?
+* 开始 [Kubernetes 入门](/zh/docs/setup/)？

content/zh/docs/concepts/overview/working-with-objects/annotations.md

@@ -37,7 +37,7 @@ Annotations, like labels, are key/value maps:
 标签可以用来选择对象和查找满足某些条件的对象集合。 相反，注解不用于标识和选择对象。
 注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符。
 
-注解和标签一样，是键/值对:
+注解和标签一样，是键/值对：
 
 ```json
 "metadata": {
@@ -60,7 +60,7 @@ Map 中的键和值必须是字符串。
 <!--
 Here are some examples of information that could be recorded in annotations:
 -->
-以下是一些例子，用来说明哪些信息可以使用注解来记录:
+以下是一些例子，用来说明哪些信息可以使用注解来记录：
 
 <!--
 * Fields managed by a declarative configuration layer. Attaching these fields
@@ -126,10 +126,10 @@ If the prefix is omitted, the annotation Key is presumed to be private to the us
 
 _注解（Annotations）_ 存储的形式是键/值对。有效的注解键分为两部分：
 可选的前缀和名称，以斜杠（`/`）分隔。 
-名称段是必需项，并且必须在63个字符以内，以字母数字字符（`[a-z0-9A-Z]`）开头和结尾，
+名称段是必需项，并且必须在 63 个字符以内，以字母数字字符（`[a-z0-9A-Z]`）开头和结尾，
 并允许使用破折号（`-`），下划线（`_`），点（`.`）和字母数字。 
-前缀是可选的。如果指定，则前缀必须是DNS子域：一系列由点（`.`）分隔的DNS标签，
-总计不超过253个字符，后跟斜杠（`/`）。
+前缀是可选的。如果指定，则前缀必须是 DNS 子域：一系列由点（`.`）分隔的 DNS 标签，
+总计不超过 253 个字符，后跟斜杠（`/`）。
 如果省略前缀，则假定注解键对用户是私有的。 由系统组件添加的注解
 （例如，`kube-scheduler`，`kube-controller-manager`，`kube-apiserver`，`kubectl`
 或其他第三方组件），必须为终端用户添加注解前缀。
@@ -139,7 +139,7 @@ The `kubernetes.io/` and `k8s.io/` prefixes are reserved for Kubernetes core com
 
 For example, here's the configuration file for a Pod that has the annotation `imageregistry: https://hub.docker.com/` :
 -->
-`kubernetes.io/` 和 `k8s.io/` 前缀是为Kubernetes核心组件保留的。
+`kubernetes.io/` 和 `k8s.io/` 前缀是为 Kubernetes 核心组件保留的。
 
 例如，下面是一个 Pod 的配置文件，其注解中包含 `imageregistry: https://hub.docker.com/`：
 
@@ -163,5 +163,5 @@ spec:
 <!--
 * Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/).
 -->
-* 进一步了解[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。
+* 进一步了解 [标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。
 

content/zh/docs/concepts/overview/working-with-objects/field-selectors.md

@@ -31,7 +31,7 @@ kubectl get pods --field-selector status.phase=Running
 Field selectors are essentially resource *filters*. By default, no selectors/filters are applied, meaning that all resources of the specified type are selected. This makes the following `kubectl` queries equivalent:
 -->
 {{< note >}}
-字段选择器本质上是资源*过滤器（Filters）*。默认情况下，字段选择器/过滤器是未被应用的，
+字段选择器本质上是资源 *过滤器（Filters）*。默认情况下，字段选择器/过滤器是未被应用的，
 这意味着指定类型的所有资源都会被筛选出来。
 这使得以下的两个 `kubectl` 查询是等价的：
 
@@ -67,7 +67,7 @@ You can use the `=`, `==`, and `!=` operators with field selectors (`=` and `==`
 -->
 ## 支持的操作符   {#supported-operators}
 
-你可在字段选择器中使用 `=`、`==`和 `!=` （`=` 和 `==` 的意义是相同的）操作符。
+你可在字段选择器中使用 `=`、`==` 和 `!=` （`=` 和 `==` 的意义是相同的）操作符。
 例如，下面这个 `kubectl` 命令将筛选所有不属于 `default` 命名空间的 Kubernetes 服务：
 
 ```shell
@@ -81,7 +81,7 @@ As with [label](/docs/concepts/overview/working-with-objects/labels) and other s
 -->
 ## 链式选择器   {#chained-selectors}
 
-同[标签](/zh/docs/concepts/overview/working-with-objects/labels/)和其他选择器一样，
+同 [标签](/zh/docs/concepts/overview/working-with-objects/labels/) 和其他选择器一样，
 字段选择器可以通过使用逗号分隔的列表组成一个选择链。
 下面这个 `kubectl` 命令将筛选 `status.phase` 字段不等于 `Running` 同时
 `spec.restartPolicy` 字段等于 `Always` 的所有 Pod：

content/zh/docs/concepts/overview/working-with-objects/finalizers.md

@@ -13,9 +13,9 @@ You can use finalizers to control {{<glossary_tooltip text="garbage collection"
 of resources by alerting {{<glossary_tooltip text="controllers" term_id="controller">}} to perform specific cleanup tasks before
 deleting the target resource. 
 -->
-你可以通过使用 Finalizers 提醒{{<glossary_tooltip text="控制器" term_id="controller">}}
+你可以通过使用 Finalizers 提醒 {{<glossary_tooltip text="控制器" term_id="controller">}}
 在删除目标资源前执行特定的清理任务，
-来控制资源的{{<glossary_tooltip text="垃圾收集" term_id="garbage-collection">}}。
+来控制资源的 {{<glossary_tooltip text="垃圾收集" term_id="garbage-collection">}}。
 
 <!--
 Finalizers don't usually specify the code to execute. Instead, they are
@@ -98,10 +98,10 @@ any Pods in the cluster with the same label.
 -->
 ## 属主引用、标签和 Finalizers {#owners-labels-finalizers}
 
-与{{<glossary_tooltip text="标签" term_id="label">}}类似，
+与 {{<glossary_tooltip text="标签" term_id="label">}} 类似，
 [属主引用](/zh/concepts/overview/working-with-objects/owners-dependents/)
 描述了 Kubernetes 中对象之间的关系，但它们作用不同。
-当一个{{<glossary_tooltip text="控制器" term_id="controller">}}
+当一个 {{<glossary_tooltip text="控制器" term_id="controller">}}
 管理类似于 Pod 的对象时，它使用标签来跟踪相关对象组的变化。
 例如，当 {{<glossary_tooltip text="Job" term_id="job">}} 创建一个或多个 Pod 时，
 Job 控制器会给这些 Pod 应用上标签，并跟踪集群中的具有相同标签的 Pod 的变化。
@@ -121,7 +121,7 @@ longer than expected without being fully deleted. In these situations, you
 should check finalizers and owner references on the target owner and dependent
 objects to troubleshoot the cause. 
 -->
-Job 控制器还为这些 Pod 添加了*属主引用*，指向创建 Pod 的 Job。
+Job 控制器还为这些 Pod 添加了 *属主引用*，指向创建 Pod 的 Job。
 如果你在这些 Pod 运行的时候删除了 Job，
 Kubernetes 会使用属主引用（而不是标签）来确定集群中哪些 Pod 需要清理。
 
@@ -153,5 +153,5 @@ Finalizers 通常因为特殊原因被添加到资源上，所以强行删除它
 * Read [Using Finalizers to Control Deletion](/blog/2021/05/14/using-finalizers-to-control-deletion/)
   on the Kubernetes blog.
 -->
-* 在 Kubernetes 博客上阅读[使用 Finalizers 控制删除](/blog/2021/05/14/using-finalizers-to-control-deletion/)。
+* 在 Kubernetes 博客上阅读 [使用 Finalizers 控制删除](/blog/2021/05/14/using-finalizers-to-control-deletion/)。