Skip to content

Commit 8b961c4

Browse files
tanjunchenk8s-ci-robot
authored andcommitted
update zh-trans content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md (#18449)
1 parent 59a42b1 commit 8b961c4

File tree

1 file changed

+220
-48
lines changed

1 file changed

+220
-48
lines changed
Lines changed: 220 additions & 48 deletions
Original file line numberDiff line numberDiff line change
@@ -1,103 +1,275 @@
11
---
22
title: 知名标签(Label)、注解(Annotation)和 Taints
3+
content_template: templates/concept
4+
weight: 60
35
---
46

5-
Kubernetes 保留了 kubernetes.io 名字空间下的所有标签和注解。 本文描述了知名的
6-
kubernetes.io 标签和注解。
7+
{{% capture overview %}}
78

8-
本文既作为这些标签和注解值的参考,也就这些标签和注解的赋值进行了说明。
9+
<!--
10+
Kubernetes reserves all labels and annotations in the kubernetes.io namespace.
911
10-
**目录:**
11-
<!-- BEGIN MUNGE: GENERATED_TOC -->
12+
This document serves both as a reference to the values and as a coordination point for assigning values.
13+
-->
1214

13-
- [beta.kubernetes.io/arch](#betakubernetesioarch)
14-
- [beta.kubernetes.io/os](#betakubernetesioos)
15-
- [kubernetes.io/hostname](#kubernetesiohostname)
16-
- [beta.kubernetes.io/instance-type](#betakubernetesioinstance-type)
17-
- [failure-domain.beta.kubernetes.io/region](#failure-domainbetakubernetesioregion)
18-
- [failure-domain.beta.kubernetes.io/zone](#failure-domainbetakubernetesiozone)
15+
Kubernetes 保留了 kubernetes.io 命名空间下的所有标签和注解。
1916

20-
<!-- END MUNGE: GENERATED_TOC -->
17+
本文既作为这些标签和注解的参考,也就这些标签和注解的赋值进行了说明。
2118

19+
{{% /capture %}}
2220

23-
## beta.kubernetes.io/arch
21+
{{% capture body %}}
2422

25-
示例:`beta.kubernetes.io/arch=amd64`
23+
## kubernetes.io/arch
2624

27-
用于:节点
25+
<!--
26+
Example: `kubernetes.io/arch=amd64`
2827
29-
Kubelet 用 Go 中定义的 `runtime.GOARCH` 值来填充该标签。 这在诸如混用 arm 和 x86 节点的情况下很有用。
28+
Used on: Node
3029
31-
## beta.kubernetes.io/os
30+
The Kubelet populates this with `runtime.GOARCH` as defined by Go. This can be handy if you are mixing arm and x86 nodes.
31+
-->
3232

33-
示例:`beta.kubernetes.io/os=linux`
33+
示例:`kubernetes.io/arch=amd64`
3434

35-
用于:节点
35+
用于:Node
3636

37-
Kubelet 用该 Go 中定义的 `runtime.GOOS` 值来填充该标签。 这在集群中存在不同操作系统的节点时很有用(尽管当前 Kubernetes 只支持 Linux 操作系统)。
37+
Kubelet 用 Go 中定义的 `runtime.GOARCH` 值来填充该标签。这在诸如混用 arm 和 x86 节点的情况下很有用。
38+
39+
## kubernetes.io/os
40+
41+
<!--
42+
Example: `kubernetes.io/os=linux`
43+
44+
Used on: Node
45+
46+
The Kubelet populates this with `runtime.GOOS` as defined by Go. This can be handy if you are mixing operating systems in your cluster (for example: mixing Linux and Windows nodes).
47+
-->
48+
49+
示例:`kubernetes.io/os=linux`
50+
51+
用于:Node
52+
53+
Kubelet 用该 Go 中定义的 `runtime.GOOS` 值来填充该标签。这在集群中存在不同操作系统的节点时很有用(例如:混合 Linux 和 Windows 操作系统的节点)。
54+
55+
<!--
56+
## beta.kubernetes.io/arch (deprecated)
57+
-->
58+
## beta.kubernetes.io/arch (已弃用)
59+
60+
<!--
61+
This label has been deprecated. Please use `kubernetes.io/arch` instead.
62+
-->
63+
该标签已被弃用。请使用 `kubernetes.io/arch`
64+
65+
<!--
66+
## beta.kubernetes.io/os (deprecated)
67+
-->
68+
## beta.kubernetes.io/os (已弃用)
69+
70+
<!--
71+
This label has been deprecated. Please use `kubernetes.io/os` instead.
72+
-->
73+
该标签已被弃用。请使用 `kubernetes.io/arch`
3874

3975
## kubernetes.io/hostname
4076

77+
<!--
78+
Example: `kubernetes.io/hostname=ip-172-20-114-199.ec2.internal`
79+
80+
Used on: Node
81+
82+
The Kubelet populates this label with the hostname. Note that the hostname can be changed from the "actual" hostname by passing the `--hostname-override` flag to the `kubelet`.
83+
-->
84+
4185
示例:`kubernetes.io/hostname=ip-172-20-114-199.ec2.internal`
4286

43-
用于:节点
87+
用于:Node
4488

45-
Kubelet 用 hostname 值来填充该标签。 注意:可以通过向 kubelet 传入 `--hostname-override`
89+
Kubelet 用 hostname 值来填充该标签。注意:可以通过向 `kubelet` 传入 `--hostname-override`
4690
参数对 “真正的” hostname 进行修改。
4791

48-
## beta.kubernetes.io/instance-type
92+
<!--
93+
## beta.kubernetes.io/instance-type (deprecated)
94+
-->
95+
## beta.kubernetes.io/instance-type (已弃用)
96+
97+
{{< note >}}
98+
<!--
99+
Starting in v1.17, this label is deprecated in favor of [node.kubernetes.io/instance-type](#nodekubernetesioinstance-type).
100+
-->
101+
从 kubernetes 1.17 版本开始,不推荐使用此标签,而推荐使用[node.kubernetes.io/instance-type](#nodekubernetesioinstance-type)
102+
{{< /note >}}
103+
104+
## node.kubernetes.io/instance-type {#nodekubernetesioinstance-type}
105+
106+
<!--
107+
Example: `node.kubernetes.io/instance-type=m3.medium`
108+
109+
Used on: Node
110+
111+
The Kubelet populates this with the instance type as defined by the `cloudprovider`.
112+
This will be set only if you are using a `cloudprovider`. This setting is handy
113+
if you want to target certain workloads to certain instance types, but typically you want
114+
to rely on the Kubernetes scheduler to perform resource-based scheduling. You should aim to schedule based on properties rather than on instance types (for example: require a GPU, instead of requiring a `g2.2xlarge`).
115+
-->
116+
117+
示例:`node.kubernetes.io/instance-type=m3.medium`
49118

50-
示例:`beta.kubernetes.io/instance-type=m3.medium`
119+
用于:Node
51120

52-
用于:节点
121+
Kubelet 用 `cloudprovider` 中定义的实例类型来填充该标签。未使用 `cloudprovider` 时不会设置该标签。该标签在想要将某些负载定向到特定实例类型的节点上时会很有用,但通常用户更希望依赖 Kubernetes 调度器来执行基于资源的调度,所以用户应该致力于基于属性而不是实例类型来进行调度(例如:需要一个 GPU,而不是 `g2.2xlarge`)。
53122

54-
Kubelet 用 `cloudprovider` 中定义的实例类型来填充该标签。 未使用 `cloudprovider` 时不会设置该标签。
55-
该标签在想要将某些负载定向到特定实例类型的节点上时会很有用,但通常用户更希望依赖 Kubernetes 调度器来执行基于资源的调度,所以用户应该致力于基于属性而不是实例类型来进行调度(例如:需要一个 CPU,而不是 `g2.2xlarge`)。
123+
## failure-domain.beta.kubernetes.io/region (已弃用) {#failure-domainbetakubernetesioregion}
56124

125+
<!--
126+
See [failure-domain.beta.kubernetes.io/zone](#failure-domainbetakubernetesiozone).
127+
-->
128+
参考 [failure-domain.beta.kubernetes.io/zone](#failure-domainbetakubernetesiozone)
57129

58-
## failure-domain.beta.kubernetes.io/region
130+
{{< note >}}
131+
<!--
132+
Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/region](#topologykubernetesioregion).
133+
-->
134+
从 kubernetes 1.17 版本开始,不推荐使用此标签,而推荐使用[topology.kubernetes.io/region](#topologykubernetesioregion)
135+
{{< /note >}}
59136

60-
参考 [failure-domain.beta.kubernetes.io/zone](#failure-domainbetakubernetesiozone).
137+
## failure-domain.beta.kubernetes.io/zone (已弃用) {#failure-domainbetakubernetesiozone}
61138

62-
## failure-domain.beta.kubernetes.io/zone
139+
<!--
140+
Example:
63141
142+
`failure-domain.beta.kubernetes.io/region=us-east-1`
143+
144+
`failure-domain.beta.kubernetes.io/zone=us-east-1c`
145+
146+
Used on: Node, PersistentVolume
147+
148+
On the Node: The `kubelet` populates this with the zone information as defined by the `cloudprovider`.
149+
This will be set only if you are using a `cloudprovider`. However, you should consider setting this
150+
on the nodes if it makes sense in your topology.
151+
-->
64152
示例:
65153

66154
`failure-domain.beta.kubernetes.io/region=us-east-1`
67155

68156
`failure-domain.beta.kubernetes.io/zone=us-east-1c`
69157

70-
用于:节点、PersistentVolume
158+
用于:Node、PersistentVolume
71159

72-
用于节点: Kubelet 用 `cloudprovider` 中定义的区域(zone)信息来填充该标签。 未使用 `cloudprovider`
73-
时不会设置该标签,但如果该标签在你的拓扑中有意义的话,应该考虑设置。
160+
对于 Node: Kubelet 用 `cloudprovider` 中定义的区域(zone)信息来填充该标签。未使用 `cloudprovider` 时不会设置该标签,但如果该标签在你的拓扑中有意义的话,应该考虑设置。
74161

162+
<!--
163+
On the PersistentVolume: The `PersistentVolumeLabel` admission controller will automatically add zone labels to PersistentVolumes, on GCE and AWS.
164+
-->
75165
用于 PersistentVolume:在 GCE 和 AWS 中,`PersistentVolumeLabel` 准入控制器会自动添加区域标签。
76166

77-
在单区的集群中,Kubernetes 会自动将同一副本控制器或服务下的 pod 分散到不同的节点上 (以降低故障的影响)。
78-
在多区的集群中,这种分散的行为扩展到跨区的层面 (以降低区域故障的影响)。 跨区分散通过 SelectorSpreadPriority
79-
来实现。
167+
<!--
168+
Kubernetes will automatically spread the Pods in a replication controller or service across nodes in a single-zone cluster (to reduce the impact of failures). With multiple-zone clusters, this spreading behaviour is extended across zones (to reduce the impact of zone failures). This is achieved via _SelectorSpreadPriority_.
169+
-->
80170

81-
这是一种尽力而为(best-effort)的处置方式, 如果集群中的区域是异构的 (例如:不同区域之间的节点数量、
82-
节点类型或 pod 资源需求不同),可能使得 pod 在各区域间无法均匀分布。 如有需要,用户可以使用同质的区域
83-
(节点数量和类型相同) 来减小 pod 分布不均的可能性。
171+
在单区的集群中,Kubernetes 会自动将同一副本控制器或服务下的 pod 分散到不同的节点上 (以降低故障的影响)。在多区的集群中,这种分散的行为扩展到跨区的层面 (以降低区域故障的影响)。跨区分散通过 _SelectorSpreadPriority_ 来实现。
84172

85-
由于卷不能跨区域挂载(attach),调度器 (通过 VolumeZonePredicate 断言) 也会保证需要特定卷的 pod
173+
<!--
174+
_SelectorSpreadPriority_ is a best effort placement. If the zones in your cluster are heterogeneous (for example: different numbers of nodes, different types of nodes, or different pod resource requirements), this placement might prevent equal spreading of your Pods across zones. If desired, you can use homogenous zones (same number and types of nodes) to reduce the probability of unequal spreading.
175+
-->
176+
_SelectorSpreadPriority_ 是一种尽力而为(best-effort)的处理方式,如果集群中的区域是异构的 (例如:不同区域之间的节点数量、节点类型或 pod 资源需求不同),可能使得 pod 在各区域间无法均匀分布。如有需要,用户可以使用同质的区域(节点数量和类型相同) 来减小 pod 分布不均的可能性。
177+
178+
<!--
179+
The scheduler (through the _VolumeZonePredicate_ predicate) also will ensure that Pods, that claim a given volume, are only placed into the same zone as that volume. Volumes cannot be attached across zones.
180+
-->
181+
由于卷不能跨区域挂载(attach),调度器 (通过 _VolumeZonePredicate_ 预选) 也会保证需要特定卷的 pod
86182
被调度到卷所在的区域中。
87183

184+
<!--
185+
The actual values of zone and region don't matter. Nor is the node hierarchy rigidly defined.
186+
The expectation is that failures of nodes in different zones should be uncorrelated unless the entire region has failed. For example, zones should typically avoid sharing a single network switch. The exact mapping depends on your particular infrastructure - a three rack installation will choose a very different setup to a multi-datacenter configuration.
187+
-->
188+
区域和地域(region)的实际值无关紧要,两者的层次含义也没有严格的定义。最终期望是,除非整个地域故障,
189+
否则某一区域节点的故障不应该影响到其他区域的节点。例如,通常区域间应该避免共用同一个网络交换机。
190+
具体的规划取决于特定的基础设备 - three-rack 设备所选择的设置与多数据中心截然不同。
191+
192+
<!--
193+
If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, you should consider
194+
adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all.
195+
-->
196+
如果 `PersistentVolumeLabel` 准入控制器不支持自动为 PersistentVolume 打标签,且用户希望防止 pod
197+
跨区域进行卷的挂载,应考虑手动打标签 (或对 `PersistentVolumeLabel` 增加支持)。如果用户的基础设施没有这种约束,则不需要为卷添加区域标签。
88198

89-
区域和地域(region)的实际值无关紧要,两者的层次含义也没有严格的定义。 最终期望是,除非整个地域故障,
90-
否则某一区域节点的故障不应该影响到其他区域的节点。 例如,通常区域间应该避免共用同一个网络交换机。
91-
具体的规划取决于特定的基础设备—— three-rack 设备所选择的设置与多数据中心截然不同。
199+
{{< note >}}
200+
<!--
201+
Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/zone](#topologykubernetesiozone).
202+
-->
203+
从 kubernetes 1.17 版本开始,不推荐使用此标签,而推荐使用[topology.kubernetes.io/zone](#topologykubernetesiozone)
204+
{{< /note >}}
92205

93-
如果 `PersistentVolumeLabel` 准入控制器不支持自动为 PersistentVolume 打标签,且用户希望防止 pod
94-
跨区域进行卷的挂载,应考虑手动打标签 (或对 `PersistentVolumeLabel` 增加支持)。 如果用户的基础设施没有这种约束,则不需要为卷添加区域标签。
206+
## topology.kubernetes.io/region {#topologykubernetesioregion}
207+
208+
<!--
209+
See [topology.kubernetes.io/zone](#topologykubernetesiozone).
210+
-->
211+
参考 [topology.kubernetes.io/zone](#topologykubernetesiozone)
212+
213+
## topology.kubernetes.io/zone {#topologykubernetesiozone}
95214

215+
<!--
216+
Example:
96217
218+
`topology.kubernetes.io/region=us-east-1`
97219
220+
`topology.kubernetes.io/zone=us-east-1c`
98221
222+
Used on: Node, PersistentVolume
99223
224+
On the Node: The `kubelet` populates this with the zone information as defined by the `cloudprovider`.
225+
This will be set only if you are using a `cloudprovider`. However, you should consider setting this
226+
on the nodes if it makes sense in your topology.
227+
-->
228+
示例:
229+
230+
`failure-domain.beta.kubernetes.io/region=us-east-1`
231+
232+
`failure-domain.beta.kubernetes.io/zone=us-east-1c`
233+
234+
用于:Node、PersistentVolume
235+
236+
对于 Node: Kubelet 用 `cloudprovider` 中定义的区域(zone)信息来填充该标签。未使用 `cloudprovider` 时不会设置该标签,但如果该标签在你的拓扑中有意义的话,应该考虑设置。
237+
238+
<!--
239+
On the PersistentVolume: The `PersistentVolumeLabel` admission controller will automatically add zone labels to PersistentVolumes, on GCE and AWS.
240+
-->
241+
用于 PersistentVolume:在 GCE 和 AWS 中,`PersistentVolumeLabel` 准入控制器会自动添加区域标签。
100242

101-
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
102-
[![分析](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/api-reference/labels-annotations-taints.md?pixel)]()
103-
<!-- END MUNGE: GENERATED_ANALYTICS -->
243+
<!--
244+
Kubernetes will automatically spread the Pods in a replication controller or service across nodes in a single-zone cluster (to reduce the impact of failures). With multiple-zone clusters, this spreading behaviour is extended across zones (to reduce the impact of zone failures). This is achieved via _SelectorSpreadPriority_.
245+
-->
246+
在单区的集群中,Kubernetes 会自动将同一副本控制器或服务下的 pod 分散到不同的节点上 (以降低故障的影响)。在多区的集群中,这种分散的行为扩展到跨区的层面 (以降低区域故障的影响)。跨区分散通过 _SelectorSpreadPriority_ 来实现。
247+
248+
<!--
249+
_SelectorSpreadPriority_ is a best effort placement. If the zones in your cluster are heterogeneous (for example: different numbers of nodes, different types of nodes, or different pod resource requirements), this placement might prevent equal spreading of your Pods across zones. If desired, you can use homogenous zones (same number and types of nodes) to reduce the probability of unequal spreading.
250+
-->
251+
_SelectorSpreadPriority_ 是一种尽力而为(best-effort)的处理方式,如果集群中的区域是异构的
252+
(例如:不同区域之间的节点数量、节点类型或 pod 资源需求不同),可能使得 pod 在各区域间无法均匀分布。
253+
如有需要,用户可以使用同质的区域(节点数量和类型相同) 来减小 pod 分布不均的可能性。
254+
255+
<!--
256+
The scheduler (through the _VolumeZonePredicate_ predicate) also will ensure that Pods, that claim a given volume, are only placed into the same zone as that volume. Volumes cannot be attached across zones.
257+
-->
258+
由于卷不能跨区域挂载(attach),调度器 (通过 _VolumeZonePredicate_ 预选) 也会保证需要特定卷的 pod 被调度到卷所在的区域中。
259+
260+
<!--
261+
The actual values of zone and region don't matter. Nor is the node hierarchy rigidly defined.
262+
The expectation is that failures of nodes in different zones should be uncorrelated unless the entire region has failed. For example, zones should typically avoid sharing a single network switch. The exact mapping depends on your particular infrastructure - a three rack installation will choose a very different setup to a multi-datacenter configuration.
263+
-->
264+
区域和地域(region)的实际值无关紧要,两者的层次含义也没有严格的定义。最终期望是,除非整个地域故障,
265+
否则某一区域节点的故障不应该影响到其他区域的节点。例如,通常区域间应该避免共用同一个网络交换机。
266+
具体的规划取决于特定的基础设备 - three-rack 设备所选择的设置与多数据中心截然不同。
267+
268+
<!--
269+
If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, you should consider
270+
adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all.
271+
-->
272+
如果 `PersistentVolumeLabel` 准入控制器不支持自动为 PersistentVolume 打标签,且用户希望防止 pod 跨区域进行卷的挂载,
273+
应考虑手动打标签 (或对 `PersistentVolumeLabel` 增加支持)。如果用户的基础设施没有这种约束,则不需要为卷添加区域标签。
274+
275+
{{% /capture %}}

0 commit comments

Comments
 (0)