知名标签(Label)、注解(Annotation)和 Taints
Kubernetes 保留了 kubernetes.io 命名空间下的所有标签和注解。
本文既作为这些标签和注解的参考,也就这些标签和注解的赋值进行了说明。
- kubernetes.io/arch
- kubernetes.io/os
- beta.kubernetes.io/arch (已弃用)
- beta.kubernetes.io/os (已弃用)
- kubernetes.io/hostname
- beta.kubernetes.io/instance-type (已弃用)
- node.kubernetes.io/instance-type
- failure-domain.beta.kubernetes.io/region (已弃用)
- failure-domain.beta.kubernetes.io/zone (已弃用)
- topology.kubernetes.io/region
- topology.kubernetes.io/zone
kubernetes.io/arch
示例:kubernetes.io/arch=amd64
用于:Node
Kubelet 用 Go 中定义的 runtime.GOARCH
值来填充该标签。这在诸如混用 arm 和 x86 节点的情况下很有用。
kubernetes.io/os
示例:kubernetes.io/os=linux
用于:Node
Kubelet 用该 Go 中定义的 runtime.GOOS
值来填充该标签。这在集群中存在不同操作系统的节点时很有用(例如:混合 Linux 和 Windows 操作系统的节点)。
beta.kubernetes.io/arch (已弃用)
该标签已被弃用。请使用 kubernetes.io/arch
。
beta.kubernetes.io/os (已弃用)
该标签已被弃用。请使用 kubernetes.io/arch
。
kubernetes.io/hostname
示例:kubernetes.io/hostname=ip-172-20-114-199.ec2.internal
用于:Node
Kubelet 用 hostname 值来填充该标签。注意:可以通过向 kubelet
传入 --hostname-override
参数对 “真正的” hostname 进行修改。
beta.kubernetes.io/instance-type (已弃用)
注意:从 kubernetes 1.17 版本开始,不推荐使用此标签,而推荐使用node.kubernetes.io/instance-type。
node.kubernetes.io/instance-type
示例:node.kubernetes.io/instance-type=m3.medium
用于:Node
Kubelet 用 cloudprovider
中定义的实例类型来填充该标签。未使用 cloudprovider
时不会设置该标签。该标签在想要将某些负载定向到特定实例类型的节点上时会很有用,但通常用户更希望依赖 Kubernetes 调度器来执行基于资源的调度,所以用户应该致力于基于属性而不是实例类型来进行调度(例如:需要一个 GPU,而不是 g2.2xlarge
)。
failure-domain.beta.kubernetes.io/region (已弃用)
参考 failure-domain.beta.kubernetes.io/zone。
注意:从 kubernetes 1.17 版本开始,不推荐使用此标签,而推荐使用topology.kubernetes.io/region。
failure-domain.beta.kubernetes.io/zone (已弃用)
示例:
failure-domain.beta.kubernetes.io/region=us-east-1
failure-domain.beta.kubernetes.io/zone=us-east-1c
用于:Node、PersistentVolume
对于 Node: Kubelet 用 cloudprovider
中定义的区域(zone)信息来填充该标签。未使用 cloudprovider
时不会设置该标签,但如果该标签在你的拓扑中有意义的话,应该考虑设置。
用于 PersistentVolume:在 GCE 和 AWS 中,PersistentVolumeLabel
准入控制器会自动添加区域标签。
在单区的集群中,Kubernetes 会自动将同一副本控制器或服务下的 pod 分散到不同的节点上 (以降低故障的影响)。在多区的集群中,这种分散的行为扩展到跨区的层面 (以降低区域故障的影响)。跨区分散通过 SelectorSpreadPriority 来实现。
SelectorSpreadPriority 是一种尽力而为(best-effort)的处理方式,如果集群中的区域是异构的 (例如:不同区域之间的节点数量、节点类型或 pod 资源需求不同),可能使得 pod 在各区域间无法均匀分布。如有需要,用户可以使用同质的区域(节点数量和类型相同) 来减小 pod 分布不均的可能性。
由于卷不能跨区域挂载(attach),调度器 (通过 VolumeZonePredicate 预选) 也会保证需要特定卷的 pod 被调度到卷所在的区域中。
区域和地域(region)的实际值无关紧要,两者的层次含义也没有严格的定义。最终期望是,除非整个地域故障, 否则某一区域节点的故障不应该影响到其他区域的节点。例如,通常区域间应该避免共用同一个网络交换机。 具体的规划取决于特定的基础设备 - three-rack 设备所选择的设置与多数据中心截然不同。
如果 PersistentVolumeLabel
准入控制器不支持自动为 PersistentVolume 打标签,且用户希望防止 pod
跨区域进行卷的挂载,应考虑手动打标签 (或对 PersistentVolumeLabel
增加支持)。如果用户的基础设施没有这种约束,则不需要为卷添加区域标签。
注意:从 kubernetes 1.17 版本开始,不推荐使用此标签,而推荐使用topology.kubernetes.io/zone。
topology.kubernetes.io/region
参考 topology.kubernetes.io/zone。
topology.kubernetes.io/zone
示例:
failure-domain.beta.kubernetes.io/region=us-east-1
failure-domain.beta.kubernetes.io/zone=us-east-1c
用于:Node、PersistentVolume
对于 Node: Kubelet 用 cloudprovider
中定义的区域(zone)信息来填充该标签。未使用 cloudprovider
时不会设置该标签,但如果该标签在你的拓扑中有意义的话,应该考虑设置。
用于 PersistentVolume:在 GCE 和 AWS 中,PersistentVolumeLabel
准入控制器会自动添加区域标签。
在单区的集群中,Kubernetes 会自动将同一副本控制器或服务下的 pod 分散到不同的节点上 (以降低故障的影响)。在多区的集群中,这种分散的行为扩展到跨区的层面 (以降低区域故障的影响)。跨区分散通过 SelectorSpreadPriority 来实现。
SelectorSpreadPriority 是一种尽力而为(best-effort)的处理方式,如果集群中的区域是异构的 (例如:不同区域之间的节点数量、节点类型或 pod 资源需求不同),可能使得 pod 在各区域间无法均匀分布。 如有需要,用户可以使用同质的区域(节点数量和类型相同) 来减小 pod 分布不均的可能性。
由于卷不能跨区域挂载(attach),调度器 (通过 VolumeZonePredicate 预选) 也会保证需要特定卷的 pod 被调度到卷所在的区域中。
区域和地域(region)的实际值无关紧要,两者的层次含义也没有严格的定义。最终期望是,除非整个地域故障, 否则某一区域节点的故障不应该影响到其他区域的节点。例如,通常区域间应该避免共用同一个网络交换机。 具体的规划取决于特定的基础设备 - three-rack 设备所选择的设置与多数据中心截然不同。
如果 PersistentVolumeLabel
准入控制器不支持自动为 PersistentVolume 打标签,且用户希望防止 pod 跨区域进行卷的挂载,
应考虑手动打标签 (或对 PersistentVolumeLabel
增加支持)。如果用户的基础设施没有这种约束,则不需要为卷添加区域标签。
反馈
此页是否对您有帮助?
感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题,可以访问 Stack Overflow. 在 GitHub 仓库上登记新的问题 报告问题 或者 提出改进建议.