whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
jckling
2022-05-09 19:53:25 +08:00
parent 1bd0ade6a1
commit 0c1e9d10fd
11 changed files with 97 additions and 97 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/overview/components.md
+16 -16
View File
@@ -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
+6 -6
View File
@@ -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
+3 -3
View File
@@ -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
+7 -7
View File
@@ -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
+3 -3
View File
@@ -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
+6 -6
View File
@@ -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/)。
content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+5 -5
View File
@@ -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。
<!--
### Object Spec and Status
@@ -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` 文件作为参数。下面是一个示例：
@@ -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 概念。
content/zh/docs/concepts/overview/working-with-objects/labels.md
+15 -15
View File
@@ -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 对于给定对象必须是唯一的。
<!--
@@ -96,7 +96,7 @@ _标签_ 是键值对。有效的标签键有两个段：可选的前缀和名
向最终用户对象添加标签的自动系统组件（例如 `kube-scheduler`、`kube-controller-manager`、
`kube-apiserver`、`kubectl` 或其他第三方自动化工具）必须指定前缀。
`kubernetes.io/` 和 `k8s.io/` 前缀是为 Kubernetes 核心组件[保留的](/zh/docs/reference/labels-annotations-taints/)。
`kubernetes.io/` 和 `k8s.io/` 前缀是为 Kubernetes 核心组件 [保留的](/zh/docs/reference/labels-annotations-taints/)。
<!--
Valid label value:
@@ -109,7 +109,7 @@ Valid label value:
* 必须为 63 个字符或更少（可以为空）
* 除非标签值为空，必须以字母数字字符（`[a-z0-9A-Z]`）开头和结尾
* 包含破折号（`-`）、下划线（`_`）、点（`.`）和字母或数字。
* 包含破折号（`-`）、下划线（`_`）、点（`.`）和字母或数字
<!--
## Label selectors
@@ -118,7 +118,7 @@ Unlike [names and UIDs](/docs/user-guide/identifiers), labels do not provide uni
-->
## 标签选择算符 {#label-selectors}
与[名称和 UID](/zh/docs/concepts/overview/working-with-objects/names/) 不同，
与 [名称和 UID](/zh/docs/concepts/overview/working-with-objects/names/) 不同，
标签不支持唯一性。通常，我们希望许多对象携带相同的标签。
<!--
@@ -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+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
* _基于等值_ 的需求：`?labelSelector=environment%3Dproduction,tier%3Dfrontend`
* _基于集合_ 的需求：`?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`。
@@ -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/) 文档。
content/zh/docs/concepts/overview/working-with-objects/names.md
+16 -16
View File
@@ -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`。
<!--
For non-unique user-provided attributes, Kubernetes provides [labels](/docs/user-guide/labels) and [annotations](/docs/concepts/overview/working-with-objects/annotations/).
-->
对于用户提供的非唯一性的属性，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/) 机制。
<!-- body -->
@@ -70,9 +70,9 @@ DNS 子域名的定义可参见 [RFC 1123](https://tools.ietf.org/html/rfc1123)
这一要求意味着名称必须满足如下规则：
- 不能超过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" %}}
@@ -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) 的设计文档
content/zh/docs/concepts/overview/working-with-objects/namespaces.md
+11 -11
View File
@@ -18,7 +18,7 @@ weight: 30
<!--
In Kubernetes, _namespaces_ provides a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_.
-->
在 Kubernetes 中，“名字空间（Namespace）”提供一种机制，将同一集群中的资源划分为相互隔离的组。
在 Kubernetes 中，_名字空间（Namespace）_ 提供一种机制，将同一集群中的资源划分为相互隔离的组。
同一名字空间内的资源名称要唯一，但跨名字空间时没有这个要求。
名字空间作用域仅针对带有名字空间的对象，例如 Deployment、Service 等，
这种作用域对集群访问的对象不适用，例如 StorageClass、Node、PersistentVolume 等。
@@ -49,7 +49,7 @@ resource can only be in one namespace.
<!--
Namespaces are a way to divide cluster resources between multiple users (via [resource quota](/docs/concepts/policy/resource-quotas/)).
-->
名字空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/zh/docs/concepts/policy/resource-quotas/)）。
名字空间是在多个用户之间划分集群资源的一种方法（通过 [资源配额](/zh/docs/concepts/policy/resource-quotas/)）。
<!--
It is not necessary to use multiple namespaces to separate slightly different
@@ -58,7 +58,7 @@ resources, such as different versions of the same software: use
resources within the same namespace.
-->
不必使用多个名字空间来分隔仅仅轻微不同的资源，例如同一软件的不同版本：
应该使用{{< glossary_tooltip text="标签" term_id="label" >}}
应该使用 {{< glossary_tooltip text="标签" term_id="label" >}}
来区分同一名字空间中的不同资源。
<!--
@@ -69,7 +69,7 @@ for namespaces](/docs/tasks/administer-cluster/namespaces/).
-->
## 使用名字空间
名字空间的创建和删除在[名字空间的管理指南文档](/zh/docs/tasks/administer-cluster/namespaces/)描述。
名字空间的创建和删除在 [名字空间的管理指南文档](/zh/docs/tasks/administer-cluster/namespaces/) 描述。
<!--
Avoid creating namespaces with the prefix `kube-`, since it is reserved for Kubernetes system namespaces.
@@ -117,8 +117,8 @@ Kubernetes 会创建四个初始名字空间：
这个名字空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。
这个名字空间的公共方面只是一种约定，而不是要求。
* `kube-node-lease` 此名字空间用于与各个节点相关的
[租约（Lease）](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)对象。
节点租期允许 kubelet 发送[心跳](/zh/docs/concepts/architecture/nodes/#heartbeats)，由此控制面能够检测到节点故障。
[租约（Lease）](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 对象。
节点租期允许 kubelet 发送 [心跳](/zh/docs/concepts/architecture/nodes/#heartbeats)，由此控制面能够检测到节点故障。
<!--
### Setting the namespace for a request
@@ -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/)。
<!--
@@ -190,7 +190,7 @@ namespaces can have short DNS names that overlap with public DNS records.
Workloads from any namespace performing a DNS lookup without a [trailing dot](https://datatracker.ietf.org/doc/html/rfc1034#page-8) will
be redirected to those services, taking precedence over public DNS.
-->
通过创建与[公共顶级域名](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)。
content/zh/docs/concepts/overview/working-with-objects/owners-dependents.md
+9 -9
View File
@@ -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/)
@@ -31,7 +31,7 @@ to the labels, each `EndpointSlice` that is managed on behalf of a Service has
an owner reference. Owner references help different parts of Kubernetes avoid
interfering with objects they don’t control.
-->
属主关系不同于一些资源使用的[标签和选择算符](/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 自动管理附属关系。
<!--
Dependent objects also have an `ownerReferences.blockOwnerDeletion` field that
@@ -74,7 +74,7 @@ prevents unauthorized users from delaying owner object deletion.
-->
附属对象还有一个 `ownerReferences.blockOwnerDeletion` 字段，该字段使用布尔值，
用于控制特定的附属对象是否可以阻止垃圾收集删除其属主对象。
如果{{<glossary_tooltip text="控制器" term_id="controller">}}（例如 Deployment 控制器）
如果 {{<glossary_tooltip text="控制器" term_id="controller">}}（例如 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 参考文档。