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

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
+10 -10
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">}})。
<!--
@@ -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
@@ -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/)
@@ -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
@@ -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
@@ -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 notinqa)` 来实现。
`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 inproduction``!=``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
@@ -18,7 +18,7 @@ For example, you can only have one Pod named `myapp-1234` within the same [names
每个 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/).
@@ -71,8 +71,8 @@ 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
@@ -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" %}}
@@ -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 等。
@@ -150,7 +150,7 @@ context.
```shell
kubectl config set-context --current --namespace=<名字空间名称>
# 验证
# 验证
kubectl config view | grep namespace:
```
@@ -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