我的书签
添加书签
移除书签- 常见的标签、注解和污点
- kubernetes.io/arch
- kubernetes.io/os
- beta.kubernetes.io/arch (deprecated)
- beta.kubernetes.io/os (deprecated)
- kubernetes.io/hostname
- beta.kubernetes.io/instance-type (deprecated)
- node.kubernetes.io/instance-type
- failure-domain.beta.kubernetes.io/region (deprecated)
- failure-domain.beta.kubernetes.io/zone (deprecated)
- topology.kubernetes.io/region
- topology.kubernetes.io/zone
- node.kubernetes.io/windows-build
- service.kubernetes.io/headless
- kubernetes.io/service-name
- endpointslice.kubernetes.io/managed-by
- endpointslice.kubernetes.io/skip-mirror
- service.kubernetes.io/service-proxy-name
- experimental.windows.kubernetes.io/isolation-type
- ingressclass.kubernetes.io/is-default-class
- kubernetes.io/ingress.class (deprecated)
- alpha.kubernetes.io/provided-node-ip
- node.kubernetes.io/not-ready
- node.kubernetes.io/unreachable
- node.kubernetes.io/unschedulable
- node.kubernetes.io/memory-pressure
- node.kubernetes.io/disk-pressure
- node.kubernetes.io/network-unavailable
- node.kubernetes.io/pid-pressure
- node.cloudprovider.kubernetes.io/uninitialized
- node.cloudprovider.kubernetes.io/shutdown
常见的标签、注解和污点
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 (deprecated)
此标签已被弃用，取而代之的是 kubernetes.io/arch.
beta.kubernetes.io/os (deprecated)
此标签已被弃用，取而代之的是 kubernetes.io/os.
kubernetes.io/hostname
示例：kubernetes.io/hostname=ip-172-20-114-199.ec2.internal
用于：Node
Kubelet 用主机名生成此标签。需要注意的是主机名可修改，这是把“实际的”主机名通过参数 --hostname-override 传给 kubelet 实现的。
此标签也可用做拓扑层次的一个部分。更多信息参见topology.kubernetes.io/zone。
beta.kubernetes.io/instance-type (deprecated)
说明：
从 v1.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 (deprecated)
参见 topology.kubernetes.io/region.
说明：
从 v1.17 开始，此标签被弃用，取而代之的是 topology.kubernetes.io/region.
failure-domain.beta.kubernetes.io/zone (deprecated)
参见 topology.kubernetes.io/zone.
说明：
从 v1.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 的场景下，此标签才会被设置。 但如果此标签在你的拓扑中有意义，你也可以考虑在 node 上设置它。
PersistentVolume 场景：拓扑自感知的卷制备程序将在 PersistentVolumes 上自动设置节点亲和性限制。
一个可用区（zone）表示一个逻辑故障域。Kubernetes 集群通常会跨越多个可用区以提高可用性。 虽然可用区的确切定义留给基础设施来决定，但可用区常见的属性包括：可用区内的网络延迟非常低，可用区内的网络通讯没成本，独立于其他可用区的故障域。 例如，一个可用区中的节点可以共享交换机，但不同可用区则不会。
一个地区（region）表示一个更大的域，由一个到多个可用区组成。对于 Kubernetes 来说，跨越多个地区的集群很罕见。 虽然可用区和地区的确切定义留给基础设施来决定，但地区的常见属性包括：地区间比地区内更高的网络延迟，地区间网络流量更高的成本，独立于其他可用区或是地区的故障域。例如，一个地区内的节点可以共享电力基础设施（例如 UPS 或发电机），但不同地区内的节点显然不会。
Kubernetes 对可用区和地区的结构做出一些假设： 1）地区和可用区是层次化的：可用区是地区的严格子集，任何可用区都不能再 2 个地区中出现。 2）可用区名字在地区中独一无二：例如地区 “africa-east-1” 可由可用区 “africa-east-1a” 和 “africa-east-1b” 构成。
你可以安全的假定拓扑类的标签是固定不变的。即使标签严格来说是可变的，但使用者依然可以假定一个节点只有通过销毁、重建的方式，才能在可用区间移动。
Kubernetes 能以多种方式使用这些信息。 例如，调度器自动地尝试将 ReplicaSet 中的 Pod 打散在单可用区集群的不同节点上（以减少节点故障的影响，参见kubernetes.io/hostname）。 在多可用区的集群中，这类打散分布的行为也会应用到可用区（以减少可用区故障的影响）。 做到这一点靠的是 SelectorSpreadPriority。
SelectorSpreadPriority 是一种最大能力分配方法（best effort）。如果集群中的可用区是异构的（例如：不同数量的节点，不同类型的节点，或不同的 Pod 资源需求），这种分配方法可以防止平均分配 Pod 到可用区。如果需要，你可以用同构的可用区（相同数量和类型的节点）来减少潜在的不平衡分布。
调度器（通过 VolumeZonePredicate 的预测）也会保障声明了某卷的 Pod 只能分配到该卷相同的可用区。 卷不支持跨可用区挂载。
如果 PersistentVolumeLabel 不支持给 PersistentVolume 自动打标签，你可以考虑手动加标签（或增加 PersistentVolumeLabel 支持）。 有了 PersistentVolumeLabel，调度器可以防止 Pod 挂载不同可用区中的卷。 如果你的基础架构没有此限制，那你根本就没有必要给卷增加 zone 标签。
node.kubernetes.io/windows-build
示例: node.kubernetes.io/windows-build=10.0.17763
用于：Node
当 kubelet 运行于 Microsoft Windows，它给节点自动打标签，以记录 Windows Server 的版本。
标签值的格式为 “主版本.次版本.构建号”
service.kubernetes.io/headless
示例：service.kubernetes.io/headless=""
用于：Service
在无头（headless）服务的场景下，控制平面为 Endpoint 对象添加此标签。
kubernetes.io/service-name
示例：kubernetes.io/service-name="nginx"
用于：Service
Kubernetes 用此标签区分多个服务。当前仅用于 ELB(Elastic Load Balancer)。
endpointslice.kubernetes.io/managed-by
示例：endpointslice.kubernetes.io/managed-by="controller"
用于：EndpointSlices
此标签用来指向管理 EndpointSlice 的控制器或实体。 此标签的目的是用集群中不同的控制器或实体来管理不同的 EndpointSlice。
endpointslice.kubernetes.io/skip-mirror
示例：endpointslice.kubernetes.io/skip-mirror="true"
用于：Endpoints
此标签在 Endpoints 资源上设为 "true" 指示 EndpointSliceMirroring 控制器不要镜像此 EndpointSlices 资源。
service.kubernetes.io/service-proxy-name
示例：service.kubernetes.io/service-proxy-name="foo-bar"
用于：Service
kube-proxy 把此标签用于客户代理，将服务控制委托给客户代理。
experimental.windows.kubernetes.io/isolation-type
示例：experimental.windows.kubernetes.io/isolation-type: "hyperv"
用于：Pod
此注解用于运行 Hyper-V 隔离的 Windows 容器。 要使用 Hyper-V 隔离特性，并创建 Hyper-V 隔离容器，kubelet 应该用特性门控 HyperVContainer=true 来启动，并且 Pod 应该包含注解 experimental.windows.kubernetes.io/isolation-type=hyperv。
说明： 你只能在单容器 Pod 上设置此注解。
ingressclass.kubernetes.io/is-default-class
示例：ingressclass.kubernetes.io/is-default-class: "true"
用于：IngressClass
当唯一的 IngressClass 资源将此注解的值设为 “true”，没有指定类型的新 Ingress 资源将使用此默认类型。
kubernetes.io/ingress.class (deprecated)
说明：
从 v1.18 开始，此注解被弃用，取而代之的是
spec.ingressClassName。
alpha.kubernetes.io/provided-node-ip
示例：alpha.kubernetes.io/provided-node-ip: "10.0.0.1"
用于：Node
kubectl 在 Node 上设置此注解，表示它的 IPv4 地址。
当 kubectl 由外部的云供应商启动时，在 Node 上设置此注解，表示由命令行标记(--node-ip)设置的 IP 地址。 cloud-controller-manager 向云供应商验证此 IP 是否有效。
以下列出的污点只能用于 Node
node.kubernetes.io/not-ready
示例：node.kubernetes.io/not-ready:NoExecute
节点控制器通过健康监控来检测节点是否就绪，并据此添加/删除此污点。
node.kubernetes.io/unreachable
示例：node.kubernetes.io/unreachable:NoExecute
如果 NodeCondition 的 Ready 键值为 Unknown，节点控制器将添加污点到 node。
node.kubernetes.io/unschedulable
示例：node.kubernetes.io/unschedulable:NoSchedule
当初始化节点时，添加此污点，来避免竟态的发生。
node.kubernetes.io/memory-pressure
示例：node.kubernetes.io/memory-pressure:NoSchedule
kubelet 依据节点上观测到的 memory.available 和 allocatableMemory.available 来检测内存压力。 用观测值对比 kubelet 设置的阈值，以判断节点状态和污点是否可以被添加/移除。
node.kubernetes.io/disk-pressure
示例：node.kubernetes.io/disk-pressure:NoSchedule
kubelet 依据节点上观测到的 imagefs.available、imagefs.inodesFree、nodefs.available 和 nodefs.inodesFree(仅 Linux) 来判断磁盘压力。 用观测值对比 kubelet 设置的阈值，以确定节点状态和污点是否可以被添加/移除。
node.kubernetes.io/network-unavailable
示例：node.kubernetes.io/network-unavailable:NoSchedule
它初始由 kubectl 设置，云供应商用它来指示对额外网络配置的需求。 仅当云中的路由器配置妥当后，云供应商才会移除此污点。
node.kubernetes.io/pid-pressure
示例：node.kubernetes.io/pid-pressure:NoSchedule
kubelet 检查 /proc/sys/kernel/pid_max 尺寸的 D 值（D-value），以及节点上 Kubernetes 消耗掉的 PID，以获取可用的 PID 数量，此数量可通过指标 pid.available 得到。 然后用此指标对比 kubelet 设置的阈值，以确定节点状态和污点是否可以被添加/移除。
node.cloudprovider.kubernetes.io/uninitialized
示例：node.cloudprovider.kubernetes.io/uninitialized:NoSchedule
当 kubelet 由外部云供应商启动时，在节点上设置此污点以标记节点不可用，直到一个 cloud-controller-manager 控制器初始化此节点之后，才会移除此污点。
node.cloudprovider.kubernetes.io/shutdown
示例：node.cloudprovider.kubernetes.io/shutdown:NoSchedule
如果一个云供应商的节点被指定为关机状态，节点被打上污点 node.cloudprovider.kubernetes.io/shutdown，污点的影响为 NoSchedule。
