Merge pull request #33570 from jckling/zh-docs-patch

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

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">}}）。
 
 <!--
@@ -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）: 负责在节点出现故障时进行通知和响应
+* 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
-* 任务控制器（Job controller）: 监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
+* 任务控制器（Job controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
-* 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)
+* 端点控制器（Endpoints Controller）：填充端点（Endpoints）对象（即加入 Service 与 Pod）
-* 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌
+* 服务帐户和令牌控制器（Service Account & Token Controllers）：为新的命名空间创建默认帐户和 API 访问令牌
 
 <!--
 ### cloud-controller-manager
@@ -128,9 +128,9 @@ The following controllers can have cloud provider dependencies:
 
 下面的控制器都包含对云平台驱动的依赖：
 
-  * 节点控制器（Node Controller）: 用于在节点终止响应后检查云提供商以确定节点是否已被删除
+  * 节点控制器（Node Controller）：用于在节点终止响应后检查云提供商以确定节点是否已被删除
-  * 路由控制器（Route Controller）: 用于在底层云基础架构中设置路由
+  * 路由控制器（Route Controller）：用于在底层云基础架构中设置路由
-  * 服务控制器（Service 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` 命名空间。
 
 <!--

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

@@ -236,9 +236,9 @@ Kubernetes：
   Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。
   如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。
 * 不部署源代码，也不构建你的应用程序。
-  持续集成(CI)、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。
+  持续集成（CI）、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。
 * 不提供应用程序级别的服务作为内置服务，例如中间件（例如，消息中间件）、
-  数据处理框架（例如，Spark）、数据库（例如，mysql）、缓存、集群存储系统
+  数据处理框架（例如，Spark）、数据库（例如，MySQL）、缓存、集群存储系统
   （例如，Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在
   Kubernetes 上的应用程序通过可移植机制（例如，
   [开放服务代理](https://openservicebrokerapi.org/)）来访问。
@@ -267,4 +267,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标签，
+前缀是可选的。如果指定，则前缀必须是 DNS 子域：一系列由点（`.`）分隔的 DNS 标签，
-总计不超过253个字符，后跟斜杠（`/`）。
+总计不超过 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/`：
 

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

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

@@ -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 需要清理。
 

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

@@ -121,7 +121,7 @@ Here's an example `.yaml` file that shows the required fields and object spec fo
 
 创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，
 以及关于对象的一些基本信息（例如名称）。
-当使用 Kubernetes API 创建对象时（或者直接创建，或者基于`kubectl`），
+当使用 Kubernetes API 创建对象时（或者直接创建，或者基于 `kubectl`），
 API 请求必须在请求体中包含 JSON 格式的信息。
 **大多数情况下，需要在 .yaml 文件中为 `kubectl` 提供这些信息**。
 `kubectl` 在发起 API 请求时，将这些信息转换成 JSON 格式。
@@ -135,7 +135,7 @@ One way to create a Deployment using a `.yaml` file like the one above is to use
 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) command
 in the `kubectl` command-line interface, passing the `.yaml` file as an argument. Here's an example:
 -->
-使用类似于上面的 `.yaml` 文件来创建 Deployment的一种方式是使用 `kubectl` 命令行接口（CLI）中的
+使用类似于上面的 `.yaml` 文件来创建 Deployment 的一种方式是使用 `kubectl` 命令行接口（CLI）中的
 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 命令，
 将 `.yaml` 文件作为参数。下面是一个示例：
 

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

@@ -40,7 +40,7 @@ and CLIs. Non-identifying information should be recorded using
 [annotations](/docs/concepts/overview/working-with-objects/annotations/).
 -->
 标签能够支持高效的查询和监听操作，对于用户界面和命令行是很理想的。
-应使用[注解](/zh/docs/concepts/overview/working-with-objects/annotations/) 记录非识别信息。
+应使用[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)记录非识别信息。
 
 <!-- body -->
 
@@ -72,7 +72,7 @@ Example labels:
 <!--
 These are examples of [commonly used labels](/docs/concepts/overview/working-with-objects/common-labels/); you are free to develop your own conventions. Keep in mind that label Key must be unique for a given object.
 -->
-有一些[常用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)的例子; 你可以任意制定自己的约定。
+有一些[常用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)的例子；你可以任意制定自己的约定。
 请记住，标签的 Key 对于给定对象必须是唯一的。
 
 <!--
@@ -109,7 +109,7 @@ Valid label value:
 
 * 必须为 63 个字符或更少（可以为空）
 * 除非标签值为空，必须以字母数字字符（`[a-z0-9A-Z]`）开头和结尾
-* 包含破折号（`-`）、下划线（`_`）、点（`.`）和字母或数字。
+* 包含破折号（`-`）、下划线（`_`）、点（`.`）和字母或数字
 
 <!--
 ## Label selectors
@@ -168,7 +168,7 @@ Three kinds of operators are admitted `=`,`==`,`!=`. The first two represent _eq
 
 _基于等值_ 或 _基于不等值_ 的需求允许按标签键和值进行过滤。
 匹配对象必须满足所有指定的标签约束，尽管它们也可能具有其他标签。
-可接受的运算符有`=`、`==` 和 `!=` 三种。 
+可接受的运算符有 `=`、`==` 和 `!=` 三种。 
 前两个表示 _相等_（并且只是同义词），而后者表示 _不相等_。例如：
 
 ```
@@ -217,7 +217,7 @@ _Set-based_ label requirements allow filtering keys according to a set of values
 ### _基于集合_ 的需求
 
 _基于集合_ 的标签需求允许你通过一组值来过滤键。
-支持三种操作符：`in`、`notin` 和 `exists` (只可以用在键标识符上)。例如：
+支持三种操作符：`in`、`notin` 和 `exists`（只可以用在键标识符上）。例如：
 
 ```
 environment in (production, qa)
@@ -241,13 +241,13 @@ Similarly the comma separator acts as an _AND_ operator. So filtering resources
 * 第四个示例选择了所有没有 `partition` 标签的资源；没有校验它的值。
 
 类似地，逗号分隔符充当 _与_ 运算符。因此，使用 `partition` 键（无论为何值）和
-`environment` 不同于 `qa` 来过滤资源可以使用 `partition, environment notin（qa)` 来实现。
+`environment` 不同于 `qa` 来过滤资源可以使用 `partition, environment notin (qa)` 来实现。
 
 <!--
 The _set-based_ label selector is a general form of equality since `environment=production` is equivalent to `environment in (production)`; similarly for `!=` and `notin`.
 -->
 _基于集合_ 的标签选择算符是相等标签选择算符的一般形式，因为 `environment=production`
-等同于 `environment in（production）`；`!=` 和 `notin` 也是类似的。
+等同于 `environment in (production)`；`!=` 和 `notin` 也是类似的。
 
 <!--
 _Set-based_ requirements can be mixed with _equality-based_ requirements. For example: `partition in (customerA, customerB),environment!=qa`.
@@ -270,8 +270,8 @@ LIST 和 WATCH 操作可以使用查询参数指定标签选择算符过滤一
 * _equality-based_ requirements: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
 * _set-based_ requirements: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
 -->
-* _基于等值_ 的需求: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
+* _基于等值_ 的需求：`?labelSelector=environment%3Dproduction,tier%3Dfrontend`
-* _基于集合_ 的需求: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
+* _基于集合_ 的需求：`?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
 
 <!--
 Both label selector styles can be used to list or watch resources via a REST client. For example, targeting `apiserver` with `kubectl` and using _equality-based_ one may write:
@@ -354,7 +354,7 @@ selector:
 <!---
 this selector (respectively in `json` or `yaml` format) is equivalent to `component=redis` or `component in (redis)`.
 -->
-这个选择算符(分别在 `json` 或者 `yaml` 格式中) 等价于 `component=redis` 或 `component in (redis)` 。
+这个选择算符（分别在 `json` 或者 `yaml` 格式中）等价于 `component=redis` 或 `component in (redis)`。
 
 <!--
 #### Resources that support set-based requirements
@@ -366,7 +366,7 @@ Newer resources, such as [`Job`](/docs/concepts/jobs/run-to-completion-finite-wo
 比较新的资源，例如 [`Job`](/zh/docs/concepts/workloads/controllers/job/)、
 [`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/)、
 [`Replica Set`](/zh/docs/concepts/workloads/controllers/replicaset/) 和
-[`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) ，
+[`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/)，
 也支持 _基于集合的_ 需求。
 
 ```yaml
@@ -383,7 +383,7 @@ selector:
 -->
 
 `matchLabels` 是由 `{key,value}` 对组成的映射。
-`matchLabels` 映射中的单个 `{key,value }` 等同于 `matchExpressions` 的元素，
+`matchLabels` 映射中的单个 `{key,value}` 等同于 `matchExpressions` 的元素，
 其 `key` 字段为 "key"，`operator` 为 "In"，而 `values` 数组仅包含 "value"。
 `matchExpressions` 是 Pod 选择算符需求的列表。
 有效的运算符包括 `In`、`NotIn`、`Exists` 和 `DoesNotExist`。

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

@@ -13,12 +13,12 @@ Every Kubernetes object also has a [_UID_](#uids) that is unique across your who
 For example, you can only have one Pod named `myapp-1234` within the same [namespace](/docs/concepts/overview/working-with-objects/namespaces/), but you can have one Pod and one Deployment that are each named `myapp-1234`.
 -->
 
-集群中的每一个对象都有一个[_名称_](#names) 来标识在同类资源中的唯一性。
+集群中的每一个对象都有一个[_名称_](#names)来标识在同类资源中的唯一性。
 
-每个 Kubernetes 对象也有一个[_UID_](#uids) 来标识在整个集群中的唯一性。
+每个 Kubernetes 对象也有一个 [_UID_](#uids) 来标识在整个集群中的唯一性。
 
 比如，在同一个[名字空间](/zh/docs/concepts/overview/working-with-objects/namespaces/)
-中有一个名为 `myapp-1234` 的 Pod, 但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`.
+中有一个名为 `myapp-1234` 的 Pod，但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`。
 
 <!--
 For non-unique user-provided attributes, Kubernetes provides [labels](/docs/user-guide/labels) and [annotations](/docs/concepts/overview/working-with-objects/annotations/).
@@ -69,10 +69,10 @@ This means the name must:
 DNS 子域名的定义可参见 [RFC 1123](https://tools.ietf.org/html/rfc1123)。
 这一要求意味着名称必须满足如下规则：
 
-- 不能超过253个字符
+- 不能超过 253 个字符
-- 只能包含小写字母、数字，以及'-' 和 '.'
+- 只能包含小写字母、数字，以及 '-' 和 '.'
-- 须以字母数字开头
+- 必须以字母数字开头
-- 须以字母数字结尾
+- 必须以字母数字结尾
 
 <!--
 ### DNS Label Names
@@ -93,8 +93,8 @@ This means the name must:
 
 - 最多 63 个字符
 - 只能包含小写字母、数字，以及 '-'
-- 须以字母数字开头
+- 必须以字母数字开头
-- 须以字母数字结尾
+- 必须以字母数字结尾
 
 
 <!--
@@ -116,8 +116,8 @@ This means the name must:
 
 - 最多 63 个字符
 - 只能包含小写字母、数字，以及 '-'
-- 须以字母开头
+- 必须以字母开头
-- 须以字母数字结尾
+- 必须以字母数字结尾
 
 <!--
 ### Path Segment Names
@@ -134,7 +134,7 @@ not contain "/" or "%".
 <!--
 Here’s an example manifest for a Pod named `nginx-demo`.
 -->
-下面是一个名为`nginx-demo`的 Pod 的配置清单：
+下面是一个名为 `nginx-demo` 的 Pod 的配置清单：
 
 ```yaml
 apiVersion: v1
@@ -165,7 +165,7 @@ Kubernetes UIDs are universally unique identifiers (also known as UUIDs).
 UUIDs are standardized as ISO/IEC 9834-8 and as ITU-T X.667.
 -->
 Kubernetes UIDs 是全局唯一标识符（也叫 UUIDs）。
-UUIDs 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667.  
+UUIDs 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667。
 
 ## {{% heading "whatsnext" %}}
 

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

@@ -150,7 +150,7 @@ context.
 
 ```shell
 kubectl config set-context --current --namespace=<名字空间名称>
-# 验证之
+# 验证
 kubectl config view | grep namespace:
 ```
 
@@ -161,7 +161,7 @@ When you create a [Service](/docs/user-guide/services), it creates a correspondi
 -->
 ## 名字空间和 DNS
 
-当你创建一个[服务](/zh/docs/concepts/services-networking/service/) 时，
+当你创建一个[服务](/zh/docs/concepts/services-networking/service/)时，
 Kubernetes 会创建一个相应的 [DNS 条目](/zh/docs/concepts/services-networking/dns-pod-service/)。
 
 <!--
@@ -224,7 +224,7 @@ persistentVolumes, are not in any namespace.
 -->
 大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些名字空间中。
 但是名字空间资源本身并不在名字空间中。而且底层资源，例如
-[节点](/zh/docs/concepts/architecture/nodes/) 和持久化卷不属于任何名字空间。
+[节点](/zh/docs/concepts/architecture/nodes/)和持久化卷不属于任何名字空间。
 
 <!--
 To see which Kubernetes resources are and aren't in a namespace:

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

@@ -18,9 +18,9 @@ In Kubernetes, some objects are *owners* of other objects. For example, a
 of their owner. 
 -->
 
-在 Kubernetes 中，一些对象是其他对象的*属主（Owner）*。
+在 Kubernetes 中，一些对象是其他对象的“属主（Owner）”。
 例如，{{<glossary_tooltip text="ReplicaSet" term_id="replica-set">}} 是一组 Pod 的属主。
-具有属主的对象是属主的*附属（Dependent）* 。
+具有属主的对象是属主的“附属（Dependent）”。
 
 <!--
 Ownership is different from the [labels and selectors](/docs/concepts/overview/working-with-objects/labels/)
@@ -56,7 +56,7 @@ automatically manage the relationships.
 Kubernetes 自动为一些对象的附属资源设置属主引用的值，
 这些对象包含 ReplicaSet、DaemonSet、Deployment、Job、CronJob、ReplicationController 等。
 你也可以通过改变这个字段的值，来手动配置这些关系。
-然而，你通常不需要这么做，你可以让 Kubernetes 自动管理附属关系。
+然而，通常不需要这么做，你可以让 Kubernetes 自动管理附属关系。
 
 <!--
 Dependent objects also have an `ownerReferences.blockOwnerDeletion` field that