A water-utility admin begins node troubleshooting. Which first-line kubectl inspection best surfaces conditions, taints, and allocatable resources together?
Select an answer to reveal the explanation.
Short Explanation
describe node is the triage clipboard—conditions, taints, and how much room is left, all in one place before you start swinging delete hammers.
Full Explanation
A water-utility admin beginning node troubleshooting should start with kubectl describe node, which surfaces Conditions, Taints, Allocatable capacity, and related events together. describe node is the triage clipboard—pressure flags, scheduling gates, and how much room is left—before anyone swings delete hammers on municipal infrastructure.
kubectl delete node --force is not the required first diagnostic step. kubectl attach to kube-apiserver on the node under test is inappropriate. Creating tokens for every ServiceAccount before reading node status is unrelated busywork.
Exam caveat: pair describe with kubectl get nodes -o wide for versions and IPs, then drill into kubelet and runtime logs on the host as needed. Destructive actions come only after diagnosis.
Operational check: describe the suspect node, note NotReady/pressure/taints/allocatable, form a hypothesis, validate on the host, remediate, and re-describe to confirm conditions cleared for the utility cluster. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork. Prefer reversible steps and verify Ready or Bound state before closing the incident.