kubectl describeExplain an object's state, conditions and events
kubectl describe prints a human-readable report about one object: its spec, current state, last termination reason, conditions and, most usefully, the Events that the scheduler and kubelet recorded about it. When a pod is Pending, crashing or can't pull its image, describe tells you why.
kubectl describe TYPE NAME [-n NAMESPACE] | kubectl describe TYPE -l SELECTORThe worker pod is in CrashLoopBackOff. Find out how its container died before reading any logs.
kubectlThe Kubernetes CLI.
describe is a client-side report, not a server feature. kubectl GETs the object, then makes extra API calls for the things a human needs next to it: for a pod, the Events whose involvedObject is that pod (GET /api/v1/namespaces/prod/events?fieldSelector=involvedObject.name=...,involvedObject.uid=...); for a node, the pods scheduled on it so it can sum their requests; for a Service, its EndpointSlices; for a Deployment, its ReplicaSets. Events are written by components: the scheduler (Scheduled, FailedScheduling), the kubelet (Pulling, Pulled, Created, Started, BackOff, Unhealthy, Killing) and controllers (SuccessfulCreate, ScalingReplicaSet). They expire after about an hour (the API server's --event-ttl), so describe soon after the problem. Repeated events are merged into one row with a count, like (x61 over 17m).
-n NSNamespace of the object-l SELECTORDescribe every object matching a label selector-ASearch all namespaces (with a type, no name)--show-events=falseLeave out the Events table--chunk-size=NPage large lists from the server (default 500)TYPE/NAMEAlternative form: kubectl describe deploy/apiRunning kubectl describe pod an hour after the crash and finding 'Events: <none>'Events expire after about an hour by default, so the evidence is gone.
Describe straight away; ship events to your logging system (an event exporter) for historyDeleting a crash-looping pod to 'fix' itThe Deployment recreates it with the same spec, and the new pod loses Last State, the restart count and the events you needed.
kubectl describe pod NAME and kubectl logs NAME --previous first, then fix the specReading 'Insufficient memory' as 'the nodes are out of RAM'The scheduler compares the pod's requests with each node's allocatable minus other pods' requests; real usage may be low.
kubectl describe node NODE | grep -A8 'Allocated resources' # then right-size requestskubectl describe pods -n prod with no name on a big namespaceIt describes every pod and fetches each one's events: hundreds of API calls and pages of output.
kubectl describe pod NAME, or narrow with -l app=workerTry these on a Linux machine of your own. Each task has a hint and a solution.
Write the command that shows the events for the node ip-10-0-3-77.ap-south-1.compute.internal, and the section of describe that tells you if it is under memory pressure.
Read this and name the cause: 'Warning FailedScheduling 0/3 nodes are available: 3 node(s) didn't match Pod's node affinity/selector.'
In the AWS Lab > EKS > your cluster > Run kubectl (lab) page, deploy the sample app and describe one of its pods. Find the node it runs on and its Events.
kubectl describeExplain an object's state, conditions and events
kubectl describe prints a human-readable report about one object: its spec, current state, last termination reason, conditions and, most usefully, the Events that the scheduler and kubelet recorded about it. When a pod is Pending, crashing or can't pull its image, describe tells you why.
kubectl describe TYPE NAME [-n NAMESPACE] | kubectl describe TYPE -l SELECTORThe worker pod is in CrashLoopBackOff. Find out how its container died before reading any logs.
kubectlThe Kubernetes CLI.
describe is a client-side report, not a server feature. kubectl GETs the object, then makes extra API calls for the things a human needs next to it: for a pod, the Events whose involvedObject is that pod (GET /api/v1/namespaces/prod/events?fieldSelector=involvedObject.name=...,involvedObject.uid=...); for a node, the pods scheduled on it so it can sum their requests; for a Service, its EndpointSlices; for a Deployment, its ReplicaSets. Events are written by components: the scheduler (Scheduled, FailedScheduling), the kubelet (Pulling, Pulled, Created, Started, BackOff, Unhealthy, Killing) and controllers (SuccessfulCreate, ScalingReplicaSet). They expire after about an hour (the API server's --event-ttl), so describe soon after the problem. Repeated events are merged into one row with a count, like (x61 over 17m).
-n NSNamespace of the object-l SELECTORDescribe every object matching a label selector-ASearch all namespaces (with a type, no name)--show-events=falseLeave out the Events table--chunk-size=NPage large lists from the server (default 500)TYPE/NAMEAlternative form: kubectl describe deploy/apiRunning kubectl describe pod an hour after the crash and finding 'Events: <none>'Events expire after about an hour by default, so the evidence is gone.
Describe straight away; ship events to your logging system (an event exporter) for historyDeleting a crash-looping pod to 'fix' itThe Deployment recreates it with the same spec, and the new pod loses Last State, the restart count and the events you needed.
kubectl describe pod NAME and kubectl logs NAME --previous first, then fix the specReading 'Insufficient memory' as 'the nodes are out of RAM'The scheduler compares the pod's requests with each node's allocatable minus other pods' requests; real usage may be low.
kubectl describe node NODE | grep -A8 'Allocated resources' # then right-size requestskubectl describe pods -n prod with no name on a big namespaceIt describes every pod and fetches each one's events: hundreds of API calls and pages of output.
kubectl describe pod NAME, or narrow with -l app=workerTry these on a Linux machine of your own. Each task has a hint and a solution.
Write the command that shows the events for the node ip-10-0-3-77.ap-south-1.compute.internal, and the section of describe that tells you if it is under memory pressure.
Read this and name the cause: 'Warning FailedScheduling 0/3 nodes are available: 3 node(s) didn't match Pod's node affinity/selector.'
In the AWS Lab > EKS > your cluster > Run kubectl (lab) page, deploy the sample app and describe one of its pods. Find the node it runs on and its Events.