diff --git a/content/zh/docs/concepts/overview/components.md b/content/zh/docs/concepts/overview/components.md index f67ee07b6e..cb88373eb7 100644 --- a/content/zh/docs/concepts/overview/components.md +++ b/content/zh/docs/concepts/overview/components.md @@ -33,7 +33,7 @@ a complete and working Kubernetes cluster. --> -当你部署完 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">}}）。 -这些控制器包括: +这些控制器包括： -* 节点控制器（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 访问令牌 * 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/) -* 开始 [Kubernetes 入门](/zh/docs/setup/)? +* 开始 [Kubernetes 入门](/zh/docs/setup/)？ diff --git a/content/zh/docs/concepts/overview/working-with-objects/annotations.md b/content/zh/docs/concepts/overview/working-with-objects/annotations.md index 053fbbc341..4d2ff7fc6f 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/annotations.md +++ b/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 中的键和值必须是字符串。 -以下是一些例子，用来说明哪些信息可以使用注解来记录: +以下是一些例子，用来说明哪些信息可以使用注解来记录： -`kubernetes.io/` 和 `k8s.io/` 前缀是为Kubernetes核心组件保留的。 +`kubernetes.io/` 和 `k8s.io/` 前缀是为 Kubernetes 核心组件保留的。 例如，下面是一个 Pod 的配置文件，其注解中包含 `imageregistry: https://hub.docker.com/`： diff --git a/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md b/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md index bfd155fb73..f5a78976da 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/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 diff --git a/content/zh/docs/concepts/overview/working-with-objects/finalizers.md b/content/zh/docs/concepts/overview/working-with-objects/finalizers.md index 88bcad1413..6a0a784fcf 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/finalizers.md +++ b/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 需要清理。 diff --git a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 8d320064d1..23afa65eab 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/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` 文件作为参数。下面是一个示例： diff --git a/content/zh/docs/concepts/overview/working-with-objects/labels.md b/content/zh/docs/concepts/overview/working-with-objects/labels.md index 618b09eb12..a1840bacbd 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/labels.md +++ b/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/)记录非识别信息。 @@ -72,7 +72,7 @@ Example labels: -有一些[常用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)的例子; 你可以任意制定自己的约定。 +有一些[常用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)的例子；你可以任意制定自己的约定。 请记住，标签的 Key 对于给定对象必须是唯一的。 _基于集合_ 的标签选择算符是相等标签选择算符的一般形式，因为 `environment=production` -等同于 `environment in（production）`；`!=` 和 `notin` 也是类似的。 +等同于 `environment in (production)`；`!=` 和 `notin` 也是类似的。 -* _基于等值_ 的需求: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` -* _基于集合_ 的需求: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` +* _基于等值_ 的需求：`?labelSelector=environment%3Dproduction,tier%3Dfrontend` +* _基于集合_ 的需求：`?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` -这个选择算符(分别在 `json` 或者 `yaml` 格式中) 等价于 `component=redis` 或 `component in (redis)` 。 +这个选择算符（分别在 `json` 或者 `yaml` 格式中）等价于 `component=redis` 或 `component in (redis)`。 `matchLabels` 是由 `{key,value}` 对组成的映射。 -`matchLabels` 映射中的单个 `{key,value }` 等同于 `matchExpressions` 的元素， +`matchLabels` 映射中的单个 `{key,value}` 等同于 `matchExpressions` 的元素， 其 `key` 字段为 "key"，`operator` 为 "In"，而 `values` 数组仅包含 "value"。 `matchExpressions` 是 Pod 选择算符需求的列表。 有效的运算符包括 `In`、`NotIn`、`Exists` 和 `DoesNotExist`。 diff --git a/content/zh/docs/concepts/overview/working-with-objects/names.md b/content/zh/docs/concepts/overview/working-with-objects/names.md index 131ce0c6ba..e7ccb39110 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/names.md +++ b/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`。 -下面是一个名为`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" %}} diff --git a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md index e57a82a972..62d47ad897 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md +++ b/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/)。 大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些名字空间中。 但是名字空间资源本身并不在名字空间中。而且底层资源，例如 -[节点](/zh/docs/concepts/architecture/nodes/) 和持久化卷不属于任何名字空间。 +[节点](/zh/docs/concepts/architecture/nodes/)和持久化卷不属于任何名字空间。 -在 Kubernetes 中，一些对象是其他对象的*属主（Owner）*。 +在 Kubernetes 中，一些对象是其他对象的“属主（Owner）”。 例如，{{}} 是一组 Pod 的属主。 -具有属主的对象是属主的*附属（Dependent）* 。 +具有属主的对象是属主的“附属（Dependent）”。