參考：https://kubernetes.io/zh/docs/reference/labels-annotations-taints/
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 服務器會在所有命名空間上設置此標簽。標簽值被設置為命名空間的名稱。
如果你想使用標簽 選擇器 來指向特定的命名空間，這很有用。
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 類型。
node.kubernetes.io/instance-type
示例：node.kubernetes.io/instance-type=m3.medium
用於：Node
Kubelet 用 cloudprovider 定義的實例類型生成此標簽。 所以只有用到 cloudprovider 的場合，才會設置此標簽。 此標簽非常有用，特別是在你希望把特定工作負載打到特定實例類型的時候，但更常見的調度方法是基於 Kubernetes 調度器來執行基於資源的調度。 你應該聚焦於使用基於屬性的調度方式，而盡量不要依賴實例類型（例如：應該申請一個 GPU，而不是 g2.2xlarge）。
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 資源將使用此默認類型。
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。