Revise the page to accurately document the well-known labels, annotations and taints.
This commit is contained in:
CKchen0726
@@ -114,3 +114,143 @@ The scheduler (through the _VolumeZonePredicate_ predicate) also will ensure tha
|
||||
If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, you should consider
|
||||
adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all.
|
||||
|
||||
## node.kubernetes.io/windows-build {#nodekubernetesiowindows-build}
|
||||
|
||||
Example: `node.kubernetes.io/windows-build=10.0.17763`
|
||||
|
||||
Used on: Node
|
||||
|
||||
When the kubelet is running on Microsoft Windows, it automatically labels its node to record the version of Windows Server in use.
|
||||
|
||||
The label's value is in the format "MajorVersion.MinorVersion.BuildNumber".
|
||||
|
||||
## service.kubernetes.io/headless {#servicekubernetesioheadless}
|
||||
|
||||
Example: `service.kubernetes.io/headless=""`
|
||||
|
||||
Used on: Service
|
||||
|
||||
The control plane adds this label to an Endpoints object when the owning Service is headless.
|
||||
|
||||
## kubernetes.io/service-name {#kubernetesioservice-name}
|
||||
|
||||
Example: `kubernetes.io/service-name="nginx"`
|
||||
|
||||
Used on: Service
|
||||
|
||||
Kubernetes uses this label to differentiate multiple Services. Used currently for `ELB`(Elastic Load Balancer) only.
|
||||
|
||||
## endpointslice.kubernetes.io/managed-by {#endpointslicekubernetesiomanaged-by}
|
||||
|
||||
Example: `endpointslice.kubernetes.io/managed-by="controller"`
|
||||
|
||||
Used on: EndpointSlices
|
||||
|
||||
The label is used to indicate the controller or entity that manages an EndpointSlice. This label aims to enable different EndpointSlice objects to be managed by different controllers or entities within the same cluster.
|
||||
|
||||
## endpointslice.kubernetes.io/skip-mirror {#endpointslicekubernetesioskip-mirror}
|
||||
|
||||
Example: `endpointslice.kubernetes.io/skip-mirror="true"`
|
||||
|
||||
Used on: Endpoints
|
||||
|
||||
The label can be set to `"true"` on an Endpoints resource to indicate that the EndpointSliceMirroring controller should not mirror this resource with EndpointSlices.
|
||||
|
||||
## service.kubernetes.io/service-proxy-name {#servicekubernetesioservice-proxy-name}
|
||||
|
||||
Example: `service.kubernetes.io/service-proxy-name="foo-bar"`
|
||||
|
||||
Used on: Service
|
||||
|
||||
The kube-proxy has this label for custom proxy, which delegates service control to custom proxy.
|
||||
|
||||
## experimental.windows.kubernetes.io/isolation-type
|
||||
|
||||
Example: `experimental.windows.kubernetes.io/isolation-type: "hyperv"`
|
||||
|
||||
Used on: Pod
|
||||
|
||||
The annotation is used to run Windows containers with Hyper-V isolation. To use Hyper-V isolation feature and create a Hyper-V isolated container, the kubelet should be started with feature gates HyperVContainer=true and the Pod should include the annotation experimental.windows.kubernetes.io/isolation-type=hyperv.
|
||||
|
||||
{{< note >}}
|
||||
You can only set this annotation on Pods that have a single container.
|
||||
{{< /note >}}
|
||||
|
||||
## ingressclass.kubernetes.io/is-default-class
|
||||
|
||||
Example: `ingressclass.kubernetes.io/is-default-class: "true"`
|
||||
|
||||
Used on: IngressClass
|
||||
|
||||
When a single IngressClass resource has this annotation set to `"true"`, new Ingress resource without a class specified will be assigned this default class.
|
||||
|
||||
## kubernetes.io/ingress.class (deprecated)
|
||||
|
||||
{{< note >}} Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassName`. {{< /note >}}
|
||||
|
||||
## alpha.kubernetes.io/provided-node-ip
|
||||
|
||||
Example: `alpha.kubernetes.io/provided-node-ip: "10.0.0.1"`
|
||||
|
||||
Used on: Node
|
||||
|
||||
The kubelet can set this annotation on a Node to denote its configured IPv4 address.
|
||||
|
||||
When kubelet is started with the "external" cloud provider, it sets this annotation on the Node to denote an IP address set from the command line flag (`--node-ip`). This IP is verified with the cloud provider as valid by the cloud-controller-manager.
|
||||
|
||||
**The taints listed below are always used on Nodes**
|
||||
|
||||
## node.kubernetes.io/not-ready
|
||||
|
||||
Example: `node.kubernetes.io/not-ready:NoExecute`
|
||||
|
||||
The node controller detects whether a node is ready by monitoring its health and adds or removes this taint accordingly.
|
||||
|
||||
## node.kubernetes.io/unreachable
|
||||
|
||||
Example: `node.kubernetes.io/unreachable:NoExecute`
|
||||
|
||||
The node controller adds the taint to a node corresponding to the [NodeCondition](/docs/concepts/architecture/nodes/#condition) `Ready` being `Unknown`.
|
||||
|
||||
## node.kubernetes.io/unschedulable
|
||||
|
||||
Example: `node.kubernetes.io/unschedulable:NoSchedule`
|
||||
|
||||
The taint will be added to a node when initializing the node to avoid race condition.
|
||||
|
||||
## node.kubernetes.io/memory-pressure
|
||||
|
||||
Example: `node.kubernetes.io/memory-pressure:NoSchedule`
|
||||
|
||||
The kubelet detects memory pressure based on `memory.available` and `allocatableMemory.available` observed on a Node. The observed values are then compared to the corresponding thresholds that can be set on the kubelet to determine if the Node condition and taint should be added/removed.
|
||||
|
||||
## node.kubernetes.io/disk-pressure
|
||||
|
||||
Example: `node.kubernetes.io/disk-pressure:NoSchedule`
|
||||
|
||||
The kubelet detects disk pressure based on `imagefs.available`, `imagefs.inodesFree`, `nodefs.available` and `nodefs.inodesFree`(Linux only) observed on a Node. The observed values are then compared to the corresponding thresholds that can be set on the kubelet to determine if the Node condition and taint should be added/removed.
|
||||
|
||||
## node.kubernetes.io/network-unavailable
|
||||
|
||||
Example: `node.kubernetes.io/network-unavailable:NoSchedule`
|
||||
|
||||
This is initially set by the kubelet when the cloud provider used indicates a requirement for additional network configuration. Only when the route on the cloud is configured properly will the taint be removed by the cloud provider.
|
||||
|
||||
## node.kubernetes.io/pid-pressure
|
||||
|
||||
Example: `node.kubernetes.io/pid-pressure:NoSchedule`
|
||||
|
||||
The kubelet checks D-value of the size of `/proc/sys/kernel/pid_max` and the PIDs consumed by Kubernetes on a node to get the number of available PIDs that referred to as the `pid.available` metric. The metric is then compared to the corresponding threshold that can be set on the kubelet to determine if the node condition and taint should be added/removed.
|
||||
|
||||
## node.cloudprovider.kubernetes.io/uninitialized
|
||||
|
||||
Example: `node.cloudprovider.kubernetes.io/uninitialized:NoSchedule`
|
||||
|
||||
Sets this taint on a node to mark it as unusable, when kubelet is started with the "external" cloud provider, until a controller from the cloud-controller-manager initializes this node, and then removes the taint.
|
||||
|
||||
## node.cloudprovider.kubernetes.io/shutdown
|
||||
|
||||
Example: `node.cloudprovider.kubernetes.io/shutdown:NoSchedule`
|
||||
|
||||
If a Node is in a cloud provider specified shutdown state, the Node gets tainted accordingly with `node.cloudprovider.kubernetes.io/shutdown` and the taint effect of `NoSchedule`.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user