知名标签（Label）、注解（Annotation）和 污点（Taint）

Kubernetes 保留了 kubernetes.io 命名空间下的所有标签和注解。

本文档提供这些标签、注解和污点的参考，也可用来协调对这类标签、注解和污点的设置。

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/os。

kubernetes.io/hostname

示例：kubernetes.io/hostname=ip-172-20-114-199.ec2.internal

用于：Node

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

此标签还用作拓扑层次结构的一部分。有关更多信息，请参见 topology.kubernetes.io/zone。

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 (已弃用)

参考 topology.kubernetes.io/region。

说明：

从 kubernetes 1.17 版本开始，不推荐使用此标签，而推荐使用 topology.kubernetes.io/region。

failure-domain.beta.kubernetes.io/zone (已弃用)

参考 topology.kubernetes.io/zone。

说明：

从 kubernetes 1.17 版本开始，不推荐使用此标签，而推荐使用 topology.kubernetes.io/zone。

topology.kubernetes.io/region

示例：

topology.kubernetes.io/region=us-east-1

参考 topology.kubernetes.io/zone。

topology.kubernetes.io/zone

示例：

topology.kubernetes.io/zone=us-east-1c

用于：Node、PersistentVolume

对于 Node： Kubelet 或外部 cloud-controller-manager 用 cloudprovider 中定义的区域信息来填充该标签。 未使用 cloudprovider 时不会设置该标签，但如果该标签在你的拓扑中有意义的话，应该考虑设置。

对于 PersistentVolume：可感知拓扑的卷制备程序将自动在 PersistentVolumes 上设置节点亲和性约束。

区域代表逻辑故障域。Kubernetes 集群通常跨越多个区域以提高可用性。 虽然区域的确切定义留给基础架构实现，但是区域的常见属性包括区域内的网络延迟非常低，区域内的免费网络流量以及与其他区域的故障独立性。 例如，一个区域内的节点可能共享一个网络交换机，但不同区域内的节点则不应共享。

地区代表一个更大的域，由一个或多个区域组成。 Kubernetes 集群跨越多个地域是不常见的，而地域或区域的确切定义则留给基础设施实现， 地域的共同属性包括它们之间的网络延迟比它们内部更高，它们之间的网络流量成本不为零，故障独立于其他区域或域。 例如，一个地域内的节点可能共享电力基础设施（例如 UPS 或发电机），但不同地域的节点通常不会共享。

Kubernetes 对区域和区域的结构做了一些假设:

1. 地域和区域是分层的:区域是地域的严格子集，任何区域都不能位于两个地域中。
2. 区域名称在地域之间是唯一的；例如，地域 “africa-east-1” 可能包含区域 “africa-east-1a” 和 “africa-east-1b”。

标签的使用者可以安全地假设拓扑标签不变。 即使标签是严格可变的，标签的使用者也可以认为节点只能通过被销毁并重建才能从一个区域迁移到另一个区域。

Kubernetes 可以以各种方式使用这些信息。 例如，调度器自动尝试将 ReplicaSet 中的多个 Pods 分布到单区域集群中的多个节点上（为了减少节点故障的影响， 请参阅 kubernetesiohostname）。 对于多区域集群，这种分布行为也被应用到区域上（以减少区域故障的影响）。 这是通过 SelectorSpreadPriority 实现的。

SelectorSpreadPriority 是一种尽力而为（best-effort）的处理方式，如果集群中的区域是异构的 (例如：不同区域之间的节点数量、节点类型或 Pod 资源需求不同），可能使得 Pod 在各区域间无法均匀分布。 如有需要，用户可以使用同质的区域(节点数量和类型相同) 来减小 Pod 分布不均的可能性。

由于卷不能跨区域挂载（Attach），调度器（通过 VolumeZonePredicate 预选）也会保证需要特定卷的 Pod 被调度到卷所在的区域中。

如果 PersistentVolumeLabel 准入控制器不支持自动为 PersistentVolume 打标签，且用户希望防止 pod 跨区域进行卷的挂载， 应考虑手动打标签 (或增加对 PersistentVolumeLabel 的支持）。如果用户的基础设施没有这种约束，则不需要为卷添加区域标签。