- 常见的标签、注解和污点
- kubernetes.io/arch
- kubernetes.io/os
- kubernetes.io/metadata.name
- beta.kubernetes.io/arch (deprecated)
- beta.kubernetes.io/os (deprecated)
- kubernetes.io/hostname
- controller.kubernetes.io/pod-deletion-cost
- 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)
- statefulset.kubernetes.io/pod-name
- 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)
- storageclass.kubernetes.io/is-default-class
- alpha.kubernetes.io/provided-node-ip
- batch.kubernetes.io/job-completion-index
- kubectl.kubernetes.io/default-container
- endpoints.kubernetes.io/over-capacity
- 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 节点),此键值可以带来极大便利。
kubernetes.io/metadata.name
示例:kubernetes.io/metadata.name=mynamespace
用于:Namespaces
当 NamespaceDefaultLabelName
特性门控 被启用时,Kubernetes API 服务器会在所有命名空间上设置此标签。标签值被设置为命名空间的名称。
如果你想使用标签 选择器 来指向特定的命名空间,这很有用。
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。
controller.kubernetes.io/pod-deletion-cost
示例:controller.kubernetes.io/pod-deletion-cost=10
用于:Pod
该注解用于设置 Pod 删除开销, 允许用户影响 ReplicaSet 的缩减顺序。该注解解析为 int32
类型。
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.
statefulset.kubernetes.io/pod-name
示例:statefulset.kubernetes.io/pod-name=mystatefulset-7
当 StatefulSet 控制器为 StatefulSet 创建 Pod 时,控制平面会在该 Pod 上设置此标签。 标签的值是正在创建的 Pod 的名称。
更多细节请参见 StatefulSet 文章中的 Pod 名称标签。
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
。
storageclass.kubernetes.io/is-default-class
示例:storageclass.kubernetes.io/is-default-class=true
用于:StorageClass
当单个的 StorageClass 资源将这个注解设置为 "true"
时,新的持久卷申领(PVC) 资源若未指定类别,将被设定为此默认类别。
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 是否有效。
batch.kubernetes.io/job-completion-index
示例:batch.kubernetes.io/job-completion-index: "3"
用于:Pod
kube-controller-manager 中的 Job 控制器给创建使用索引 完成模式 的 Pod 设置此注解。
kubectl.kubernetes.io/default-container
示例:kubectl.kubernetes.io/default-container: "front-end-app"
注解的值是此 Pod 的默认容器名称。 例如,kubectl logs
或 kubectl exec
没有 -c
或 --container
参数时,将使用这个默认的容器。
endpoints.kubernetes.io/over-capacity
示例:endpoints.kubernetes.io/over-capacity:warning
用于:Endpoints
在 Kubernetes 集群 v1.21(或更高版本)中,如果 Endpoint 超过 1000 个,Endpoint 控制器 就会向其添加这个注解。该注解表示 Endpoint 资源已超过容量。
以下列出的污点只能用于 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
。
最后修改 June 03, 2021 at 11:15 AM PST : [zh]Resync Reference files[11] (c73d0510b)