From 0c1e9d10fdea178409fb2ceaf13a5b3ee6853a32 Mon Sep 17 00:00:00 2001 From: jckling Date: Mon, 9 May 2022 19:53:25 +0800 Subject: [PATCH] [zh]update content/zh/docs/concepts/overview --- .../zh/docs/concepts/overview/components.md | 32 +++++++++---------- .../docs/concepts/overview/kubernetes-api.md | 12 +++---- .../concepts/overview/what-is-kubernetes.md | 6 ++-- .../working-with-objects/annotations.md | 14 ++++---- .../working-with-objects/field-selectors.md | 6 ++-- .../working-with-objects/finalizers.md | 12 +++---- .../kubernetes-objects.md | 10 +++--- .../overview/working-with-objects/labels.md | 30 ++++++++--------- .../overview/working-with-objects/names.md | 32 +++++++++---------- .../working-with-objects/namespaces.md | 22 ++++++------- .../working-with-objects/owners-dependents.md | 18 +++++------ 11 files changed, 97 insertions(+), 97 deletions(-) diff --git a/content/zh/docs/concepts/overview/components.md b/content/zh/docs/concepts/overview/components.md index f67ee07b6e..c4084b8ae6 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 访问令牌 -* 进一步了解[节点](/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/) diff --git a/content/zh/docs/concepts/overview/kubernetes-api.md b/content/zh/docs/concepts/overview/kubernetes-api.md index 61cf1a2c2e..61acf3f1f1 100644 --- a/content/zh/docs/concepts/overview/kubernetes-api.md +++ b/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/) 之一。 @@ -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 特性。 关于 API 版本分级的定义细节，请参阅 -[API 版本参考](/zh/docs/reference/using-api/#api-versioning)页面。 +[API 版本参考](/zh/docs/reference/using-api/#api-versioning) 页面。 -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。 diff --git a/content/zh/docs/concepts/overview/what-is-kubernetes.md b/content/zh/docs/concepts/overview/what-is-kubernetes.md index 9d2f772089..4c7bb14b20 100644 --- a/content/zh/docs/concepts/overview/what-is-kubernetes.md +++ b/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/)？ 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..0a40fd3f93 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/`： @@ -163,5 +163,5 @@ spec: -* 进一步了解[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。 +* 进一步了解 [标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。 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..6defb45228 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 @@ -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： 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..a5ec9e0108 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/finalizers.md +++ b/content/zh/docs/concepts/overview/working-with-objects/finalizers.md @@ -13,9 +13,9 @@ You can use finalizers to control {{}} to perform specific cleanup tasks before deleting the target resource. --> -你可以通过使用 Finalizers 提醒{{}} +你可以通过使用 Finalizers 提醒 {{}} 在删除目标资源前执行特定的清理任务， -来控制资源的{{}}。 +来控制资源的 {{}}。 ## 属主引用、标签和 Finalizers {#owners-labels-finalizers} -与{{}}类似， +与 {{}} 类似， [属主引用](/zh/concepts/overview/working-with-objects/owners-dependents/) 描述了 Kubernetes 中对象之间的关系，但它们作用不同。 -当一个{{}} +当一个 {{}} 管理类似于 Pod 的对象时，它使用标签来跟踪相关对象组的变化。 例如，当 {{}} 创建一个或多个 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/)。 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..aa1bd7ec1a 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 @@ -55,7 +55,7 @@ Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernete [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api)。 比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用， 也可以在程序中使用 -[客户端库](/zh/docs/reference/using-api/client-libraries/)直接调用 Kubernetes API。 +[客户端库](/zh/docs/reference/using-api/client-libraries/) 直接调用 Kubernetes API。 -使用类似于上面的 `.yaml` 文件来创建 Deployment的一种方式是使用 `kubectl` 命令行接口（CLI）中的 +使用类似于上面的 `.yaml` 文件来创建 Deployment 的一种方式是使用 `kubectl` 命令行接口（CLI）中的 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 命令， 将 `.yaml` 文件作为参数。下面是一个示例： @@ -199,7 +199,7 @@ detail the structure of that `.status` field, and its content for each different 另一个对象规约的例子是 StatefulSet API 中的 [`spec` 字段](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec)。 对于 StatefulSet 而言，其 `.spec` 字段设置了 StatefulSet 及其期望状态。 -在 StatefulSet 的 `.spec` 内，有一个为 Pod 对象提供的[模板](/zh/docs/concepts/workloads/pods/#pod-templates)。该模板描述了 StatefulSet 控制器为了满足 StatefulSet 规约而要创建的 Pod。 +在 StatefulSet 的 `.spec` 内，有一个为 Pod 对象提供的 [模板](/zh/docs/concepts/workloads/pods/#pod-templates)。该模板描述了 StatefulSet 控制器为了满足 StatefulSet 规约而要创建的 Pod。 不同类型的对象可以由不同的 `.status` 信息。API 参考页面给出了 `.status` 字段的详细结构， 以及针对不同类型 API 对象的具体内容。 @@ -211,6 +211,6 @@ detail the structure of that `.status` field, and its content for each different * [Using the Kubernetes API](/docs/reference/using-api/) explains some more API concepts. --> * 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh/docs/concepts/workloads/pods/)。 -* 了解 Kubernetes 中的[控制器](/zh/docs/concepts/architecture/controller/)。 +* 了解 Kubernetes 中的 [控制器](/zh/docs/concepts/architecture/controller/)。 * [使用 Kubernetes API](/zh/docs/reference/using-api/) 一节解释了一些 API 概念。 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..387c770c67 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 对于给定对象必须是唯一的。 ## 标签选择算符 {#label-selectors} -与[名称和 UID](/zh/docs/concepts/overview/working-with-objects/names/) 不同， +与 [名称和 UID](/zh/docs/concepts/overview/working-with-objects/names/) 不同， 标签不支持唯一性。通常，我们希望许多对象携带相同的标签。 _基于集合_ 的标签选择算符是相等标签选择算符的一般形式，因为 `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`。 @@ -400,5 +400,5 @@ See the documentation on [node selection](/docs/concepts/configuration/assign-po #### 选择节点集 通过标签进行选择的一个用例是确定节点集，方便 Pod 调度。 -有关更多信息，请参阅[选择节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)文档。 +有关更多信息，请参阅 [选择节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) 文档。 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..d59214ca0c 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/names.md +++ b/content/zh/docs/concepts/overview/working-with-objects/names.md @@ -13,19 +13,19 @@ 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`. +比如，在同一个 [名字空间](/zh/docs/concepts/overview/working-with-objects/namespaces/) +中有一个名为 `myapp-1234` 的 Pod，但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`。 对于用户提供的非唯一性的属性，Kubernetes 提供了 -[标签（Labels）](/zh/docs/concepts/working-with-objects/labels)和 -[注解（Annotation）](/zh/docs/concepts/overview/working-with-objects/annotations/)机制。 +[标签（Labels）](/zh/docs/concepts/working-with-objects/labels) 和 +[注解（Annotation）](/zh/docs/concepts/overview/working-with-objects/annotations/) 机制。 @@ -70,9 +70,9 @@ DNS 子域名的定义可参见 [RFC 1123](https://tools.ietf.org/html/rfc1123) 这一要求意味着名称必须满足如下规则： - 不能超过253个字符 -- 只能包含小写字母、数字，以及'-' 和 '.' -- 须以字母数字开头 -- 须以字母数字结尾 +- 只能包含小写字母、数字，以及 '-' 和 '.' +- 必须以字母数字开头 +- 必须以字母数字结尾 -下面是一个名为`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" %}} @@ -174,6 +174,6 @@ UUIDs 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667. * See the [Identifiers and Names in Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) design document. --> * 进一步了解 Kubernetes [标签](/zh/docs/concepts/overview/working-with-objects/labels/) -* 参阅 [Kubernetes 标识符和名称](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)的设计文档 +* 参阅 [Kubernetes 标识符和名称](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) 的设计文档 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..8d7deae7d5 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md @@ -18,7 +18,7 @@ weight: 30 -在 Kubernetes 中，“名字空间（Namespace）”提供一种机制，将同一集群中的资源划分为相互隔离的组。 +在 Kubernetes 中，_名字空间（Namespace）_ 提供一种机制，将同一集群中的资源划分为相互隔离的组。 同一名字空间内的资源名称要唯一，但跨名字空间时没有这个要求。 名字空间作用域仅针对带有名字空间的对象，例如 Deployment、Service 等， 这种作用域对集群访问的对象不适用，例如 StorageClass、Node、PersistentVolume 等。 @@ -49,7 +49,7 @@ resource can only be in one namespace. -名字空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/zh/docs/concepts/policy/resource-quotas/)）。 +名字空间是在多个用户之间划分集群资源的一种方法（通过 [资源配额](/zh/docs/concepts/policy/resource-quotas/)）。 不必使用多个名字空间来分隔仅仅轻微不同的资源，例如同一软件的不同版本： -应该使用{{< glossary_tooltip text="标签" term_id="label" >}} +应该使用 {{< glossary_tooltip text="标签" term_id="label" >}} 来区分同一名字空间中的不同资源。 ## 使用名字空间 -名字空间的创建和删除在[名字空间的管理指南文档](/zh/docs/tasks/administer-cluster/namespaces/)描述。 +名字空间的创建和删除在 [名字空间的管理指南文档](/zh/docs/tasks/administer-cluster/namespaces/) 描述。 ## 名字空间和 DNS -当你创建一个[服务](/zh/docs/concepts/services-networking/service/) 时， +当你创建一个 [服务](/zh/docs/concepts/services-networking/service/) 时， Kubernetes 会创建一个相应的 [DNS 条目](/zh/docs/concepts/services-networking/dns-pod-service/)。 -通过创建与[公共顶级域名](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) +通过创建与 [公共顶级域名](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) 同名的名字空间，这些名字空间中的服务可以拥有与公共 DNS 记录重叠的、较短的 DNS 名称。 所有名字空间中的负载在执行 DNS 查找时，如果查找的名称没有 [尾部句点](https://datatracker.ietf.org/doc/html/rfc1034#page-8)， @@ -264,5 +264,5 @@ Kubernetes 控制面会为所有名字空间设置一个不可变更的 * Learn more about [creating a new namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace). * Learn more about [deleting a namespace](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace). --> -* 进一步了解[建立新的名字空间](/zh/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)。 -* 进一步了解[删除名字空间](/zh/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)。 +* 进一步了解 [建立新的名字空间](/zh/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)。 +* 进一步了解 [删除名字空间](/zh/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)。 diff --git a/content/zh/docs/concepts/overview/working-with-objects/owners-dependents.md b/content/zh/docs/concepts/overview/working-with-objects/owners-dependents.md index b5e8228bd3..d1d4945294 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/owners-dependents.md +++ b/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）*。 例如，{{}} 是一组 Pod 的属主。 -具有属主的对象是属主的*附属（Dependent）* 。 +具有属主的对象是属主的 *附属（Dependent）*。 -属主关系不同于一些资源使用的[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)机制。 +属主关系不同于一些资源使用的 [标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/) 机制。 例如，有一个创建 `EndpointSlice` 对象的 Service， 该 Service 使用标签来让控制平面确定，哪些 `EndpointSlice` 对象属于该 Service。 除开标签，每个代表 Service 所管理的 `EndpointSlice` 都有一个属主引用。 @@ -56,7 +56,7 @@ automatically manage the relationships. Kubernetes 自动为一些对象的附属资源设置属主引用的值， 这些对象包含 ReplicaSet、DaemonSet、Deployment、Job、CronJob、ReplicationController 等。 你也可以通过改变这个字段的值，来手动配置这些关系。 -然而，你通常不需要这么做，你可以让 Kubernetes 自动管理附属关系。 +然而，通常不需要这么做，你可以让 Kubernetes 自动管理附属关系。 附属对象还有一个 `ownerReferences.blockOwnerDeletion` 字段，该字段使用布尔值， 用于控制特定的附属对象是否可以阻止垃圾收集删除其属主对象。 -如果{{}}（例如 Deployment 控制器） +如果 {{}}（例如 Deployment 控制器） 设置了 `metadata.ownerReferences` 字段的值，Kubernetes 会自动设置 `blockOwnerDeletion` 的值为 `true`。 你也可以手动设置 `blockOwnerDeletion` 字段的值，以控制哪些附属对象会阻止垃圾收集。 @@ -99,7 +99,7 @@ You can check for that kind of Event by running --> 根据设计，kubernetes 不允许跨名字空间指定属主。 名字空间范围的附属可以指定集群范围的或者名字空间范围的属主。 -名字空间范围的属主**必须**和该附属处于相同的名字空间。 +名字空间范围的属主 **必须** 和该附属处于相同的名字空间。 如果名字空间范围的属主和附属不在相同的名字空间，那么该属主引用就会被认为是缺失的， 并且当附属的所有属主引用都被确认不再存在之后，该附属就会被删除。 @@ -150,7 +150,7 @@ specify an orphan deletion policy, Kubernetes adds the `orphan` finalizer so that the controller ignores dependent resources after it deletes the owner object. --> -当你使用[前台或孤立级联删除](/zh/docs/concepts/architecture/garbage-collection/#cascading-deletion)时， +当你使用 [前台或孤立级联删除](/zh/docs/concepts/architecture/garbage-collection/#cascading-deletion) 时， Kubernetes 也会向属主资源添加 Finalizer。 在前台删除中，会添加 `foreground` Finalizer，这样控制器必须在删除了拥有 `ownerReferences.blockOwnerDeletion=true` 的附属资源后，才能删除属主对象。 @@ -165,5 +165,5 @@ Kubernetes 也会向属主资源添加 Finalizer。 * Read the API reference for [object metadata](/docs/reference/kubernetes-api/common-definitions/object-meta/#System). --> * 了解更多关于 [Kubernetes Finalizer](/zh/docs/concepts/overview/working-with-objects/finalizers/)。 -* 了解关于[垃圾收集](/zh/docs/concepts/architecture/garbage-collection)。 -* 阅读[对象元数据](/docs/reference/kubernetes-api/common-definitions/object-meta/#System)的 API 参考文档。 +* 了解关于 [垃圾收集](/zh/docs/concepts/architecture/garbage-collection)。 +* 阅读 [对象元数据](/docs/reference/kubernetes-api/common-definitions/object-meta/#System) 的 API 参考文档。