Kubernetes / Cluster Operations, Access & Incident Response
Explain why healthy nodes receive no new ordinary workloads
A node can be Ready but intentionally unschedulable during maintenance. Check scheduling state before changing placement rules.
Environment and inputs: Kubernetes · kubectl with supported client/server versions and delegated RBAC. Examples use namespace app unless noted. Check context, namespace, APIs and provider support first.
Start with this check
Confirm the environment and replace sample objects, namespaces, images, paths and hosts with approved targets. Share only relevant, sanitized output. Follow the workload owner’s process for changes.
kubectl get nodes
kubectl describe node node01Read the result
The listing and description reveal scheduling-disabled state, taints and other constraints. Ready alone is not an eligibility guarantee.
Resolve and verify
Compare the node with the approved maintenance record and actual scheduler message. Resume scheduling only when the node owner confirms maintenance and validation are complete.
Before changing production
Do not uncordon a node still undergoing upgrades, recovery or security containment.